Thursday, September 6, 2018

Converged IoT Platform Operating Notes

Stabilization Mode Precedence

The Matek/CC3D is set to have 3 operating characteristics, passthru-manual, accelerometer-attitude, and gyro-rate modes.
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 channel 6 mode switch should be set in the radio transmitter to skip the passthru-manual mode to give stabilization characteristics whenever the platform is operating. The Betaflight software gives the passthru-manual flight characteristic an independent transmitter channel control, so the 3 position channel has 3 equal PWM fractions of the full 3-position switching PWM range. Each fraction for a flight characteristic, as the pictured below. The CC3D software does not have an independent transmitter channel control for the passthru-manual mode. The 3 different flight characteristics need to shared the PWM rationing with the passthru-manual mode, resulting in each having a 1/4 fraction of full PWM switching range. To find the ranges of PWM that the equivalent flight characteristics overlap, we find the common denominator of the 2 fraction system bases to be 12. And the overlapping ranges are 3/12-4/12 , 6/12-8/12 , and 9/12-12/12 . The OpenTX transmitter channel 6 can be configured to fit the 3 positions to the equivalent flight characteristic sets between Betaflight and Librepilot flight software as pictured. To find the PWM center points for the overlapping ranges, we double the common denominator to obtain twice precision. Then the center points for transmitter to switch to is the middle points, 7/24, 14/24, and 21/24.

To set PWM signal points and ranges for the fractions, Betaflight/Matek need to anchor the end points to the nearby 25 points of the 988us-to-2011us range, which is the range the OpenTX can reliably produce by Matek, as pictured below on the right; Librepilot/CC3D needs setting them to the 174us-1810us range because CC3D interprets the received signal with formula,
1.6 x ActualPWM - 1407 = interpreted value.
The OpenTX offset points between PWM range center and switching center is (14/24-6/12)x200points = 16.6 points. The OpenTX scale percent of the switching range of the full PWM range is (21/24-7/24)x100percent = 58.3 percent.


We can not remove the passthru-manual mode and rely on failsafe's neutral Pitch-Roll PWM setting for swashplate centering tuning, because the swashplate is subject to PID compensation, giving cyclic movements in real-time, even in failsafe status, for the 3 profiles-modes flight characteristics are still in effect. Checking swashplate leveling is needed after each hard landing and servo arm dislocating/re-positioning. To reduce pilot/operating error, we consistently use 3+1 profile-modes on flight computer and 3 modes on transmitter. to reduce pilot error and setting errors. There is no such thing of a reliable, field-improvised easy transmitter setup.

When the first mode is not skipped in the pre-prototype setting, as the lower cyan roll of the diagram below for CC3D, pilot may forget to switch 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 can be very bad 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 above on the right.  


Setting up 2 flight modes, in-field, in transmitter is also a bad idea. With Matek, we can be tempted to have a cruise-only mission with a single 2-position switch for aux2-channel6, for both arming(0/4-1/4 disarmed and 1/4-2/4 armed) and for accelerometer-attitude activation. In the field, you may think that aux2 needs to be larger than 1/4 to arm the craft, so you set the OpenTX channel weight to 1/3=33%. And in that case, Betaflight would interpret 33% PWM , 1326us, in gyro-rate mode, because gyro-rate mode starts at 1325us. So, you would take off at gyro-rate mode, surprised, confused, and crash, similar to the video above on the right.

CC3D has an alternative configuration to give stabilization precedence by arming the craft. But, we should not rely on transmitter disarming the craft to go into passthru-manual mode for swashplate maintenance. The craft is created by human and is equal to human, and it should be able to have a working mode that does not rely on human operated transmitter. The transmitter should be able to lose power at any time, and the passthru-manual mode should be fully functional. You may be tempted to workaround this problem by setting the craft to disarm itself whenever the transmitter loses signal, but this endangers the flight recovery after a brief signal loss because the disarmed craft will need re-arming midair to regain motor power, and re-arming loses the precious time in the middle of a crash landing. Humans created machines, but that doesn't mean that humans are superior to machine, and it doesn't mean that machines are superior to human. 

In the case of using arming to enter stabilization mode, the craft can not have swashplate maintenance once the craft has been armed after bootup; in the case of using independent aux channel to enter stabilization mode, the swashplate can be centered for checks and adjustments any time when transmitter is powered off. It is better when humans and machines can be independent of one another.

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.

Acro+ And Rate Mode Throttle/Pitch Curves

For the acro+ and rate modes, to enhance the maneuverability on the expense of fuel efficiency, we set the hovering pitch to slightly lower than 5 degrees but higher than 4 degrees between the orange and green lift curves, so that the lift slope doesn't turn steep, which translates to harder hovering. Testing hovering with the new collective pitch has throttle point at 87 in 200 point scale when ESC is configured without governor. RPM of the new hovering pitch is 19% higher, 3107 versus 2607 of attitude mode.

According to NASA education page in build note, the square of the RPM growth 1.19x1.19=1.42 should require the inverse of this ratio of collective pitch because lift is proportional to pitch in overall trend in the NACA 0015 data sheet. So the new pitch angle in theory is 6.2/1.42=4.4 degrees. However, the Reynolds number changes with RPM, shifting from the aqua colored curve toward orange and green colored curves, suppressing lift coefficient at sub-6-degree angle but augmenting lift coefficient past 6 degree.
Hovering at 23 points, 23 points / 29.8points x 6.2 degrees = 4.8 degrees.

The maxium RPM of the 14 poles motor is 50,000/7 = 7143, so the hovering point is 200 x 3107 / 7143 = 87 . When you listen to the hovering RPM, 3107/60=51.9Hz, you hear 2 octaves higher harmonics multiplied by the 2 blades, 51.9x2x2x2=415.2Hz because this is the octave most people can hum and sing along. This frequency is the Baroque tuning frequency of A4 music note. The attitude mode hovering sound is conversely a F#4 note. These 2 pitches are the first 2 notes of the Dvorak New World symphony folk tune of the 1800s era, which means that you can validate the power-tran setup in the field just by humming the song and matching it to the tune of the craft switching between the 2 modes.

The collective pitch curve for diving should not be 0 because the helicopter's body provides drag and gives down cyclic pitch for the craft equivalent of elevator-down, as seen in the following video. The free fall from the antenna tip to the church spire, 0:08 to 0:19 is about 200m. The dive started next to the building , but the craft relented its position and drifted behind the building at the bottom of the dive.




To improve the dive precision, we will keep the lowest collective pitch at 8points x (6.2degrees/29.8points)=1.66 degrees to provide compensation, at the same time, using single rotor helicopter dynamics, converting collective pitch force to craft elevator tilting at high forward speed. Overall the curve goes from 8 points and increases 15 points every quarter of throttle range, ending in 53 points,  6.2 x 53 / 29.8 = 11 degrees.

The maximum throttle in acro+ mode climbing/punching should be smooth as the following video.
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
 



And, the difference between factory uav file and operating uav file is the 3 lines of 3 servo PWM ranges, plus 1 line difference of CC3D serial number. Example,
test@galliumos:~/Downloads$ diff Converged-IoT.uav /home/test/dive.uav
4c4
<         <hardware serial="000000000000000000000000" type="3c" revision="a5"/>
---
>         <hardware serial="54ff6b064883545328241887" revision="2" type="4"/>
20,22c20,22
<             <field values="2000,1000,2000,1000,2000,2000,1000,1000,1000,1000,1000,1000" name="ChannelMax"/>
<             <field values="1500,1500,1500,1000,1000,1000,1000,1000,1000,1000,1000,1000" name="ChannelNeutral"/>
<             <field values="1000,2000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000" name="ChannelMin"/>
---
>             <field values="2057,1075,2000,1000,2000,2000,1000,1000,1000,1000,1000,1000" name="ChannelMax"/>
>             <field values="1565,1575,1500,1000,1000,1000,1000,1000,1000,1000,1000,1000" name="ChannelNeutral"/>
>             <field values="1057,2075,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000" name="ChannelMin"/>

Dynamic rotor balancing

In build notes, we visually balanced the rotor for lower RPM 2607 to less than 0.03 grams precision, but the high RPM has imbalances not visible to the eyes. This subtle imbalance gives CC3D error input causing twitching motions in Acro+ and rate mode, making it unusable for cinematic video production. And it is time to fine tune the rotor. Here the test retains the original decal of the blades. 
  1. Fixed by cutting out a corner of 1 decal.
  2. When aggressively trimming the corner, it is over corrected and twitching reoccurs.
  3. Balance out the over correction by cutting the corner of the other decal.
  4. Moving on to remove the test decals. After removing all original decals, swinging re-occurs. Using regular tape on both side covering the chord, swinging persists. Removing one side's tape gains some improvement. Removing half of the remaining side's tape eliminates swinging as the final solution.
The conclusion is that one square centimeter tape makes all the difference. Thickness of tape 0.002inch = 0.005cm, weight (assuming density 1g/cm-square) 0.005 grams. This means acro mode needs precision balance 6 times higher than attitude mode.

Takeoff Procedure

Recent car models have computerized battery management and shuts electric circuit after 20-30 minutes of parking the car. The solution is to stop the car in N neutral gear and engage manual brake manually. The following procedure is written for the car based ground station.

0. After arrival on site, put transmission on N gear and engage manual brake before stopping engine. Wire up ground station.

1. Apply retaining torque on the craft's DFC bolts with a hex screw driver to probe any loose torquing. Check tail prop for detached adhesion. Start FPV antenna and goggles and start recording.

2. Plug in craft battery, but first prepare the craft in a position, such as on your lap, in your hand that it will be rotated clockwise slightly when placed down on a surface in a clockwise motion.
This may sound hideously detailed. But making this happen before powering on transmitter is crucial in allowing swashplate leveling to be checked every flight.
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.

3. Perform the slightly clockwise motion, so that the tail gyro keeps the tail motor off, while placing the craft on a level surface.
Wait until the fast blinking LEDs slows down to a breathing. This takes about 5 seconds. Do not rotate the craft counter clockwise before the LEDs slows down the blinking because that will kick star the tail motor.

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

5. Once the LEDs are in breathing state, the craft can be picked up and rotated any direction without servo or motor movements. 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 by cutting throttle and turning rudder to the left and hold for 3 seconds. The craft will be armed in 3 seconds.

9. Spool up the main rotor by 1/8 stick. This a slow start so that the blades don't fold causing inbalanced rotor to exert force on servo arm spline dials. Give 5 seconds for the rotor to settle speed. The 1/8 position doesn't give the blades aerodynamic effects, so that the craft can stay stable on the ground.

10. From 1/8 stick to 3/8 stick, the problem of 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, where the spool up is at 0:06 , and 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 altitude out of the expected flight envelope.

You need to be very concentrated in applying equally forceful counter corrections.
Alternatively, if you place the craft on a terrain with the pre-defined 4 degree tilt to the right, there will be no error correction by CC3D. But the placement with the pre-tilting is not always available and stable.

11. Throttle up past 1/2 stick. Take off.

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.

And the PIDs, already configured with our production Converged-IoT.uav is as the following screenshot. CC3D setting attitude mode response at 180 degrees, which is the maximum, means that full elevator stick will pitch the craft 90 degree vertical relative to the ground. Rate and acro+ modes response 1000 degrees/s is the maximum in the "Insane" responsiveness region. All those mean that CC3D has full unlimited control of the craft, and the transmitter needs to scale it down or stipulate it for human piloting, like the  exponent setting in the following picture.

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.

High wind landing is often risky. In the following landing approach, I first tilted the head of the craft down so that I could see obstacles around the landing patch on the ground. I continued to keep the head down so that the camera points toward the ground from 0:12 to 0:22 while descending. I ended up facing wind and away from the landing patch because the wind is blowing toward the fence. I flew blindly because I was facing away from the fence and landing patch from 0:22 to 0:30 during final approach. I ripped off the FPV goggles at 0:32 to try to land line-of-sight, but I didn't have the training to fly LOS when the craft flies toward me at the landing target. I was disoriented at 0:37. It crashed.
The appropriate approach planning should be exercised to reduce the risk of landing in high wind as the following table.
This is the most favorable condition. Same with landing an airplane. The head wind slows down the craft. The craft elevator tilts downward to resist the wind. At the same time, the FPV camera points toward the ground for clear view of obstacles.



With crosswind, unlike an airplane, the drone does not need to change approach heading because the drone flies side ways just as fast as flying forward. So, the craft tilts side ways and forward at the same time  FPV camera points toward the ground for clear view of obstacles.

With tailwind, without changing approach heading, the craft needs to tilt its head up, pointing FPV camera toward the sky resulting in blind landing. If the pilot heads toward the wind to tilt the FPV camera down to see the ground, he is facing away from the landing patch flying backward blindly as seen in previous crash landing video. The solution is to change heading and convert the tailwind to cross wind. The field of view of the camera only approaches 180 degrees and less, so the side way approach needs a slight forward movement, and the craft lands slightly off the landing target.

With tailwind and slight crosswind, the heading should be perpendicular to the wind and heading toward the crosswind component of the wind. The landing target is with in the field of view of the camera. The craft tilts toward the ground to resist the crosswind at the same time the FPV camera points toward the ground for clear view of obstacles.


When crosswind mixed with headwind, no heading changes needed because there is no tailwind component to force the pilot to tilt the craft and the FPV camera toward the sky. This is the first and second condition combined. And not heading change needed for either component of the wind.

In summary, the montage of 30 screens to edit/check in Frsky X9Lite after installing OpenTX 2.3.1 is here below.

todo flash complete
todo eeprom error erase
todo calibration


Voltage Monitoring In-Flight

It can be inferred in the following video that Caddx Turtle's voltage OSD shows the voltage is floored to the nearest 0.5 volt. The 10+ second dive starts at 3:59 , and the on-board HD video here,
However, either Caddx Turtle or Runcam Split's voltage range is 10-13V. There is no 4S voltage monitoring.

FPV Fishbowl Optical Illusion

As an illustration, a 30-frame-per-second FPV feed in a tail-spin situation has the following 3 consecutive frames,

, and the craft appears to move from the left side of the road to the ball park on the right side of the road more than 210 feet between 2 frames of 0.033 seconds illustrated in the satellite photo on the right.

In the third frame to the camera failure, the camera points toward the south east corner of the park; in the second to the last frame, the camera points toward near straight north.
The apparent mach-6 hypersonic movement optical illusion needs to be re-fitted into pilot's mental picture for the craft's actual movement. Due to the near-170 degree wide angle lens of either Goqotomo or Caddx Turtle, the camera can display overlapping objects after craft turning 160 degrees. In the above first and second frame, the area at the overlap of line of sight is the actual position of the craft. In the last frame, the battery pack is seen thrown off the craft, and the craft crashed on to the right curb of the road as circle-highlighted in the satellite photo. The craft's actual position is closer to the right curb of the road on the peripheral of the thrid and second frame than it appears.

All objects in the FPV feed are "squeezed" toward the center of the screen from all angles, and the pilot needs to know that the craft is actually positioned closer to the objects on the peripheral of the screen than they appear. This is the same principle of wide angle rear mirrors where car manufacturers put the warning "Objects in mirror are closer than they appear". For the actual footage of the flight leading to the tail spin in the video on the right, in which the same principle applies.

At exactly 1:00 mark, the craft appears to be outside of the ball park over the row of pine trees lining the south side street on the peripheral of the screen, but, the craft is actually closer to the pine trees, likely right above them. 12 seconds later, at 1:12 mark, the apparent position of the craft has moved the improbable 1000 feet to the north west side of the curved road, even though the actual position is still in the confine of the park because the view is exactly the same as the third frame to the camera failure video picture frame. Between 1:34 mark and 1:35 mark, the craft appears to move the impossible 600 feet from the south east side outside the park to the curved road side crash landing point all within 1 second. The reality is that the craft moved from near the center of the park to the curb of the road, 80 feet at most, within 1 second.

The conclusion is that the craft has been within the confine of the ball park all though out the entire flight doing very small maneuvers. The technique of tilting the camera can produce explosive high speed craft flight visual effects simply by distorting the pictures.


FPV Feed Flight Path Tracking

The raw FPV DVR recorded mp4 of the tail-spin crash with fishbowl optical illusion is saved at googledrive https://drive.google.com/file/d/1IchzErZsqhmW0qukS_ZLuJz3CpO4A27t .
When viewed in Android MX Player or the EV800D set, the last 3 frames used to track down the wreckage is not available frame-by-frame. A laptop with desktop Avidemux software is needed to step in the last 3 frames. Avidemux installation for Ubuntu laptops is the 2-step procedure seen in
http://ubuntuhandbook.org/index.php/2018/01/install-latest-avidemux-2-7-0-ubuntu-17-10-18-04/ .

Distinguishing Tail Failure And Failsafe Mode

The video on the right is the confirmed tail failure due to prop ejection, which goes into left turn tail spin at 2:00 and continues until crash.
It is distinguished from the radio loss Failsafe Mode free fall video below at 0:03, which initially turns the craft to the right due to sudden zeroing of collective angle/torque while tail prop momentum continues the right turn motion for a few seconds until tail prop stops, then the zero main torque produces left turn spin.

The correction for the pre-prototype FlySky-A8S receiver is to replace it with parts listed in build notes when the craft is ready to be taken outdoors for test/missions; the correction for the tail prop ejection is for pilot to check the prop loose before every flight.

In the last 3 seconds of the video on the right, the different kind of tail lapse occurs when  rotor torque can only physically turn the craft left 180 degree/s during landing approach and with lower collective pitch/torque. CC3D tried to catch up the misalignment resulting in stall lapse. Pilots should not make aggressive left turn. 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 .

Terminal Speed Diving And High-G Pull-Up


On pull-up, with pre-prototype build of 3S battery and diving at RPM 2607, pull-up with maximum 1666us PWM on ESC and full pitch, airfoil operates as the following diagram.
The 34 degree effective collective pitch has extremely high drag results in collapsed RPM. The airfoil operating point moves towards the wrong corner of the lift curve never to recover the RPM. Crash experiments below with 2 incidences, the first dive starts at 1:00 mark.  In either case, full throttle is applied at the same time of leveling the craft by virtue of high-velocity pitch-up mechanism.



A workaround for the weak power plant is to maintain the diving collective pitch for a few seconds,  after angling the craft for pull-out. as the following airfoil operation diagram.

In such a self-imposed flight-envelope, at 23 degrees effective angle of attack, the lift slows down the descent enough that the airfoil operating moves to the normal operation region, as the following video, which holds back throttle for 3 seconds at the bottom of the dive after leveling the craft to horizontal. This dive still used RPM 2607.

And with RPM 2607, I can only eliminate the swinging motion by diving with 20 degrees off the vertical line. Terminal vertical speed is 20m/s, as seen in urban diving video, which is significant to the rotor head wind speed, at 42%, 20 to 48 m/s that is calculated in build notes.

The comprehensive solution is a 3-part solution, 
  1. 4S battery pack for diving. This eliminates most problems between power plant and the operating curve of airfoil.
  2. Use cyclic to level the craft, not collective. Collective leveling just means to prop wash the PID loops, which the resetting in video looks ugly. Cyclic-then-collective sequencing gives craft a chance to slow down before the next move.
  3. Use RPM 3125, as implicated in build note, to reserve more kinetic energy against the effective pitch resistance. The higher RPM also beats down the terminal vertical speed slightly better, 56 to 20 m/s . And you got highly vertical and high precision dives. 


Tuning Rotor RPM

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


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.



Using Servos With High I-Gain

The high I-gain of the E-Fligh S-60 slows servo response time to gain precision.
For terminal speed divings that need fast PID loops adjustments, the solution is to use 194% P gains in CC3D to buy time for the servo in a dedicated, special "dive mode", which should be meticulously applied before the diving or during the long dive by turning the the switch lever to the middle position. The diving with the S-60 servos is the video below. The pilot needs to be trained to flip the mode switch all the way down back to normal acro mode between 0:28 and 0:30 to produce a seamless video. Because this switching has a very small window time, the normal acro mode is set up to be at the low extreme end of the 3 position switch in the Converged-IoT.uav , so that the switching back action can be swift.

Alternatively, the video with extra 94% gain with vibrations can be edited out post-production, as the following,

The alternative Spektrum H2070T servo does not have the high-I-gain problem and is fully compatible with Emax 9051 servo, as shown in the video here,

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 988us even though they can produce 987us 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 at, or lower than, neutral level PWM, but low limit needs to be lower than neutral. Librepilot does have 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.


No comments:

Post a Comment