Thursday, September 6, 2018

Converged IoT Platform Operating Notes

Alternative operating procedures are not discussed in this general chapter. They will be discussed in individual notes of topics.

Flight Computer With Stabilization Precedence

The racing drone flight computer software is 2020's betaflight_4.2.5_STM32F411.hex, displayed as 483267 bytes when you choose either the generic STM32F411 or HGLRCF411 flashing option in the Betaflight Configurator. The configuration is dump_all_converged_IoT_hglrc_fd411.txt. The Configurator can be the latest version or 2020's v10.7.0 or higher on a Chromebook.
The flight computer can have 3 operating modes, pass-thru, accelerometer, and gyro. But, the pass-thru(manual) mode is not operable, as shown in this video.
tilt right and backward - 0:01
attitude mode to rescue - 0:02
tilt right and forward - 0:03
 to attitude mode - 0:04
 tilt left straight - 0:05
attitude mode - 0:06
tilt backward - 0:08
attitude mode - 0:09
tilt forward - 0:10
 attitude mode - 0:11
 landing approach too high - 0:25
backing off far and fast - 0:35
good landing approach - 0:40
 touch down - 0:53
So, the OpenTX transmitter should engage in a stabilization mode before liftoff. 

The problem of erratic, forceful PID Integral over-correction (winding) is common throughout nearly all helicopter flight computers. An example of the same problem is with Blade230's AS3X; in the video on the right, during the spool-up, the error rolling to the right is at 0:14. This is because the PIDs are tuned for flying in the air when rotor RPM is sufficiently high, but the ground contacts force the craft attitude out of the planned flight envelope when the spooling-up rotor RPM is too low to correct in time. To overcome this problem, we cancel the PID process and use pass-thru-manual mode during rotor spool-up. The spool-up RPM should be controlled directly by the pilot by the throttle proportion on channel 5 to ensure safety, and the pilot's control should only be relinquished with the pilot's explicit input on the channel 6 switch, even when the throttle position reaches full speed. The in-depth spool-up note discusses the reason for this channel switch assignment and the alternatives. The spool-up throttle channel setup is pictured here on the right. 

Toward complete solving the problems of the previous two paragraphs, we configure the flight computer to give the pass-thru mode a channel switch, and this channel switch for the pass-thru mode is tied with a constant negative collective pitch. The negative pitch prevents a takeoff while the pilot spools up the rotor with the CV1 curve. In blue, we highlight the disabling of the accelerometer and/or gyro sensors. The flesh color underneath all flight modes is for the same set of PID coefficients throughout all modes.

To convert the fraction system to the flight computer's PWM timing system, Betaflight/FD411 needs to anchor the endpoints to the nearby 25 points of the 1000us-to-2000us range, which is the range the OpenTX can produce after 98% scaling of 989-2011us.

To reduce pilot/operating error, we should consistently use all these modes on both the flight computer and the three modes on the transmitter. There is no such thing as a reliable, field-improvised easy transmitter setup, as the following 2 paragraphs discuss.

When the first mode does not set the collective pitch to -23(that prevents liftoff) via an extra channel one mixer page in a faulty improvised setting, the pilot may forget to switch channel six to the middle position when attempting to reduce time to takeoff to save battery life in the midst of enabling video recordings and operating other equipment. The result is forceful crashes due to the high power applied for takeoff and the high-speed drift of the manual mode. The video of such a crash is on the right.

When the transmitter and flight computer setups are improvised out of sync, the takeoff can happen in gyro-only mode. This happens even after a hand-tethered hovering test because the gyro-only mode hovering can be successful without the pilot knowing that the modes are out of sync, for that gyro-only mode does have stabilization characteristics. Then the actual takeoff will, again, crash badly due to the high craft momentum nature of the gyro-only mode. The video of this gyro-only mode takeoff is on the right. This field fault occurs when we are tempted into setting a single 2-position switch on Aux2-channel6 for a cruise-only mission. In the field, the PWM for profile switching appears to need more than 33%, say 40% or 50%, weight to expand over the 1/3 spool-up region at a low position. And that is true for a 2-position switch, but Betaflight would interpret the high position (2000-1500)*0.4+1500=1700 in the gyro-only setting because the weight scaling is centered at 1500, not 1000, as depicted in the diagram on the right.

How about tieing stabilization mode with arming the craft? The problem with the tieing is that abrupt powering off the RF transmitter (to conserve battery or to avoid accidentally activating stick commands) prevents the returning to manual mode for swash plate level checks. Checking swashplate leveling is needed after each hard landing with servo clutch slip, which can be needed frequently, and hence repowering up the RF transmitter just to disarm complicates the work procedure and frustrates operators.

Motors Use Multi-Rotor Software

14-pole motors are the most common of drones at 250 grams. During pre-prototype motor selection, it was discovered that the 250-gram craft hovered at -20/-100+100 throttle with the Oxy2 210mm blades, RPM 3.7V*3S*660kv*80/200*(90/100 torque retardation)=2640, 6.2 degree collective, with a 14-pole, 660kv motor, with 3S battery, as pictured on the right. The pre-prototype motor selection further involved testing hovering with 4.8 degrees collective and 94/200 throttle for the same motor with the throttle curve on the lower right, all with a 3S battery pack. The maximum punch/climb at 114+7(compensation knob added 7 points for voltage drop)/200 throttles induced oscillation on the stable craft, indicating that RPM exceeded hovering RPM and craft PIDs needed scaling down subsequently for the pre-prototype craft. The pre-prototype motor selection further switched from the 14-pole motor to the high-efficiency 24-pole 4004 400kv motors and utilized KV ESC PWM scaling for the same punch/climb test, equaling (114+7)x660/400=200 full throttle. The question is which motors under 55 grams are powerful enough. And, the design phase verified that both motors had sufficient motor power throughput without draining battery current higher than allowance for better-than-steady-RPM maximum punch/climb.

The question is which software among MAIN, MULTI, and TAIL to use with variable RPM in-flight. And, it was tested by changing the main rotor ESC from MULTI to MAIN code with the RPM governor disabled; it resulted in a spool-up delay of roughly 3 seconds whenever throttle-up and resistance were detected. That meant when the pre-protype craft descends too fast approaching an obstacle, I couldn't punch up the craft immediately because the ESC senses blade foil drags with throttle-up and gives small increments of torque over 3 seconds to prevent damage to the helicopter pinion/gear. There is no resistance reduction gearing in the gearless helicopter, so the ESC needs to apply the torque regardless of resistance, just like a multi-rotor system. The answer is shown in the BLHeli ESC assembly code,

, which shows that MULTI code has all the MAIN code functionalities, including fixed-RPM governor, but without the unneeded spool-up torque detection, and that MULTI code has all TAIL code functionalities except the unneeded idle spin, and hence the MULTI code should be used for both the primary and tail rotor of our IoT builds for simplicity. 

To configure the ESC, we use the FD411 computer's passthrough USB-to-UART connection program with BLHeli Configurator, either stand-alone or Chrome WebApp. With a stand-alone program, to access a USB tty device, the program needs to be started as root user. With WebApp in a Chromebook, Chrome browser always gives regular users full root access to USB.  For the pass-thru program to work, the MOTOR 1 pin needs to be temporarily assigned to the SERVO pin of the primary motor(SERVO 5 in CLI) or tail motor(SERVO 4 in CLI). Safety precaution dictates that motor power with ESC battery should be applied last after all connections and software are set up, and motor power should be the first to be torn down after any configuration/software flashing. With that in mind, power only the flight computer by connecting a micro USB cable, start the BLHeli app, and click "Connect" with the default baud rate and auto-detected tty port. The computer now reboots into the USB-to-UART adapter program. But, wait, there is sometimes a 1-minute delay for the reboot to occur if the BLHeli program determines that the Internet connection is available but the software website is unreachable, so the best is to ensure Internet access of the laptop PC. Now connect ESC's craft battery power, then click "Read Settings" to connect to the ESC computer. If the "Read Settings" button is unavailable, it is still in the 1-minute period. After flashing ESC with motor software, remove ESC's craft battery power plug first as a safety precaution. Then tear down software/other connections. If you don't tear away the power, when the program switches back to BetaFlight software, the motors will spin up to compensate for craft orientation or to match any unintended RF transmitter command signal, posing a great danger.

The mentioned "compensation" throttle setting for a specific motor, case-by case, is not applicable for large-scale deployment with varying hardware. The solution is to use ESC's RPM control PID governor. I-Gain needs to be high at 3.00 to track RPM precisely. P-Gain 0.13 to reduce sudden high torques and prevent breaking the motor anti-rotation zip tie. The governor doesn't detect torque and has a much shorter acting time than 3 seconds.

With RPM PID control, called the governor, the craft with the 14-pole pre-prototype motor needs 2640RPM / ( 50000RPM / 7 ) x 200poionts = 74 points level in the 0-200 scale of the transmitter for the same RPM as the mentioned "pre-prototype." The 50,000 max RPM is seen in the above GitHub page of the ESC source code. 1/7 fraction is attributed to the ratio of the 14-magnet brushless motor compared to the elementary 2-magnet motor.  For the production with 24-pole 4004 motors, to use the same throttle curves from the RF control transmitter for mass deployment compatible with 14-pole motors, the PWM needs to be scaled from the original span to 1000us x 14 / 24 = 583us. The scaling is performed in GUI.
Channel 5 is configured as a "servo 6", counting up from 2, "bypass" checked in the GUI. In the CLI's servo section (not the resources section, not the smix section), the fifth channel is specified as the 4th channel, counting from 0th in the last parameter; in the GUI, the 5th column is checked for "bypass."

The scaling, colloquially called calibration, configurator needs tentative(don't click Save in the GUI) Servo 6's MID and MIN set to the high position of 1583. 
The tentative neutral position only takes effect after you click on a different field in the GUI after entering the neutral PWM number, as shown in the screenshots above. The scaling is finalized when setting back to 1000 to save the scaling.
The motor is not configured as a motor in the mmix section. The motor can not be controlled with Motors GUI because Betaflight motor mmix is tied to throttle channel T, a collective pitch channel in our IoT build after all other alternatives were ruled out.
Here the mentioned 200-point scale is assumed to perfectly corresponds to 1000us to 2000us RF transmitter output, and if the RF transmitter uses the 989us to 2011us range, such as Frsky's X9 Lite or QX7, the RF transmitter needs scaling the channel by (2000-1000)/(2011-989)=97.8%. 
In the production model, the battery pack is further reinforced to 4S, giving a 25% extra power budget for future improvements in fuel economy/G-force-performance optimization. This battery change does not need an RF throttle signal change with the governor's RPM control. 

The tail's Startup Power needs to be optimized, as in TAIL software default setup, to catch up with tail lapse or the PIDs reset itself (slang terms "prop wash") frequently with a significant deviation of tail attitude when you make a left yaw during cruising or correcting a diving trajectory. During the R/D process, the momentary tail reset became frequent after changing from TAIL to MULTI, as shown in the video on the right. Notice that the heading is the same at 0:07 and 0:12 . The tail motor spins down at 0:07 when torque suddenly lowers down or when the wind blows from the side onto the tail fin/prop creating artificial counter torque. At 0:08, the tail motor can not spool up fast enough, and the deviation between the expected and actual heading is too large. At 0:09, the tail PID resets, allowing a (unintended) 360-degree turn. At 0:12, the tail spools up successfully.

It was noticed that TAIL software has a default of 1.25 Startup Power, so we replicated the property in the MULTI software, which is implicated to be in the 0.125-1.25 good range for quick catchup of motor spin after a prolonged idle, as the following screenshot of research by SiieeFPV.

Once the startup power is set to 1.25, the production craft tail reset is infrequent and needs deliberate efforts to reproduce the tail reset problem, as in the following 2 videos. 
Yet, another question is whether the Low RPM Power Protection feature is detrimental to the quick spinup. And our testing in the following 2 video footage showed that the Low RPM Power Protection feature is irrelevant when the propellers don't hit a solid obstacle, only spinning up the motor mid-air.
So, the solution configuration for the tail ESC is shown in the following screenshot, which enables the Low RPM Power Protection feature to protect the ESC in case of a crash when the propellers are stopped by the ground or other solid objects.

In the design phase, it was not obvious whether fixed RPM will be required during takeoff and landing. The CV1 spool-up throttle curve picture on the right is super-imposed by collective pitch curve, and the 2 curves were simultaneously in effective with build test hovering. The test showed that the region between the 2 red dash lines had tail punches, indicating insufficient RPM brought on by variable RPM configuration. So, the production build is determined to require fixed-RPM with ESC governor for both takoff and landing, not with the spool-up throttle curve.  

Collective Curve For Maximum Efficiency

All credit and copyright of airfoil data belong to , NASA, and Xfoil , for the following picture.

Our rotor RPM for level hovering is 2650/minute = 44/s . Rotor iameter 0.49m , speed at 3/4 blade span is 0.49m x 3.14 x 44/s x 3/4 = 51m/s . Our Reynolds number is 51m/s x 18mm / 1.46 x 100000 = 62,876 . So, between the light brown and green curves, but closer to the light brown curve, is our curve for attitude-accelerameter mode.

For simplicity of collective pitch angle calculation, we choose servo arm length identical to blade pitch lever length, 12 mm pictured above and on the right. The  Oxy2 Sport grips and the Align 250 grips have congruent geometry as shown in the picture above. When all 3 pillars of the swash plate are raised evenly, the blade lever and angle are congruent to the servo arm and angle.   
For the optimal lift-to-drag ratio blade pitch 6.2 degrees,  servo arms also rotate 6.2 degrees. The full range angle of the EMAX 9501 for 1000us to 2000us PWM is 83 degrees. 6.2 degrees / 83 degrees x 200 points = 14.94 points . To fit the PWM with our swash plate mixers here, we double the hovering points because most flight computers allocates 50% swash travel for collective mixing. So, we set a straight line for the collective pitch curve from 0 to 14.94x2=29.9 points at mid throttle stick. We stipulate collective pitch to 3/4 of throttle stick to avoid straining and overheating motors that have mislabeled KV. We use the servo sequence, the first servo on the front, the second on the right, and the third on the left, when looking down on the craft from above the craft. With Betaflight, servo 0 and servo 1 are reserved as pan-tilt servos for camera, so, the servo numbers start from 2 for the first craft servo.

Also in the -50 mix lines, the source 0 and 1 are stabilized roll and pitch respectively. Source 7 is throttle channel 1, not an aux(source 8+). The problem of assigning collective pitch control channel to Aux is that flight computer TPA(Throttle PID Attenuation) and TPS(Thrust PID Scaling) only corresponds to throttle, not AUX. The consideration with throttle input channel 1 in TAER being recognized as the throttle means arming for throttle position should not near 1500us to avoid stick function commands. After considering all alternatives, the arming is set to have a large negative collective pitch for low throttle. This large negative collective pitch is set as the inverted hovering pitch angle for fast travel RPM, which is -23 points, or 1500-23/200*1000=1385us. The F411's min_check=1385us can mislead us to think that a hypothetical RF calls for -57 point of 1215us collective signal will be conflated to 1385us in F411 setup, but F411's signal 7 is raw RF signal, not processed nor conflated. 

Swashplate Setting 

Insert a 2mm wide tape strip to fill the slop gap between the swash ball and servo rod socket, as indicated by red arrows in the below picture, to prevent pitch trap instability, discussed here When clipping on the link, the swash should be tilted at a large angle to avoid cutting the tape strip by the socket because the sockets have a sharp-edged rim. If, after checking that the tape inserts are working correctly, the craft still suffers from unmanageable altitude swing, replace the swashplate because an old swashplate with many crashes is loose and has an unacceptable slop gap.
Remember, our spool-up is performed in manual mode. If the swash banks to one side of the craft, there is no PID correction by the computer and no heavy battery or long tail lever on the sides of the fuselage to counter the tipping. Use a zip tie with the half-cut end, as shown in the below picture, to check that all 3 pillars nearly touch the servo linkage. This zip tie should only be used after checking for enough room between the swash and the hub after booting up the flight computer.  

It is well known that servos accept PWM range 1ms to 2ms, or 1000us to 2000us. But, the consensus is that manufactures specify margin of error of 150us between flight computer and servos when viewed in BLHeli configurator. So, it is safe to give servos PWM between 1000-150=850 and 2000+150=2150. The spline count of the servo arm is 15; the servo arm travels 83 degrees for 1000us. So, each spline dial notch is equivalent of  1000.0*(360.0/15)/83.0=289us PWM change. That means that when attempting to set the high-end PWM to larger than 2145us, you could dial the arm position up 1 spline and increase PWM on top of 2145-289=1856us, which will set the high-end PWM closer to central1500us in the tolerated margin of error. 

When changing the servo PWM center micro-second value, the change should be multiples of 10us because it doesn't have the resolution of the full 1000 PWM points; instead, it only changes with 1/100 of the full range. Considering that the full range of the servo arm is 83 degrees, 1/100 of the range is 0.83 degrees. To center the swash plate, check the top of the blade boltings pictured on the right. Change all the 3 PWM center neutral values 10us at a time. 

Indoor Hovering With RF Receiver With Proximity Cutoff

In the following video, XM+ receiver's LED starts out green, the transmitter antenna is shifted to create stronger radio coupling with the receiver at 0:01. The cutoff occurs at 0:02, the LED turns red, fail safe takes effect. The camera moves forward to zoom in to the receiver. The movement inadvertently shifts the transmitter antenna again , weakening the proximity coupling.  The cutoff is released at 0:07, and LED returns to green.

To avoid mid-air failure, the FrSky XM+ receiver requires putting transmitter on "range testing" mode before hovering in close proximity. This is not needed with Crossfire or R9M receiver, which does not have proximity cutff.  In the pre-prototype, the receiver sits on the pedestal as appropriate for the small, geared motor under 22mm diameter of stater, spaced across the cage. In production, when 4004  direct drive motor is used center in the cage, the receiver signal is severely jammed by the spinning motor. So, production build does not use the pedestal.

Takeoff Procedure With Safety Checks

 Many safety problems can be mitigated pre-mission. The video on the right is tail failure due to propeller glue adhesion slip, which goes into a left turn tailspin at 2:00 and continues until the crash. There was no crash in the 11 minutes between 18:32 and 18:43 . The prop slip is distinguished from the radio loss free fall video in the Failsafe Setup section by a characteristic left turn instead of a right turn with an initial jerk due to Failsafe's sudden zero-collective-pitch setup.

Tail bolting failure has the same characteristic left turn, resulting in twisted tail motor wires and missing bolts after recovering the wreckage. Such a case's tail wreckage is pictured below.
The takeoff procedure with correction for the tail failures follows.
    1. Apply specified torques in the build note on the 2 tail motor bolts and craft's DFC bolts with a hex screwdriver to probe any loose torquing. Fix it if loose. 
    2. With one hand only, use the thumb and index finger to try to turn the tail motor while stopping the tail prop with the middle and ring finger to check glue adhesion. 
    3. Adjust grip clamping force for consistent PID performance with blade draping, ideally at 90-degree tilting.
    4. Plug in the craft battery. Check the rough zero pitch and level of the swashplate. If the servo arm clutch is sprained during the last mission or handling, dial it to correct it.
    5. Position the craft on the takeoff surface with friction that doesn't allow the craft to slide. The blades should not be allowed to scrape grass or thin twigs on the ground because the initial spool can bend the foldable hinges, throw the rotor off balance, and sprain the servo arms. 
The following steps show the OSD percent display of channel 1 throttle in a video clip for illustrative view. But OSD is not required in our base build. The corresponding RF control transmitter LCD point displays are noted next to the OSD percent displays. 
    6. Step back from the craft and power on the RF control transmitter. The video above shows that the collective pitch changes from neutral to -4.8 degrees at 0:10 when the LCD display point of channel 1 throttle changes from 0 to -22.5. The throttle percent shown at OSD goes from 18 to 0. The 0 percentile display refers to the PWM signal at min_check from the RF transmitter, which is a negative collective pitch. The 18 percentile display refers to the actual neutral zero collective pitch at 1500us in the scale from min_check = 1386us to 2000us.
    8. Arm the craft. Gyro calibration can take 12 seconds, as seen at 0:29 of the video above, or up to a minute.
    9. Spool up the main rotor slowly to the hovering RPM at 2/8 stick, as seen in the above video from 0:38 to 0:50, reaching the top red line of the soil color region in the table on the right. Slowly make the spool up so that the craft doesn't capsize due to an unbalanced rotor with folded blades, as seen with the shaking motion in the above video at 0:40. Then the craft should have no movement after the shaking because the friction of the ground overcomes the main rotor torque, and the negative pitch lift force presses down the craft firmly on the ground. 
    10. Switch on stabilization attitude mode with the throttle stick at 2/8 position, as seen in the above video at 0:50. The collective pitch will suddenly become positive 3.3 degrees, as shown as 15.6 LCD throttle point, also shown as 31 percent in the upper right OSD of the video. The craft will swing for a few seconds for computer stabilization to settle.
    11. In the video, raise the collective pitch to 3/8 stick from 0:52 to 0:54. The craft will stay on the ground.  
    12. Raise collective pitch toward 4/8 stick slowly; craft will drift and scratch ground at between 23.5 and 27.4 throttle LCD display points or 38 and 41 percentiles shown in OSD. Average 1/16 up from 3/8 or 25.4 throttle points or 39 percentile in OSD, as shown in the video at 0:56.
    13. If the drift is acceptable, raise the collective pitch to mid stick 4/8 +/- 1/32 stick or between 27.4 and 31.3 throttle points, or between 41 and 44 in OSD, average 29.3 throttle points or 42 percentile, as shown in the sky blue region in the table on the right. The craft will be on the brink of leaving the ground effect as of 0:57 in the video.
So, overall, the collective pitch raises first with 1/4 stick, stops for 2 seconds, then 1/8 stick, stops for 1 second, then 1/16 stick, and lifts off or aborts in 0.5 seconds. For the FrSky r9 lite RF transmitter, it is 8 ticks, then 4 ticks, then 2 ticks. The first stop checks whether the craft has tipped over by severe swashplate leveling error or by too much off-trim, the second checks whether the craft is stable with computer stabilization and off-trim, and the third checks to see if off-trim is desirable.

Accidental Disarming Recovery

The RF controller's arming switch SD (or QX7's equivalent SF) is the throttle cut mixed into channel 5.
Channel 5 RPM control bypass means that flight computer has no modification on it. So, after a throttle cut, nothing prevents main rotor RPM spoolup if the arming switch is flipped back to high. It is true that a motor mixers of a copter(mmix) require throttle below min_check for arming to be successful and subsequently giving ESC PWM a value anywhere close to 1500us. But our craft doesn't have any motor connected to mmix, instead our main motor is treated as a servo with channel bypass, which takes raw RC throttle input that is not subject to arming manipulation. Further more, collective pitch and cyclic and yaw are a servo mixes, taking RC raw input (source 7) and PIDs outputs, not modified by arming, so, nothing prevents the craft from properly fly and land after an accidental disarm-throttle-cut and uncutting throttle (the upper right cell's condition in the above table). So, the solution is to flip the arm switch back after accidental disarm and land the craft. There is no need for slow spool-up because the on-ground slow-spool-up is meant to prevent blade hitting the ground. Here we are already in the air, away form the ground, and not time for spooling.
However, after uncutting throttle, still disarmed, the stick commands are unpredictable in the air.  Our channel 1 throttle is actually collective pitch that is limited in between -23 and 57 points, PWM 1382-1385us to 1785-1792us. Our min_check=1386 and max_check=1886, so only the 8 red-highlighted commands can possibly be activated with low collective pitch when disarmed. And closer look at the remaining 8 commands shows the changes are inconsequential.
The immediate high throttle without slow spool-up risks servo clutch sprain. And in the test video, the descent is faster than usual due to a sprained clutch lowering the collective pitch.

Failsafe Setup

$ grep failsafe dump_all_converged_IoT_hglrc_fd411.txt
set failsafe_delay = 4
set failsafe_off_delay = 10
set failsafe_throttle = 1000
set failsafe_switch_mode = STAGE1
set failsafe_throttle_low_delay = 10
set failsafe_procedure = DROP
set failsafe_recovery_delay = 20
set failsafe_stick_threshold = 30
All time units are 1/10 second. Configurations that are not relevant or unused are crossed out.
The RF glitches for less than 4 tenth seconds will not disarm the craft, nor OSD shows mission statistics. If the RF control signal recovers in 0.4 seconds, RF control resumes like nothing had happened. When more than 0.4 seconds of RF signal loss, the procedure of DROP the craft enters. The craft will drop to the ground if nothing else happens. When the RF signal resumes, the first 2 seconds of the signal is considered dirty and discarded, then a proper recovery with RF control requires a throttle channel 1 signal lower than min_check when flipping on the arming switch. However, in our helicopter IoT platform, the main motor RPM is not influenced by armed/disarmed conditions, so our craft can fly withOUT a proper recovery procedure. So the craft recovered successfully without the main rotor slow spool-up nor flipping any switch on the RF control transmitter, as tested in the first video footage, which disconnected the ribbon cable between the RF control transmitter and the TBS Crossfire Mini module. 

Accidental Manual Spool-Up Mode

The negative collective pitch of the spool-up mode with tailspin somehow results in near-perfect craft inversion. In the footage on the right, the accident occurred at 0:05 during hovering with a hovering throttle (collective pitch) in attitude mode. The recovery is flipping the mode switch to attitude mode, keeping the same throttle (collective pitch) at a hovering level. The altitude drop from flipping the switch to attitude mode to stabilizing altitude is 6 meters.

Summary RF Control Setup

In gyro-only mode, the accelerometer is not used, and the outer loop calculation of PID in flight software is zeroed, so the RF control's trim from the transmitter handset is inappropriate. And so, the roll and pitch RF control mixer should have 2 separate pages for each axis, one with trim, another without trim.

To summarize, with all alternatives considered, the montage of 27 screens of created/edited/confirmed pages after installing OpenTX 2.3.10 is here below. The whole-transmitter-receiver configurations are in the first column and needs to be reconfigured every time a new transmitter or receiver is added. The whole-transmitter configuration pages for file browsers, global functions, and PWM alteration are skipped. The actual per-model configuration pages of non-computerized helicopter setups are skipped. Navigate-thru pages without needing to click Enter are skipped. Pages with all automatically generated known defaults(such as rudder) or no content modifications are skipped. Repeated pages with identical contents are skipped. Notice that the SF switch is the Frsky QX7's equivalent of X9Lite's SD switch, and that QX7's SA and SC are the same as X9Lite's SA and SC, respectively.

The 27 pages don't need to be set up at once. For a hand-launched hovering test, one single mixer page on the left is all needed to map an RPM curve and a throttle pitch curve and add an arming channel mix. As pictured on the left, the bare minimum pages serve the top rows for each mixer to continue building the craft to full capabilities. In the absence of channel 6 flight modes, the default middle 1500us is presumed in the flight computer, which assumes the accelerometer stabilized mission.

Rotor Balancing For RPM 2650

As seen in the video explanation on the right, vibration can have unforeseen net forces on  the micro mechanical components in the gyro chip with unforeseen directions. A build with a clipped blade twitches with a 1-2 second period with the vibration, which was the I term correction for the phantom net forces. 

For this investigation, a second identical crafts with undamaged rotor was built, and both crafts without the rubber dampener washers to intentionally make a slop play on the lengthwise axis. To stabilize the flights, the first craft required tugging the grip toward the side of the blade grip with scratch marks, and the opened gap is visibly larger than the other side of the hub. Yet, the second build had no difference in stability either tugging the grips left or right. The tugging diagnosed the weight imbalance between the 2 blades of the first craft. And the fix was to trim the blade tip of the heavier blade to match the chipping of the other blade. As little as a grain of oat's volume of plastic is enough up upset the balance. Such weigh difference is less than 1/30 of a gram and can not be detected reliably with common scales. And even if a scale can detect the 0.03g weight discrepancy, it doesn't tell whether the rotor grips have manufacturing errors, one grip's bolt hole is farther than another, etc. For example, if the second craft had 0.01g of blade imbalances, the grips could have additional 0.01g imbalances that was tolerated as simulated by the tuggings. 

The permanent solution is to use a 1 inch clear tape about 5cm square area, which weighs about 0.03 grams, to test weighing the blades near the tips and find the most balanced configuration.

The Tarot replacement blades for Trex250 have wildly uneven bending and are hard to find balanced pairs even with multiple purchases.

Change Rotor RPM With Locale/Weather

According to the NASA education page screenshot below on the left, density affects blade lift linearly; in the screenshot below on the right, the lift is proportion to RPM to the square power. Using binomial approximation, blade airspeed RPM should be adjusted by half the percentage of air density change with weather reports.
Overclocking RPM can cause craft instability and/or vibration because the flight computer PID gain is tied to rotor angular momentum and proportional to rotor RPM.
Our reference condition is the middle of the Fahrenheit scale of 0-100, 50 degrees Fahrenheit, 10C temperature for RPM 2643 at -26 throttle points in the -100-to-100 points scale of the 1000us-2000us PWM signal range. Weather temperature and pressure can change air density from normal conditions by 11%. For example, a typical winter temperature weekly low of -10C produces air density 293.0/(293-20-10)=1.11 times the reference air density around Boston suburbs.  Barometric pressure generally does not affect air density as much as temperature; for example, a 13% pressure change from 30 inHg to anything below 26 inHg would approach world records for the eyes of an intense cyclone. On the other hand, locale consideration for elevation, many cities above the elevation of 3000 feet, such as Tucson, northeast of Los Angeles County, El Paso, Denver, and Honolulu, can reduce air pressure by 11% by altitude.

However, the simple square relation doesn't consider turbulence effects with Reynold's number, and the simple square relation consistent for both drag and lift in response to blade speed change would contradict the deviation of Cl/Cd ratio curves when Reynold's number changes. The effect of blade speed is more powerful than the second power proportion because the higher the blade speed, the higher Reynold's number and the higher the Cl/Cd ratio. So, we will use a spreadsheet table on the right for RPM adjustment, approximating the blade speed effect to the 2.5th power.

In the ESC scaling/calibration section, we set the both the low and high PWM points in Betaflight. Here, we tune the high point PWM for actual RPM with BLHeli Configurator of the actual ESC with Android's Headspeed Tachometer. To get a sense of how many PWM calibration point need to change for the 4004 motor, consider increasing RPM by 50 from 2643 to 2693; the new scaling size is 572;  50000.0 / 12.0 * 74.0 / 200.0 * 1000.0 / 572.4 = 2693. So, a 11 PWM change from the original 583 produces 50 RPM change, a 1 to 5 ratio. The picture on the right, focusing on the 2600-2700 RPM region, is an experiment result of increasing PWM calibration by 4 points with 4004 motor that reduced RPM by about 20 from the previous 2690 average RPM to 2670 average. It was found in the ESC setup section screenshots that the BLHeli Configurator actually only accepts PWM calibration point changes by multiples of 4, which means that an RPM error of less than 20 can not be improved with the 4004 motor. 

In the Swashplate Setting section, we adjusted Betaflight's Servo tab PWM range/center based on a visual inspection of the rotor hub. The PWM range/center should be fine-tuned to produce a consistent climb rate among drones of a swarm of deployment now that RPM is precisely set. To understand how many PWM range/center points changes are needed after a test hovering, consider that if the craft hovers at 31.3 LCD display points in the transmitter display, 2 points above the theoretical 29.3 LCD display points, the collective pitch angle error is 6 degrees / 29.3 points * 2 points = 0.42 degrees too low. But, as discussed in the swash centering section, the servo only has a resolution of 0.83 degrees. Increasing the center PWM by 10 us and 0.83 degrees will make the craft hover at about 2 points off at 27.4 points, and no improvement can be made. The 31.3 points position is at 17/32 stick position and is 1 ratchet tick above the stick center position. This means that 1 ratchet ticks off center can not be improved. For another example, if it hovers at 28 points in LCD display, off by 29.3-28=1.3 points,  lowering the PWM central by 10us will make it hover at 28+4=32 points, which is off the center by 32-29.3=2.7 points, worse than without overcorrection.

IoT Video Monitoring

The AIY Vision kit with Raspberrypi image aiyprojects-2021-04-02.img allows setting up Raspberry Pi without any HDMI monitor or FTDI terminal connection. Instead, an Android app Google AIY Projects gives your WIFI hotspot's password to the Raspberry Pi with Vision Bonnet board, as shown in the following screenshots.
Once the Raspberry Pi Linux system receives the WIFI password, it connects to the WIFI hotspot that assigns a DHCP IP address to the Linux system. From then on, the Raspberry Pi Linux system's pre-running SSH server accepts connection from any computer on the WIFI network.

Raw video transmission data has too much delay and is impractical. Instead, the H264 compression is a good balance between processing delay and transmission delay. The setup in the craft follows (the AIY Linux system image has a default video transmission service, "joy_detection_demo", incompatible with the 1.6-gram, 160-degree FOV camera and needs to be disabled). 
pi@raspberrypi:~$ sudo apt install gstreamer1.0-tools
pi@raspberrypi:~$ sudo systemctl disable joy_detection_demo
pi@raspberrypi:~$ cat .bash_profile
sh /home/pi/
pi@raspberrypi:~$ cat /home/pi/
raspivid -t 0 -rot 180 -b 1700000 -w 640 -h 360 -o - | gst-launch-1.0 -v fdsrc ! 'video/x-h264,width=640,height=360' ! h264parse ! queue ! rtph264pay config-interval=1 pt=96 ! gdppay ! udpsink host = port=9000
The App in Android is Raspberry Pi Camera Viewer by BigDotSoftware. Above is the setup, with the Android phone as the WiFi hotspot, itself at IP address, as the example, which is the target of h264 video streaming.
The Viewer app must start receiving the video data stream before the video transmission starts because the app can not decode the video data stream in the middle. In the video, the Viewer app starts at 0:02, and you can hear the craft powering up at 0:04 with ESC's beeping sequence. The receiving of the video data stream starts at 0:09 before video data transmission starts at 0:48. 
This video also reveals the landing process with a line of sight, heading away from the pilot while descending. 

No comments:

Post a Comment