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 Software Stabilization Precedence

The racing drone flight computer software is betaflight_4.2.5_STM32F411.hex (483267 bytes) when you choose either the generic STM32F411 or HGLRCF411 flashing option in the Betaflight GUI. The configuration is here.
The flight computers can have 3 operating characteristics, passthru-manual, accelerometer-attitude, and gyro-rate. But, manual mode is not operable as seen in this video.
0:01 tilt right and backward
0:02 attitude mode to rescue
0:03 tilt right and forward
0:04 to attitude mode
0:05 tilt left straight
0:06 attitude mode
0:08 tilt backward
0:09 attitude mode
0:10 tilt forward
0:11 attitude mode
0:25 landing approach too high
0:35 backing off far and fast
0:40 good landing approach
0:53 touch down.
So, the OpenTX transmitter should engage a stabilization mode before the takeoff. 

The problem of erratic, forceful PID Integral over-correction is common through out nearly all helicopter flight computers. Example of the same problem is with Blade 230, 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 air, but the ground contacts force the craft attitude out of the planned flight envelope. To overcome this problem, we cancel the PID process and use passthru-manual mode during spool-up. The spool-up RPM should be controlled by the pilot by the throttle proportion on channel 5 to ensure safety, and the pilot's control should not be relinquished without the pilot's explicit input on channel 6 switch, even when the throttle position reaches full spool-up. The reason for this specific channel switch assignment and the alternatives are discussed in in-depth spool-up note  . The spool-up throttle channel setup is pictured here on the right. 

To complete solving the problems of previous 2 paragraphs, we configure the flight computer to give the passthru mode a channel switch, and this channel switch for the passthru 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. We hilight the disabling of accelerameter and/or gyro sensors blue. The flesh color underneath all flight modes is for the same set of PID coefficients throughout all modes.

To convert the fraction system to flight computer's PWM timing system, Betaflight/FD411 need to anchor the end points 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 this 3 profile-modes on both flight computer and 3 modes on transmitter. There is no such thing of 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 a takeoff) in the field-fault setting, pilot may forget to switch channel 6 to 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. Video of this crash is on the upper right.

When transmitter and flight computer are out of sync, the takeoff can happen in gyro-rate mode. This happens even after a hand-tethered hovering test because the rate mode hovering can be successful without pilot knowing that the modes are out of sync, for that gyro-rate mode does have stabilization characteristics. Then the actual takeoff will, again, crash badly due to the high craft momentum nature of gyro-rate mode. Video of this gyro-rate 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, you may think that the PWM for profile switching needs more than 33%, say 40%, weight to expand over the 1/3 spool-up region at low position. And that is true for a 2-position switch, but Betaflight would interpret the high position (2011-1500)*0.4+1500=1704, in gyro-only setting because the weight scaling is centered at 1500, not 1000, as depicted in the lower right diagram.

How about tieing stabilization mode with arming the craft? The problem of 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 RF transmitter just to disarm complicates work procedure.

Motor Multi-Rotor Software

During motor selection, it was discovered that the 250 gram craft hovered at 80/200 throttle, RPM 3*3.35*660*80/200=2650, 6.2 degree collective, with the 2808 660kv motor, all under 3S battery, as pictured on the near right. The pre-prototype motor selection further involved testing hovering with 4.8 degree collective and 94/200 throttle for the same motor with the throttle curve on the far right, all with 3S battery. The maximum punch/climb at 114+7(compensation knob added 7 points for voltage drop)/200 throttle induced oscillation on the normally stable craft indicating that RPM exceeded hovering RPM and craft PIDs needed scaling down subsequently for the pre-prototype craft. The production motor selection further switched motor to 4004 400kv and utilized ESC capacity scaling for the same punch/climb test, equaling (114+7)x660/400=200 full throttle. That verified that both motor had sufficient, equal, power throughput for better-than-steady-RPM maximum punch/climb.

The simplest, one-bend throttle curve had only 5 points in a pre-prototype build, as the picture on the right. The pitch curve is super-imposed on the throttle curve. But the region between the 2 red dash lines had tail punches, indicating insufficient RPM brought on by variable RPM configuration. So, production is determined to require fixed-RPM with ESC governor. The next question is which soaftware among MAIN, MULTI, and TAIL to use.
So, it was tested changing main rotor ESC from MULTI to MAIN code with governor disabled, it results in a "spool up" delay of roughly 3 seconds whenever throttle-up and resistance is detected. That means that when you descend too fast approaching an obstacle, you can't punch up the craft immediately because the ESC senses blade foil drag with throttle-up and gives small increments of torque over 3 seconds to prevent damage to the helicopter pinion/gear. In the gear-less helicopter, there is no resistance reduction gearing, so the ESC needs to apply the torque regardless of resistance, just like a multi-rotor system. The solution is shown in BLHeli ESC assembly code,


, which shows that MULTI code has all the MAIN code functionalities except 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 is used for both the main and tail rotor of our IoT build. 

The configuration for the main rotor motor using MULTI code needs small P-Gain 0.50 to prevent oscillation (yes, motor RPM can oscillate producing audible noise), I-Gain needs to be high at 3.00 to track RPM precisely, Startup Power needs to be the lowest so that spool-up does not capsize the craft with unbalanced(blades not stretched fully) high torque. Overall as screenshot.
To configure the ESC, we use Omnibus F4 computer's passthrough USB-to-UART connection. And we use BLHeli configurator on Chrome browser. The configurator is not listed in chrome web store, instead, google it "chrome web store blheli" and add it. To access USB tty device, chrome needs to be restarted as root user with command "google-chrome --no-sandbox", then browse chrome://apps to start the app. Alternatively, run chrome as regular user and
# chmod 777 /dev/ttyACM0
Safety precaution dictates that ESC battery power should be applied last after all connection/software are set up, and ESC battery power should be first one to be torn down after any configuration/software flashing. With that in mind, power on Omnibus computer by connecting micro USB cable, connect only the tail ESC's signal cable to a PWM out header of computer, which is on the 2nd to 5th rows. Start the app and click "Connect" with default baut rate and auto-detected tty port. The computer now goes into USB-to-UART adapter program. But, wait, there is sometimes a 1-minute delay for the program switch to occur. Now connect ESC's craft battery power, then click "Read Settings" to actually connect to the ESC computer. If the "Read Settings" button is not available, it is still in the 1-minute period. After flashing ESC, tear away ESC's craft battery power plug first, as the safety precaution. Then tear down software/other connections. If you don't tear away the power, when the program switches back to Beta Flight computer, the motor will spin up to compensate craft attitude orientation as a quadcopter motor.


In production, with RPM PID computer, without ESC capacity scaling, the craft with the 12-node 2808 motor needs 2650RPM / ( 50000RPM / 7 ) x 200poionts = 74 points level in the 0-200 scale of the transmitter for the same RPM as the pre-protytpe. Here the 200 point scale is assumed to perfectly corresponds to 1000us to 2000us RF transmitter output, and if RF transmitter uses 989us to 2011us range, RF transmitter needs scaling the channel by (2000-1000)/(2011-989)=98%. The 50,000 max RPM is seen in the above github page of ESC source code. 1/7 fraction is attributed to the 14-pole brushless motor compared to elementary 2-magnet motor. In the production model, the battery pack is further reinforced to 4S, giving 25% extra power budget for future improvements on fuel-economy/G-force-performance optimization. Incorrect RPM is the first cause of the 3 equally significant sources of craft instability and/or vibration because the flight computer PID gain is tied to rotor angular momentum and proportional to rotor RPM. For the 24-pole 4004 motor, to use the same throttle curves from transmitter, the PWM needs to be scaled from the original range of 1000us x 7 / 12 = 583us. 

The scaling, colloquially called calibration, configurator needs tentative(don't click Save in the GUI) servo 6(the pass-thru servo) MID/MIN set to the high position (2000us or 1583us, actual number scaled according to tachometer measurement).
The tentative neutral position only takes effect after you click on a different field in the GUI after entering the neutral PWM number, as screenshot above. Also Live mode is needed in the Servos GUI. Then setting back to 1000 to save the scaling.
This "calibration" does not need BLHeli configurator. In fact, the motor is not configured as motor in mmix. The motor can not be controlled with Motors GUI because Betaflight motor mmix is tied to throttle channel T, which is collective pitch channel in our IoT build after all alternatives were ruled out.


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

To configure the ESC, the tail SERVO esc needs to be temporarily be recognized by the ARM computer as the MOTOR 1 , as pictured here below, because BLHeli configurator only accepts motor ESCs.


Then after saving and rebooting, BLHeli configurator can proceed.


The reason we don't tune the IoT flight computer's PIDs output is because this problem is hardware specific to 4S and 20A ESC and 4500KV motor. Our IoT platform deploys to large scale accommodating TAIL ESC hardware combinations, so hardware specific problems should be solved at hardware level.


Collective Curve For Maximum Efficiency

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


Our rotor RPM for level flight missions 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.  So, for 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 = 15 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 15x2=30 points at mid throttle stick as shown picture-in-picture above at the bottom right corner. 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(throttle-PID-scaling) only responds 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 acrobatic 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. 

Endurance with the optimal pitch for the optimal fuel economy lift-to-drag ratio is 35 minutes with HD video recording, compared to 23 minutes of DJI Mavic Mini test at https://www.youtube.com/watch?v=aBXS2m9xwXc .

Level swash plate to prevent tip-over during spool-up and the technique 

Remember, our spool-up is performed in manual mode. For the longitudinal axis, if the swash banks to one side, there is no PID correction by the computer and there are no heavy battery nor long tail lever on this axis to counter the tipping. Use a zip tie with half cut ending as the picture blow on the left to check that all 3 pillars nearly touch the servo linkage. Notice that this zip tie should only be used after checking that there is enough room between the swash and the hub after booting up the flight computer. To check the centering of the swash plate, check the top of the blade bolting as pictured on the right. 


The procedure starts out putting the craft on manual mode cyclic control and keep the transmitter off so that all servos are at neutral positions, then use a zip tie to check the 3 points of swash plate pillars. The first stage of the procedure is to modify the F4 computer center points and modify the direction of servo2 and servo3 from factory setting that assumes the custom servo bracket is used. 



In the second stage, the technique to check the swash plate center is to hang the blades vertically, then grab and move the DFC links up and down in the craft's perspective. The scissoring action of the blades needs to be evened on the 2 direction of movement. In the following video, the swash plate is overly high because the far end blade is pitching up more than pitching down, which means that all 3 servo PWM center value needs to be lowered. 


Once the center values of servo PWM are adjusted to level the swash plate, in the third stage,  the extreme ends of the PWM range are +- 500 of the center values. For the alternative servo of Spektrum 2070 tail servo, the PWM range from the center is 500 x 12mm / 13mm x 83.5deg / 83.8deg = 460.

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 ESC 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  288us PWM change. That means that when attempting to set the high PWM to larger than 2144us, you might as well dial the arm position up 1 spline and decrease PWM on top of 2150-288=1862us, which will set the high PWM in the safe zone. 

Input s-bus PWM signal does not need calibration because it is calibrated in transmitter with stick calibration to ensure high precision.

In summary, the difference between factory txt file and operating "diff all" output file is the 1 line addition of hardware ID and 3 lines of 3 servo PWM ranges
test@laptop201:~$ grep -v ^$ tmp.txt > tmp2.txt
test@laptop201:~$ diff Downloads/Converged-IoT.txt tmp2.txt
11a12
> mcu_id 006300543239510e34393435
27,29c28,30
< servo 2 1000 2000 1500 -100 -1
< servo 3 1000 2000 1500 100 -1
< servo 4 1000 2000 1500 -100 -1
---
> servo 2 1040 1960 1500 -100 -1
> servo 3 1050 1970 1510 -100 -1
> servo 4 988 1908 1448 100 -1
 

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 Checklist

 There are safety problems that can be mitigated pre-flight. The video on the right is tail failure due to prop slip, which goes into left turn tail spin at 2:00 and continues until crash. There was no crash in the 11 minutes between 18:32 and 18:43 . It is distinguished from the radio loss free fall video in the Failsafe Setup section by a gradual left turn, instead of right turn with an initial sudden jerk.

The correction for the tail prop slip is for pilot to check the prop loose before every flight.

1. Apply retaining torque on the craft's DFC bolts with a hex screw driver to probe any loose torquing.

2. Use thumb and index finger to turn tail motor while stopping the tail prop with middle and ring finger to check detached adhesion. 

3. Adjust grip clamping force for consistent PID performance with this quick check

. The quick check approximate the flexibility as shown in the picture here,

, which a 100 gram weight bends the blade to nearly touch the boom. This grip force also prevents tail strikes. 


3. Power on goggles and start recording. This needs to happen before powering on craft because once you power on craft, there is a sense of urgency to take off ASAP to use maximum battery life, and you often forget to record the video footage that is valuable for locating craft after crash.

4. Plug in craft battery. Swashplate leveling check. As shown in previous topics, the transmitter needs to be ready for takeoff as soon as it is powered on, swashplate checking needs to be done while transmitter is off.

4. Check that FPV recording is in progress in the goggles. 

5. Check rough zero pitch and rough level of the swashplate. If not level and centered, dial servo arms to correct it.

6. Position the craft on takeoff surface. Blade should not be allowed to scrape grass, even with very insignificant thin twigs, because the initial spool up can bend the foldable hinges and throw off the rotor off balance and improperly dial the servo splines.

7. Put on FPV goggle. Turn on transmitter.  

8. Arm the craft.

9. Spool up the main rotor one click at a time to full hovering RPM at 1/8 stick. The craft should have no movement because the friction of the ground overcomes the main rotor torque, and the collective pitch is too low to counter craft weight that presses down the craft firmly on the ground. Slowly make the spool up so that the craft doesn't capsize due to unbalanced rotor with folded blades.





10. Continue throttling up to 1/4 stick. The craft should tilt on the cyclic axis and tail wag is expected. 

11. Between 1/4 and 1/2 stick, the craft will lift off with side way movements because the ground friction is suddenly releases. So, pilot should concentrate on the cyclic stick correction during this lift off. The lift off happens around 40% throttle stick even though the craft hovers at 50% half stick due to ground effect boosting lift efficiency. 

Failsafe Setup


Failsafe Mode free fall video below at 0:03, which initially turns the craft to the right due to motor bell magnets dragging along the stater that is attached to the fuselage.
We have to keep the betaflight internal arming signal high during failsafe because it is the reason the flight was recovered at 0:18 . Further more, to prevent accidental disarming mid-flight, , arming signal from the radio transmitter needs to be also stay high during most of the flight with any mode-PID-profile switch position when throttle position is not zero. 

  
The Failsafe flight characteristic is predictable in the failsafe test video because we set all servos to fixed 0 collective and motor to 0 throttle in Converged-IoT.uav . The predictable behavior allows recovery at 0:18 .










Landing Procedure

Acro+ and rate mode landing often results in capsizing due to the drifting nature of the rate mode as seen in the last few seconds of the video on the right when the pseudo touch down at 1:43 has a remaining altitude, maybe 1 foot, and the drift scraped the grass at 1:45 resulting in capsizing.

Aborting landing in rate/acro+ mode also often results in crash due to altitude drop with the big maneuvering nature of rate mode. Rate mode spot landing is often nearly impossible even fly line of sight. Here in the following video, the landing approach, trying to avoid the fence, is deemed to high at 0:05 in the video here below,
and the go-around at 0:06 results in steep increase in craft speed and altitude drop, resulting in crash. Seemingly smooth touchdown in rate mode can still capsize due to the general high speed approaching to the target in the last video on the right.
Forgetting about switching to attitude mode can occur during high work load situations such as combating high wind while locating a obstacle'd landing patch impromptu.
Flipping SwitchC to attitude mode for final approach should be trained into the pilot's reflex because attitude mode landing is appropriate in nearly all circumstances even the most unlikely ones, such as the following example.
 The trick to have near 100% success landing is to trim the aileron and elevator stick in attitude mode indoors to near zero drift. The trim for attitude mode is to compensate the imprecise/inaccurate attitude mode accelerometer leveling. In rate mode and acro+ mode, the accelerometer is not used, Outer Loop zero'd, so the trim is not appropriate. To achieve switching off the trim, the flight mode setting needs  to be as the picture on above, which switches off any trimming when SwitchC is in rate mode or acro+ mode.
 



To summarize, with all alternatives considered, the montage of 42 screens of created/edited/confirmed pages after installing OpenTX 2.3.10 is here below. The whole-transmitter-receiver configurations are in the first 2 columns and need to be reconfigured ever 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 pertain to non-computerized helicopter setups are skipped. Navigate-thru pages without needing to click Enter are skipped. Pages with all automatic 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.










* see notes


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

When launch-from-ground and gyro-only-profile are needed later in the build, the other mixes are then appended to the bottom row for each mixer. The added bottom rows are constricted with switch positions. *Finally, the disarm guard of channel 7's second page should be added last as an optional mix.


Avoid flying without arming

Nothing prevents RPM spoolup and adding collective pitch. Without arming, the stick commands are unpredictable during flight.

Video Monitoring

pi@raspberrypi:~$ uname -a
Linux raspberrypi 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l GNU/Linux
pi@raspberrypi:~$ cat .bash_profile
sh /home/pi/stream.sh
pi@raspberrypi:~$ cat /home/pi/stream.sh
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 = 192.168.1.1 port=9000
pi@raspberrypi:~$



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.

Tuning Rotor RPM

As little as extra 3% RPM is noticeable in the video here, (RPM 3215 versus 3145)


This happens because BLHeli ESCs have dithering error margins, and dithering is a necessary feature to avoid motor oscillations/vibrations. All these mean that a good tachometer, such as Android's Headspeed Tachometer, is needed for tuning precision flights. But the PWM marginal error doubles affects on PID loops by servo outputs. When a board needs 2% throttle correction, the transmitter likely needs 4 points change on the throttle curves. We add to the mixer page of OpenTX to add/subtract up to 10 points by a potentiometer.
Weather temperature and pressure deviates air density from normal condition by 7+2%. According to NASA education page, density affects lift linearly. RPM tuning should linearly counter the air density change even though RPM speed changes the lift by the square power, as explained in build notes.
In the Headspeed App, the attitude mode, 85 point RPM fluctuates and has extra 2% elevated RPM due to dithering of the ESC. The -5 point RPM has flat value on target by calculation, 6250x80/200=2500. The +5 point RPM is dithered downward by 1.5% at 6250x103.5/200=3234.



Transmitter Setup Wizard 

Betaflight does not have a wizard for transmitter setup, and the throttle low limit is the same as other channel's low limit. We manually set all channels' low PWM to 989us even though they can produce 988us PWM because arming code dictates that throttle needs to be lower than the channel's low limit. In LibrePilot wizard, the Collective input value is not isolated when the wizard collects Throttle input value, resulting in a mix-up of the 2 inputs. Our production Converged-IoT.uav has the fix. It was fixed by manual entering channel numbers after wizard finished its work. The arming dictates that throttle channel needs to be no higher than, neutral level PWM, but low limit needs to be lower than neutral. Librepilot has individual channels' low limits, so, we set low limit to 0 to satisfy the second condition. And we set the neutral to 174 because the throttle output to ESC is scaled from neutral to high. In either case, setting the throttle point closest to actual TX signal's low point gives most precise RPM output.