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 With 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 Configurator. The configuration is downloadable here dump_all_converged_IoT_hglrc_fd411.txt. The Configurator can be the latest version in Linux with full GUI functionalities or 2018's v10.4.1 in Chromebook with CLI for loading/saving changes and GUI for viewing.
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.
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 is common throughout nearly all helicopter flight computers. An 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 the air when rotor RPM is sufficiently high, 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 the 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 the in-depth spool-up note. 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. We highlight the disabling of the accelerometer and/or gyro sensors in 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 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 these three profile-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-rate mode. This happens even after a hand-tethered hovering test because the rate mode hovering can be successful without the 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 the gyro-rate mode. The 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% 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

During motor selection, it was discovered that the 250 gram craft hovered at 80/200 throttle with the optional Oxy2 210mm blades, RPM 3x3.33x660x80/200=2640, 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 from 2808 660kv motor to 4004 400kv motor and utilized ESC capacity scaling for the same punch/climb test, equaling (114+7)x660/400=200 full throttle. So, the design phase verified that both motors had sufficient power throughput 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 changing main rotor ESC from MULTI to MAIN code with governor disabled, it resulted 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 answer is shown in 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 main and tail rotor of our IoT build for simplicity. 

To configure the ESC, we use the FD411 computer's passthrough USB-to-UART  connection program with BLHeli Configurator. To access USB tty device, the program needs to be started as root user. For the passthru program to work, MOTOR 1 pin needs to be temporarily assigned to the SERVO pin of main motor(SERVO 5 in CLI) or tail motor(SERVO 4 in CLI). 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 flight computer by connecting micro USB cable, start the BLHeli app and click "Connect" with default baut rate and auto-detected tty port. The computer now reboots into 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 Inernet connection is available but software web site 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 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 with motor software, 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 BetaFlight software, the motors will spin up to compensate craft orientation or spin up to match unintended RF transmitter command signal, posing great danger.

Yet another question is whether to use fixed-RPM governor. The configuration for the main rotor motor using MULTI code takes advantage of the RPM governor instead of alternative channel 5 mixers that need to compensate voltage drops, scale with collective pitch, and match up cyclic maneuver demand for torque. The governor 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.


In production, with RPM PID computer, without ESC capacity scaling, the craft with the 12-node 2808 motor needs 2640RPM / ( 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, such as Frsky's X9 Lite or QX7, RF transmitter needs scaling the channel by (2000-1000)/(2011-989)=97.8%. 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. This battery change does not need RF throttle signal change with governor'ed RPM control. However, in either battery setups, without tuning and verification, incorrect 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. For the 24-pole 4004 motor, to use the same throttle curves from transmitter, the PWM needs to be scaled from the original span to 1000us x 7 / 12 = 583us. The scaling is performed in GUI.
Channel 5 is configured as a "servo 6", counting up from 2, bypass in the GUI. In the CLI's servo section (not  resources section, not smix section), the fifth channel is specified as 4th channel counting from 0th in the last parameter; in the GUI, the 5th checkbox 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 (2000us or 1583us, actual number tuned according to tachometer such as Headspeed Tachometer of Android) in the "Live mode". 
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. The scaling is finalized when 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.

The tail's 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 a 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 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 heading and the actual heading is too large. At 0:09, the tail PID resets allowing a 360-degree turn. At 0:12, the tail spools up successfully.

It was noticed that TAIL software has a default of 1.2 Startup Power, so, the MULTI software simply replicates the property as the screenshot below, which shows that 0.125-1.25 is a good range for quick catchup of motor spin after a prolonged idle.


We use the same PID tuning for TAIL software as with MULTI software. The reason we don't change the PID tune in the IoT flight computer is that this problem is hardware specific to 4S and 20A ESC. Our IoT platform deploys to large-scale accommodating TAIL ESC software or other hardware combinations, so hardware-specific problems should be solved at the hardware level, not at software PID.

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 takoff and landing, not with the spool-up throttle curve.  


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.   
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 = 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. 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 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 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, 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.

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

 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, as part of the procedure below.

    1. Apply retaining, soft 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 blade draping at about 90 degrees tilting.
    4. Plug in craft battery. Check rough zero pitch and rough level of the swashplate. If servo arm clutch slipped in last flight or during handling, dial servo arms clutch to correct it.
    5. 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 the rotor off balance and cause servo arm clutch slip. 

  
    6. Step back from craft and power on RF transmitter. Collective pitch will go from neutral to -4.8 degrees, as seen in the video above at 0:10 when throttle shown at OSD upper right corner goes from 18 to 0. The 0 percentile display refers to the PWM signal at min_check from RF transmitter, which is a negative collective pitch. The 18 percentile display refers to true neutral zero collective pitch at 1500us in the scale from min_check = 1386us to 2000us.
    8. Arm the craft. It can take up to 12 seconds for gyro calibration, as seen at 0:29 of the video above.
    9. Spool up the main rotor slowly to full hovering RPM at 2/8 stick, as seen in 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 unbalanced rotor with folded blades as see 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 lift force presses down the craft firmly on the ground. 
    10. Switch on stabilization attitude mode with throttle stick at 2/8 position as seen in above video 0:50. The collective pitch will suddenly become positive 3.3 degrees, also shown as 31 in the upper right OSD of the video. The craft will swing for a few seconds for computer stabilization to settle.
    11. Raise collective pitch to approach 3/8 stick or 36 in OSD from 0:52 to 0:54 in the video. The craft will stay on the ground.
    12. Raise collective pitch from 3/8 stick toward 4/8 stick, Craft will lift off with ground effect at between 21.5 and 29.3 throttle points ,or 36 and 42 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/16 stick or between 25.4 and 33.2 throttle points, or between 39 and 45 in OSD, average 29.3 throttle points or 42 percentile, as shown in the sky blue region in the table on the right. Craft will hover freely  as seen at 0:57 of the video.
So, overall, the raising of the collective pitch goes first with 1/4 stick, then 1/8 stick, then 1/16 stick. For the FrSky r9 lite RF transmitter, it is 8 ticks, then 4 ticks, then 2 ticks. First stop check whether craft has tipped over, second stop checks the craft is stable with computer stabilization, and third check see if drift is acceptable.


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 .

Accidental disarm videos
https://www.youtube.com/watch?v=yOUkg2uYwlA

https://www.youtube.com/watch?v=yOUkg2uYwlA















Accidental Manual Mode

The negative collective pitch with tail spin.

Accidental Disarming

The RF controller's arming switch SD (or QX7's equivalent SF) is actually the throttle cut, mixed in to 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. Further more, collective pitch and cyclic and yaw are a servo mixes, not modified by arming, so, nothing prevents the craft from properly fly and land after an accidental disarm and quick rearming (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.
However, in the brief moment between accidental disarm and quick rearm, the stick commands are unpredictable during flight.  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 the sudden erratic behavior of the craft with accidental disarming startles and prevents the pilot from giving the RF transmitter sticks any large input.

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.














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 an RPM curve and a throttle pitch curve and to add an arming channel mix. As pictured on the left, the bare minimum pages serve the top rows for each mixer for continuing to build 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 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.

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

Change Rotor RPM And PIDs With Weather

A good tachometer, such as Android's Headspeed Tachometer, is needed for tuning precision flights. Ideally, the 2 fixed RPM points from RF transmitter of 74 and 88 produce RPM 2643 and  3143 respectively, and any deviation needs to be corrected with ESC signal scaling ("calibration"), but the RF transmitter's AUX output MAX setting can be used as a shortcut to modify the RPMs. 
According to NASA education page below on the left, density affects lift linearly. RPM tuning should counter half the percentage of air density change because RPM speed changes the lift by the square power, as explained in build notes. To get a sense of how many RF transmitter points need to change, the below picture on the right has the experiment of changing RF transmitter points on the AUX channel. The non-linear correlation between actual RPM and RF transmitter points (3129x1.05=3285!=3230=3129x1.04) means that the calculated RF transmitter points only deviates 1% of RPM and 2% of force, which can be safely discarded. But the initial scaling ("calibration") still needs tuning. It's just one-time tuning for all weather.

Weather temperature and pressure deviates air density from normal condition by 7%+2%=9%. Our normal condition is gas chemistry standard condition at 25C temperature. So, at cold temperature, such as -9C , the RPM needs to be reduced with factor 1 - (1 - 264 / 298.0) / 2=0.943 , 2492 and 3058. So, RF transmitter point should be roughly 0.943x74=70 and 0.943x88=83 points.

Changing PIDs are only for the tail motor that has no RPM tuning. PIDs are shipped with 3 level with our product, and default is the middle level.







No comments:

Post a Comment