Converged IoT Platform Near The Edge Of Space

Disclaimer: Please check with local authorities before a mission. This blog is not responsible for injuries and damages caused by building and using this platform.  This blog is intended to investigate and understand the performance of extreme robotics for better safety planning for cases in the following news. 

And discuss how inexpensive and capable modern components are with a sub-30 dollar motor.

The general platform built (utility drone) is in the previous blog, build-notes; the general operation note is in operation-notes. Our single-rotor platform with collective pitch has one extra degree of control for precision target diving,  compared to fixed-pitch crafts with unplanned displacements, as discussed in the video on the right. We build this new extreme robot based on the endurance build but divert about 20 grams of the mass from the battery pack toward crash resilience and signal transmission, GPS (5.3g) tracking, higher video transmission power (1g extra), higher RF control receiving (1.8g extra) thicker flexible wires (3.2g extra), titanium main shaft (extra 2.8g), higher crash-resistance rotor grips (extra 2.5g), extra video transmission antenna (2.9g extra), battery soft mounting velcro (0.8g extra). 5.3+1+1.8+3.2+2.8+2.5+2.9+0.8=20.3g. The battery pack is about 20 grams lighter, 87.2g+2.2g+0.8g-70.7g=19.5g. The build is pictured below; the bill of materials follows. 

193 mm Blades RPM 3400 Allows Fast Mission Travel

	Prototype High Endurance Build	Prototype Fast Travel Build	Production High Endurance Build	Production Fast Travel Build
RPM	2640	3100	3250	3430
Rotor Diameter	18.6 in/472mm	18.6 in/472mm	17.2in/438mm	17.2in/438mm
Hover Blade Angle	6.2 degrees	4.8 degrees	6.1 degrees	5.5 degrees
Blade Mass	14.6 grams	17 grams	15.6 grams	13.4 grams
Moment Of Inertia	0.00036388	0.00040843	0.00029416	0.00032933
Angular Momentum	0.10	0.13	0.11	0.11
Blade Tip Speed	65m/s	77m/s	74m/s	79m/s

The endurance optimization from prototype 210mm blades to 193mm blades did not improve endurance but increased blade tip velocity, incidentally improved fast travel and wind resistance. Summary table here on the right.  

Reducing rotor diameter and increasing blade tip velocity from the endurance build logically should improve wind resistance and increase top speed. In the endurance build chapter page, it was discovered that the small-diameter Sokolov-twisted and Clark-Y-slanted foils could not be used in single-rotors and could not be fixed without deteriorating efficiency and motor overheating/overclocking. But, even disregarding efficiency, Sokolov-twisted and Clark-Y-twisted foils have reduced blade tip speed relative to wind or travel. 12-inch and 14-inch Sokolov-twisted blades rotate at 3250 and 2550 rpm for a 250-gram lift , as  designated and extrapolated in the graph below . Their blade tip speeds are 3.14*(12*25.4/1000)*3250/60=52m/s and 3.14*(14*25.4/1000)*2550/60=47m/s, respectively. For comparison, the symmetrical airfoil we use rotates at 2640 rpm at the lowest for endurance with an 18.6-inch diameter, has a blade tip speed of 3.14*(18.6*25.4/1000)*2640/60=65m/s. 

To patch up the velocity (before improving upon the prototype build), 12-inch and 14-inch Sokolov-twisted blades would have to rotate at 4100 and 3500 rpm, respectively, with slight motor overheating. Remember, as tested in the endurance build, the slightly negative pitch affording the 4100 and 3500 RPM has more drag than a positive drag in Sokolov-twisted and Clark-Y-slanted foils.

But the biggest problem, as shown in the endurance build note, is the lack of angular moment, much lower than 0.1 kg⋅m^2/s of the prototype endurance build. When Sokolov-twisted and Clark-Y-slanted rotors were spun to match the angular momentum of the prototype endurance build, even without improving upon the prototype endurance build, the overheating became a risk of fault point.

A prototype rotor with 77 m/s blade tip speed was built to refocus on straight blades, which performed successful terminal speed divings. But was 77 m/s overkill and unnecessary? It was discovered that for a prototype with 210mm blades, the high-fuel-efficiency setting RPM2640 was sufficient for both straight diving and cruising for both the orange (nylon) and black (graphite reinforced nylon) Oxy210 blades, 2.7mm and 2.5mm cord thickness (not blade root thickness), respectively. The first two diving videos below show the blade tips for using orange and black rotors with an ESC governor. The third video shows the pre-prototype RPM2640 setup without an RPM governor during the "motor selection" with our pre-prototype builds. However, RPM2640 with 2.5mm blades was prone to forward travel stall, blade tip velocity 2640/60*(210*2+52)/1000*3.14 = 65m/s, as shown at 2:02 and 2:12 of the first video, due to the helicopter physics, which tilts the craft's head upward when traveling against the wind. RPM2640, with 2.5mm thin blades, caused several flyaways in high winds. It is well known that a thicker airfoil allows a higher attack angle without stalling because the thicker convex surface exerts higher pressure on the gas to press it onto the airfoil firmer, except at the very tail tip where thickness approaches zero regardless of airfoils, to prevent de-lamination and stall. It is also well known that the lift coefficient does not change when airfoil thickness changes. 

For the prototype build, the solution was RPM at 3100, setting the hovering pitch to slightly lower than 5 degrees but higher than 4 degrees, trading off 8% fuel efficiency as seen in operating note of cL/cD 23 versus 25. This angle between the orange and green lift curves so that the lift slope doesn't turn steep, which would have translated to more difficult altitude management. RPM of the new hovering pitch is 19% higher, 3100, versus 2600 of attitude mode. The RPM change from accelerometer mode to gyro mode has a ratio of 3100/2600=1.19. According to the NASA education page in the operating notes  https://nocomputerbutphone.blogspot.com/2018/09/converted-iot-drone-operation-notes.html, the gyro mode should require the inverse of the square of the 1.19 ratio on the collective pitch, 1.19**2=1.42, because the lift is proportional to the airfoil pitch; in contrast, the lift is proportional to the second power of RPM-airspeed. The new pitch angle should be 6.2/1.42=4.37 degrees. However, the Reynolds number changes with RPM, shifting from the aqua-colored curve toward orange and green-colored curves, suppressing lift at a sub-6-degree angle but augmenting lift past 8 degrees. So, I experimented hovering to see that the mid-throttle collective pitch point needed to be 22 points, 22 / 29.9 x 6.2 degrees = 4.56 degrees of the collective pitch in the channel 1 curve. Notice that the mid-throttle is scaled by 0.98 in the transmitter and shown as 22x0.98 = 21.56 in the LCD display. However, the angle is 4.56 because the display of 21.56 points refers to the 989-2011us PWM range. The 0.98 scaling sets the PWM signal range 1000-2000 microseconds for 200 points for "83 degrees" as measured as the full servo horn travel angle. 21.56/200x(2011-989)+1500=1610us is the actual PWM signal. (1610-1500)x50%+1500=1555us is the mixer output toward the servo. (1555-1000)/1000x83=46.0 is the angle from the position where PWM is 1000us in the servo. 46.0-(83/2.0)=4.56 is the angle from neutral. 

The prototype build was subjected to maximum climbing (punch) test with an overall collective curve from 6 points in the first quarter and increasing by 17 points every quarter of the entire throttle range, ending at 57 points, 6.2 x 57 / 30 = 11.8 degrees maximum, as pictured on the right. But the high-end punching has craft yaw lapse, gradually spinning to the left while ascending, as shown in the first video of this section. The workaround of increasing the P gain of the tail motor could not completely remedy the problem due to the near verticle drag slope at 11 degrees, as seen in the operating note's NASA foil data. 

The prototype was subjected to terminal speed fast travel (diving) as the video on the right shows. The free fall from the antenna tip to the church spire, 0:08 to 0:19, is about 200 m. The dive started next to the building, but the craft relented its position and drifted behind the building at the bottom of the dive. The craft's body provides drag and gives the craft the equivalent of a minute elevator down torque. Trying to improve the dive precision by keeping the lowest collective pitch at 1-2 degrees to provide compensation by using single-rotor helicopter dynamics and converting collective pitch force to craft elevator tilting at high forward speed, resulted in difficult-to-pilot, swinging motion, as tested in the video on the lower right, with the compensation with 6 points of collective pitch in the -100 to 100 RF transmitter point range.

Nontheless, the prototype verified that the stable terminal speed that our build can handle is 24.5 m/s or 55MPH or 90 km/h. It is calculated graphically below. The speed-time plot of free fall with drag is well known to be a tanh function with terminal speed in the scaling factors. The integral distance-time plot shows 10 seconds of dive with 203 m travel at 24.5 m/s terminal speed. Assuming the pull-up force is 2.5 G, the craft stops within 1 second past the 10 seconds of dive with 12 m overshooting travel. The church's spire's height is about 50 m. The tower's roof is about 240 m above ground, and the antenna mast likely adds another 25 m where the diving started.

We refocus on the 77 m/s with an  angular momentum of 0.1 as the solution for the production build. The  ideal solution (the skinny blade unavailable in the market) for straight, symmetrical airfoil or endurance improves wind resistance for fast travel because the blade tip velocity is high at 3340 RPM, all in the same mode of operation for high endurance. Blade tip airspeed is 3340/60*(193*2+52)/1000*3.14 = 77 m/s, the same as having 3140 RPM on the prototype blades of 210mm and broader hub span, 3140/60*(210*2+52)/1000*3.14 = 77.5m/s. 

For the production build, the solution could be simply an RPM 3340 for the 193 mm blades because that is how a 193 mm blade can achieve the needed 77m/s and 0.1 angular momentum. Still, we increase RPM to 3430 instead of the ideal 3340 for the margin for the blade balancing RPM adjustments. Remember, the spinning linear blades with centrifugal force is equivalent of a musical instrument string in tension, with  resonant frequencies to be tuned out. The RF controller channel 5 bypass is 3430*7/50000*200-100 = -4.  Also, the stall angle rises when Reynolds's number increases with the airspeed. In short, this recapitulate toward a separate operating mode at 79m/s velocity as the solution for production builds. Firstly, the ideal high-efficiency blade angle product is not available to reach 77m/s blade tip speed at RPM 3340 while having optimal blade attack angle of 6+ degrees. Secondly, the practical, available product needs a slightly smaller blade collective pitch angle for hovering, and furthering this downward shift is actually beneficial. So, even if the ideal product is available in the market, a separate operating mode for 79m/s is beneficial.

Unlike the prototype build, there is no lift-curving because both endurance mode and fast traveling mode have a collective pitch above 5 degrees. The calculated hovering angle for fast travel is 6.1 (degrees high-efficiency setting) / (3430/3250)^2 = 5.5 degrees. The PWM servo signal for this angle is (5.5+(83/2.0)) / 83 * 1000 + 1000 =  1566.265us. RF PWM is (1566.265 - 1500) / 50% + 1500 = 1632.53 , LCD display point (1632.53 - 1500)/(2011-989)*200 = 25.935 . Pitch curve point for it is 25.935 / 0.98 = 26.46 . Hence the production build's pitch curve is set as 0, 13, 26, 39, 52, maximum collective pitch is 6.2x52/30=10.7 degrees. The zero collective pitch at the low end avoids the pre-prototype swinging motion. 

The production craft's servo mixing is larger than the prototype craft's because the servo arms are shorter relative to the blade pitch arm width, the p-value in the following diagram. The high mixing also allows the overshooting of the servo-throttle to avoid flight software startup cyclic "rapid twitch" discussed in the build notes https://nocomputerbutphone.blogspot.com/2018/09/converged-iot-platform-build-notes.html.  

The relationship between servo mixer attenuation and servo/swash/pitch/DFC arm spans is illustrated here.

Because the prototype's servo mixing used standard CC3D 50%/50% collective/cylic mix when the p value was 1, the extra attenuation of production build's p value at 1.5 means the production build's collective mixing, if and we do want prototype's throttle curves reused in production build, needs to compensate the 50% mix by the factor of 1.5, 50% x 1.5 = 75%.

Because the prototype's cyclic mixing occurred with p*(d/u)=1*(1.833/0.916)=2 while production build's p*(d/u)=1.5*(2.25/1.1875)=2.842. The extra attenuation of 2.84/2 = 1.42 is compensated as 50% x 1.42 = 71%, and (50*sqrt(3)/2)% x 1.421 = 62%.

Because we compensate the mixer difference in software, the pitch curve calculation in RF hardware controller based on the 50%/50% mix does not need recalculation.

The endurance build notes show the measurements of p, d, and u, where lightweight substitutes were considered

All these production-improved settings are part of the dump_all file in the  operating notes.

Production Build's CG Setting Is Always Correct

During the prototype build with the  substitute camera Insta360 Go, it was discovered that moving CG forward stabilized the diving, as seen here. When using the substitute Runcam Hybrid2, which weighed the same as Insta360 but distributed weight rearward 6cm on the recording board that weighs 5.4g and without the 3.5g custom bracket and without the 2-gram Caddx Ant camera, and with the 49-gram, 450mah, battery front close to the battery cavity front edge, the unstable dive is shown in videos here.
The weights of the substitute components are in the pictures below. The loss of head-down torque with the Runcam Hybrid2 setup was 5.4gx6cm+(2g+3.5g)x9cm = 81.9g-cm, equivalent to having an 81.9gram-cm/30cm=2.7gram heavier tail motor.

 

What's worse was that the loss of head-down torque disrupts the level travel pitch holding, as shown in the following videos.

For the substitute Runcam Hybrid2, the solution was to modify the 450mah battery with double-sided mounting tape and Velcro to protrude 2-3cm (about 1.5-2.5cm in the horizontal component), pictured here.

When tested with Runcam Hybrid2, there was no difference in flight characteristics between 2cm and 3cm protrusion. 

In the following diagram, the production build Blade Fusion 180 frame has a rotor and tail congruency as the prototype Blade 230 frame with ThumbPro(instead of Hybrid2).

The congruent tail has the moment of inertia as

>>> 0.007*(0.3**2) + 0.0048*(0.25**2)

0.00093 kg · m^2

The non-congruent motor, battery, and camera have the moment of inertia as the following calculations,

>>> #for production build plus tail

>>> 0.0418*(0.075**2)(motor) + 0.0691*(0.133**2)(battery) + 0.0019*(0.117**2)(camera) + 0.0045*(0.076**2)(FC) + 0.008*(0.1**2)(ESC) + 0.02*(0.075**2)(fuselage) + 0.00093

0.002632 kg · m^2

>>> #for prototype with Hybrid2 plus tail

>>> 0.0501*(0.0819**2)(motor) + 0.049*(0.133**2)(battery) + 0.0127*(0.127**2)(camera) + 0.0026*(0.108**2)(VTX) + 0.0026*(0.108**2)(FC at bottom plate) + 0.008*(0.110**2)(ESC) + 0.02*(0.0819**2)(fuselage) + 0.00093

0.002629 kg · m^2

So, the production build's moment of inertia is almost the same as the prototype's. 

LongRange Battery Has Same Power Within 70% Discharge As High C-Marking Batteries

The production build uses a high-capacity battery instead of a high-C-marking battery. A Voltek audio recorder was installed to view the main rotor RPM recovery during diving pullouts. 

High C-marking batteries GNB Power and CNHL SpeedyPizza were compared to the production-built GNB LongRange battery. All 3 batteries have the same weight within a +/- 1 gram margin of error. The audio fingerprints below show identical recovery S curves between the production build within 70% discharge and CNHL SpeedyPizza within 95% discharge. They show that the production build is exactly as powerful as a high-C-marking battery when using the same ESC RPM PID governor production parameters.

LongRange 850mAh 4S 60C Spectroid spectrum at 5:20 arm minutes at 6:50 at 8:24 .

SpeedyPizza 600mAh 4S 120C Spectroid spectrum at 4:47 arm minutes at 6:30 at 7:42 .

Both batteries, both nearly brand new, have been tested with 570+mAh of proximity missions after audio card was removed for highest performance, in the following 2 videos, with nearly identical total climbs of 1100m in windy days.

For the LongRange battery, the discharge is about 575/830x100%=69%; for the high-C-marking battery, the discharge is about 575/580x100%=99%. The high-capacity battery has a good safety reserve of about 830-575=255mAh; the high-C-marking battery has no safety reserve of about 580-575=5mAh and crash landed.

With extreme robotics missions, the LongRange battery has a lifespan of about 8 cycles, as tested to failure in the video on the right. 3 tested packs have similar lifespans, but 2 packs are not documented.

The performance of the 8th cycle of the GNB Beat battery is very similar to that of the LongRange battery's same cycle performance in the 2 videos here for comparison. Neither could climb fast past the 6-minute time.

Soft Velcro Diverts Fluid Vortex Out Of Resonance 

Prototype's enclosed battery configuration was changed in the production build to an attached configuration, giving a nearly indestructible craft body, as summarized in the table below.  The accidental discovery that the attached battery configuration made an indestructible craft body was in the crash video on the right. The crash that should have resulted in destruction of the battery, rotor DFC components, motor mount truss, and bottom plate, instead, only had a broken top plate at the front protrusion - there was no detectable damage to the battery.   

	Prototype Build	Production Build
Battery pack setup	Enclosed	Attached
Contact with body during diving	Sliding	Pressed head-on
Contact with body during crash	Head-on impact	Deflected-off
Vortex Resonance if tight mounting	No	Yes
Battery Munting	Blind Mounting	Visually Measured
Crash damage	Severe	Indestructible

The video below on the left (for testing bad high tail I-gain) in April 06 shows another startling example of the production build's robustness. The crash at terminal velocity caused zero damage, so on April 10, the correction of the tail I-gain was tested in the tail PID section of this page, which is also shown as the pre-fix video here below on the right with a video serial number immediately adjacent to the crash video, proving no fix of any damage was made.

 
The 2 different battery setups are pictured here. Notice that, in the enclosed configuration, the lower left part of the battery did not have velcro, and it slides into the frame enclosure.

 Action cameras logically have proprietary motion blur and other features that consumers cannot control, making them difficult to be a converged solution with high levels of control for a wide range of applications. FPV cameras are on the trajectory to become open source with OpenIPC. The following two videos compare the prototype built with the Runcam action camera and the production build with FPV onboard recording, which shows more detailed paused pictures.

This is true even without youtube video compression loss, if you view the example action camera video under the best lighting condition here after downloading it.

When the prototype's action camera block was removed from the front battery bay roof and the battery moved forward (to compensate CG shift) and lowered to the attached position, it was discovered that the fluid vortex-induced oscillation's frequency matched the craft's mechanical resonance frequency. This results in high headwind vibrations, as shown in the video (first dive) below on the left. When the battery pack's mounting was strengthened, the resonance became stronger and more persistent, as shown in the video below on the right.

The solution is to use loose battery mounting, as pictured below on the left. The front mount point has a 5mm gap; the rear velcro does not corner the battery. Vibration-eliminated video below on the right.

The raw video before Gyroflow stabilization is below on the left. In the solution picture, the loose mounting incorporates a Velcro loop tape cloth on the roof of the battery bay. The roof cushion is for craft attitudes when the battery touches the roof, such as inverted or diving vertically down. Without this cushion, the battery knocking on the roof produces yet another vibration, as shown in the video below on the right. 

PID tuning and tightening the battery logically can also divert the craft's whole mechanical system resonance frequency. However, testing with downshifting PID to the equivalent of 60 degrees F colder temperature's PID did not shift the frequency enough, as shown in the following 2 videos. The video on the left is raw FPV footage; the video on the right is Gyroflow stabilized but still shows fluid vortex vibration during vertical dive.

Half-soft mounting, retaining some pressure to the battery to the roof velcro, is ineffective. The following video shows the half-soft mounting. The front has not a 5mm gap and the back has velcro cornering the battery.

 

Emax 9051 F3P Servo And "Tail Servos" Interchangeable With A Fixed Set Of Control PIDs

Prototype adjusted PIDs with air density, temperature, and swashplate slop; production build only adjusts RPM and discards swashplate with crash damages.

It was discovered that the physical P-to-I ratio of 1:20 is suitable for straight-down terminal speed diving with a 188 Hz low-pass gyro filtering at 1 kHz PID looping rate.

In the video, the left side is controlled by Betaflight (our production build) with the vintage scaling numbers set by a racing champion robot or an anonymous human defector as the following,

PTERM_SCALE  0.032029
ITERM_SCALE  0.244381
DTERM_SCALE  0.000529
PID_MIXER_SCALING 1000 

PID_SERVO_MIXER_SCALING 0.7

.  More than 3 different racing controllers in the market follow such a "define" of scaling in their pid.h file. Pitch PIDs at -1°C is 45/118/0 on the left side. The prototype  CC3D flight computer used physical PID parameters on the video's right side. Pitch PIDs 0.002/0.04/0, tail yaw PIDs 0.0015/0.0034/2.1e-5 at -9°C. Both sides had identical main blades, RPM, swash mix, servos, tail motor, tail prop, weight, and weight distribution.

For gyro-only-stabilization, straight-line traveling (the b and c terms in pid2 of Matlab are canceled by zero steering),  we convert and cross-reference  CC3D PIDs  with  Betaflight PIDs by applying the vintage scaling as follows.

          pCC3D  / 0.032029  / 0.7 * 1000/2 = pRacing

, i.e.   0.00200 / 0.032029  / 0.7 * 1000/2 =  45

, i.e.    0.0015 / 0.032029  / 0.7 * 1000/2 =  33

          iCC3D  / 0.244381  / 0.7 * 1000/2 = iRacing

, i.e.    0.0400 / 0.244381  / 0.7 * 1000/2 =  117

, i.e.    0.0034 / 0.244381  / 0.7 * 1000/2 =  10

          dCC3D  / 0.000529  / 0.7 * 1000/2 = dRacing

, i.e.    2.1e-5 / 0.000529  / 0.7 * 1000/2 =  28

In our production build, which uses racing quadcopter controller, the 1000/2 factor emulates PWM 1500+/-500 servo travel of helicopter. The 0.7 factor is another racing controller scaling in the developers' mind to protect servos from perceived overrun.

The prototype's PI values scale together in conjunction with compensation for air density conditions (temperature) and swashplate slop, as tested and recorded in the following graph. 

The production build adjusts the main rotor RPM according to the general operating note. Because the operating note uses 50°F (10°C) as the reference temperature, the pitch axis PIDs are set for that reference temperature as so,

0.00200 / 0.032029  / 0.7 * 1000/2 * (273.15+10)/(273.15-9) =  48

 0.0400 / 0.244381  / 0.7 * 1000/2 * (273.15+10)/(273.15-9) = 125

; the roll PIDs are 1/3 of the pitch axis, 16, 42.

PID for pitch axis is always 48/125/0 for all weather. The production build's swashplate has sacrificial linkage stubs that break easily as pictured on the right, so the swash slop does not worsen after a crash. So, there is no need to adjust PIDs for swash slop either. And the axillary channel 5 RF control for throttle RPM for fast-travel, rate mode operation is always 5 points higher than for attitude mode. This persistent 5-point difference can be illustrated when we are change RPM from 3250 to 3430 for high-speed missions. 3430/3250 = 1.055 . In cold and dense air, base point 87 multiplied by 1.055 gives 92 points; in hot and thin air, base point 94 multiplied by 1.055 gives 99  points. Every 10 degrees Celsius rise in temperature corresponds to about 1 point. The RPM measured below on the left produced the video below on the right.

The following 2 videos show the production build diving at the 33°F. The raw footage is on the left, and the post-production stabilized video is on the right.

Over locking RPM produced craft vibration that completely destroyed the video, as shown in the following 2 videos for comparison. This was tested on a prototype build with an RPM meant for 20 degrees F higher. The 2 tests were only 1 day apart with identical craft setups. But the second day's morning temperature was uncharacteristically low for summer and caught me off guard.

 

The following video on the left is underclocking at 2650 RPM for the prototype discussion earlier, using the same old, loose swashplate. The video to the right is another underclocking but with production build.

 

The shakings for insufficient RPM and PIDs appear similar in videos. However, piloting can feel that the shaking with insufficient RPM and PIDs has a bigger rolling banking component, while the shaking with overshooting RPM and PIDs has a bigger pitching, up-and-down component.

DYS Sn20a And Favorite Blheli20a ESCs With 1106/1303.5 Motor All Interchangeable Using Same Software And Configuration For Tail

	Prototype		Production
Part	Gemfan oblong 4025 prop.		HQ Prop slanted 4025 prop.
PIDs	33, 10, 28		50, 8,35
High-wind PID	33, 8, 34		50, 8, 35

The production build's all-weather tail PIDs are improved based off the prototype's PID set that needed a separate high-wind set of PIDs. The prototype tail with a glued straight propeller was tested and shown that, with Kd=0, at the bottom of the dives or whenever the main rotor torque has rapid, sudden increases, the direct drive tail lapses while the motor spins up with limited acceleration and limited yaw-left movement. The high integral produces winding resulting in tail bumping "collision with thin air" bounces at 0:57, 1:16, and 1:41 of the video below on the left. One solution was to use a high torque tail motor of 1306 size and Kd=0, such as the video below on the right. But the CG setting was incorrect with the heavier tail motor, so the general solution was to set Kd to around 2.1e-5 in CC3D, or equivalent D= 28 in Betaflight, with a small Ki with 1106/1303.5 motor.

The fact that whenever a control axis has ample, instant corrective torque, the Kd should be zero acknowledges that our rotor attitude control PID with Kd=0 is a correct setting because the variable pitch rotor can produce the desired corrective torque utilizing the considerable spinning momentum of the main rotor within half a revolution of the rotor without speeding up or slowing down any propeller. This also explains the contrast of why multi-rotor systems need Kd tuning for roll and pitch control.

Yet the general solution needs to consider wind conditions. With the prototype's glued straight tail propeller, in high winds, the I term should be lowered by 20%, D term should be upped by 30% for Betaflight to prevent wind-induced oscillation, as the following 2 experiments show.  

The production build uses the high-wind PIDs modified with the slanted propeller, requiring 50% extra P gain, and is in the dump_all configuration. 

The tabulation here gives temperature 0.5th-order power to scale PIDs because tail PIDs control tail RPM with a 2nd-order power on thrust and is part of the dump_all config file. The following videos show a comparison of a flip turn with the production build with a 40% extra P gain on the left and a 50% extra P gain on the right. You can see the tail wagging at 3:37 with an insufficient 40% extra P gain in the video on the left. 2:09 flip in the video on the right has no wagging. 

The insufficient P gain wagging can not be fixed with post-production stabilization, as shown in the following 2 videos, at 0:31 for post-production stabilization for the previous 2 videos.

A trial of a different ESC/motor combination found that startup 1.25 had propeller stuttering, even though FVT Blheli20a and DYS Sn20a can start the motor smoothly, regardless of 0.5 or 1.25 startup.

The prop stutter with 1.25 startup was not recorded. The verification with interchanging between FVT and DYS is in multiple videos in this page, including the GPS glitch and pull-off jerking prevention discussion video.

Tail punch/reset/bumping takes 4 parts of corrections to fix. In the operating note, the tail punch was solved with constant main rotor RPM, and the tail reset was solved with slanted props. The 0.5 startup prevented tail prop stuttering as the 3rd correction. The final correction for the tail bumping is to make smooth pull-offs. With interchangeable FVT ESC, video is here.

With the production build DYS tail ESC, the video is in the 8th battery cycle discussion.

1303.5 2500kv motors have been verified in many different settings, including video here, but without documentation of startup power and BLHeli motor software version. 

Higher Rotor Balancing With RPM 3400 For Stable Video

In the platform's operating note, we visually make sure the rotors are symmetrical. For the prototype build with RPM 3140 and the production build with RPM 3420, the rotors has imbalances not visible to the eyes

. The first thing to take care of is the tightness of the rotor grips. For consistency, we set the blade draping angle to ideally 90 degrees, as the video on the right shows.

If the blades are over-tightened, imbalance easily results in mechanical vibration; if the grips are too loose, such as in the video on the right, the P-I ratio is different from usual and unpredictable.

Going from 2650 to 3150 and higher RPM requires fine-tuning the rotor with hand-tethered hovering. Here the R/D test retained the original decal of the blades. And the tuning took 3 tries in the research process, as pictured below. First, I fixed the tremoring by cutting out a corner of a decal. When aggressively trimming the corner, it was over-corrected, and tremoring reoccurred. The balance was restored by cutting the corner of the other decal. Once the amount of taping was determined, all decals were removed, and the clear tape was put in place for the required balancing. The balancing progress during the research is the 4 pictured below from left to right. The conclusion is that one square centimeter of tape makes all the difference because the rotor is stretched by centrifugal force like a musical instrument wire, and the 3150 RPM is on one of the resonance frequencies of the device. The thickness of tape 0.002-0.003inch = 0.005-0.0075cm, weight (assuming density 1g/cm-square) 0.005-0.0075 grams. This means RPM3150 needs a precision balance of 1/100th of a gram.

   

However, during multiple test builds, it was discovered that most builds could not achieve smooth balance and that blade swapping was needed. One of the successful blade pairings was pictured above on the right with a green checkmark. The 2 distinct symmetries, rotation and mirror, for balancing the rotors is diagramed here.

The swapping needs to restore the rotational symmetrically of curved blades because our rotor hub does not have a cord-wise balancing bolting like the Bell 222 rotor, as highlighted in the picture on the right. The 2 blades with up-down warpings can be none-mirroring as the right side in the above diagram when subjected to 3250+ RPM's centrifugal force. The solution is to pick and match a pair that dynamically match the warping to each other.

A new blade with natural backward curving when spun up (not the same curving at rest) can be matched to a old blade with crash-induced backward bending, as shown in the above example with a green checkmark; the older blade's color fades, but it is the best match picked out from 3 different sets of new purchases. The at-rest warping mismatch shall be disregarded. At rest, one may warp up, and the other down, but the forces may balance out when spun up to 3250+ RPM, depending on the material's internal stress. All the other blades from the 3 sets fail to match the lower blade in the picture. The only way to check the pairing is to spin them up to full speed. And each pairing test needs to be checked with 2 alternative orientations of the grip installation. In the pictured example, only one orientation can produce a smooth spin. The other orientation always has vibrations that can't be tuned out with scotch tape.

Before the pairing process of a purchase, mark each blade with a unique serial number you manage, then weigh each blade individually and note the heaviest blade. The following pictures show an example of the heaviest blade, blade 3, of 7.301 grams. Then use scotch tapes spread evenly on each blade (except the heaviest one) to patch all the blades in the purchase to the heaviest weight. This ensures that the pairing process focuses on matching the the warpings of the blade material.

So, what happens if the rotor is a non-symmetrical mismatch? RPM detection with Engine RPM Android App can not lock and detect the RPM.

Use the Android app Engine RPM to measure the rotor's RPM with the settings in the screenshot below.  The app automatically logs the detected RPM every 3 seconds, as seen in the screenshot below. There is a 1.5% discrepancy between the PWM control signal and the actual measured value. The PWM controls are pictured with the respective actual RPM logs below. We use the actual measured RPM as standard.

So, what happens if the rotor has longitudinal off-balance by more than 1/100th of a gram in the field? In the videos below on the left, with perfect balancing, the PIDs are 2 notches lower than required because the swash slop is 10mm, the largest. The dive loses its heading hold about 2 seconds before pull-up at 0:11, but video stabilization patches up the insufficient PIDs below on the right.

But, when a 2 square-cm balacing tape is intentionally removed and immediately performing another test, the dive has loss of heading hold at 0:08 and 0:09, and the stabilization result is sub-par, with blurring at 0:07 and 0:09, to the above good video.
When inspecting the gyro data, both good and sub-par dives are 11 seconds between 2 green pitch-up dips in the following 2 pictures. The first picture is the good dive; the second is the sub-par one. And the blue-band noise level of the sub-par dive is about twice as thick. The good dive has a long period of quietness between 05:49 and 05:55, while the sub-par one has no quiet period.

The ultimate smooth balancing has a lateral (on the side) ballast, in addition to the axial balancing, as follows with 24 AWG copper wires.

The first loop has the crossing beneath the DFC bolting and excess wire trimmed. Then, pinch and turn the wire for a few turns. In the example on the right, the 7 loops on one side are the correct balancing because 14 loops were tried on one side, and zero loops on either side were also tested to be lesser balance. This example ballast weighed 0.2 grams with 7 loops.  However, this level of ultra balance is not required for smooth HD video shooting.

Electronic calibration to fix aborted/diminished dive

 The example on the right is of diminished dive happened with 1495us center pitch PWM output. The full deflection of the stick is 720 degrees per second. The 5us from center 1500us is 5 / 500 x 720 x 0.25(exp) x 6(sec) = 10.8 degrees tilted dive at the bottom of the dive. And this tilting is also very obvious when tethered hovering in hand.

Robust Main Grips

The good dives are reproducible consistently using Oxy2 grips, which have thrust bearings pictured here. 

When installing the Oxy2 grips, watch out for factory assembly mistakes that occur about once every 10 pieces by the tentative(without washers and without hard cranking) installation of the feathering shaft and pulling, as shown in the following video on the. But, first use a marker to mark a dot to make sure, if the pulled grip rotates smoothly by itself or by rotating the shaft and the other grip's bearing provides the smoothness. A correctly assembled grip set should feel surprisingly and pleasantly slick in the pulling test on both grips.

The technique in the following left-side video is incorrect because a good grip on one side can ensure a smooth rotation on the other side, masking the problem of one-sided manufacturing mistakes. The following right-side video shows the entire assembly process.

 

The factory assembly sometimes misplaces a high-error inner thrust disk instead of the low-tolerance outer thrust disk, as explained in the video above on the right. Discard the bad grip. The outer thrust disk needs to hug the feather shaft tightly because the radial bearing's inner tube needs to rest on the outer thrust disk without sinking into the crevice between the shaft and the disk, which would result in transferring centripetal, axial force onto the junction between the outer radial bearing's inner and outer tube. The general IoT platform build uses Align250 main grips without thrust bearings to avoid the added build complexity.

The general build's Align main rotor grips without thrust bearings can also dive at terminal speed properly, as in the following video, but only with brand-new grips if without modifying PIDs, as seen in the previous section about calibration of electronic PWM. Unless you trim the rotor blade roots, the Align250 grips are too short to accommodate a thrust bearing on the far side, like the Align300 grips. With wearing, the feathering friction is more significant without thrust bearings, so the physical P-to-I ratio differs from 1-to-20 (as seen in CC3D, or, unscaled) for terminal speed traveling,as shown in the following video.

Highly Reliable RF Control

In the general operating notes  https://nocomputerbutphone.blogspot.com/2018/09/converted-iot-drone-operation-notes.html , we showed that 4004 motors need the toned-down governor P-gain of 0.13 for proper RF control lost recovery. But, a high P-gain of 0.5 is needed for high-performance "punch up." In the RF control signal loss and recovery exercise in the video on the right, the 4004 motor's high torque with sudden high throttle breaks the motor anti-rotation zip tie when the ESC governer P-gain is 0.5. The wreckage of the crash has main motor power wires twisted due to anti-rotation zip tie failure. A common strategy is to increase the RF range to increase reliability. The TBS Crossfire RF control transmitter and receiver setup follow.

Dual Antenna Fixes Single Antenna VTX Difficulties

Here is an FPV view of the Walksnail HD v2 Single Antenna VTX when the craft blocked the antenna, at 11:20 (best attitude to counter wind but most severe video freeze), resulting in a momentary video freeze right before the dive.

In this wind condition of 20 mph from southeast, the attitude to counter the wind unavoidably blocked the antenna at 9:34, 9:54 - 10:05, 10:17, 10:30, all in the best attitude to counter the wind, but most severe video freeze.

Canted Tail Rotor Setting Solves "Thrubbling"

The build's helicopter tail rotor is not on the rotation plane of the main rotor. It has a small right-roll torque on the craft, and the gyroscopic precession makes it tilt backward and fly backward. The parasitic torque increase as the throttle increases. The pullback problem can be discovered in gyro mode travel with sudden maximum throttle, the tilt backward happens between 0:31 and 0:33. Just 2 seconds of pullback already sends the craft away from the car where it hovers initially. Then a forceful pitch down is applied in a panic at 0:33. At the end of second 33, the car is seen in front of the craft, compared to it is on the side of the craft at the beginning of the punch-up. Please notice that the tilt angle is barely perceived, lowering horizon for about half an inch when viewing this video on computer monitor. That means FPV pilot can not notice the problem is occurring.

On a high-wind day, the throttle may need to be kept high throughout the mission, and that causes the fly-away. The actual fly-away video footage shows traveling over roads and people, which was unlawful. It is only resolved when the throttle is lowered. The solution is the canted angle same as the Seahawk helicopter's design. The fix can be verified line-of-sight, on the right, and the maximum throttle punch-up at 0:30-0:33 happens rather uneventfully, straight up.

FPV Fishbowl Optical Illusion

A 30-frame-per-second FPV feed of a tail-spin, craft shaking itself apart, has the following 3 consecutive final 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 screen's periphery than they appear. This is the same principle of wide-angle rear mirrors where car manufacturers warn, "Objects in mirror are closer than they appear." The same principle applies to the footage of the mission leading to the tailspin in the video on the right.

At exactly 1:00 mark, the craft appears to be outside of the ballpark 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 the 1:12 mark, the apparent position of the craft has moved the improbable 1000 feet to the northwest 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 the 1:34 and 1:36 mark, the craft appears to move the impossible 600 feet from the southeast side outside the park to the curved roadside crash landing point within 2 seconds. The craft moved from near the park's center 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 ballpark all though out the entire mission doing very small maneuvers.

Navigation With GPS

The GPS connection needs baud rate 115200 , for HGLRC F411, on UART1(TX1/RX1) as the following. All these configurations are part of the "dump all" file in operating note https://nocomputerbutphone.blogspot.com/2018/09/converged-iot-platform-build-notes.html . Softserial, as the 3rd serial line, controls the video transmitter and is already soldered on the S5 lead as shown in the build note. This arrangement is based on the  technical note from HGLRC.
The navigation depends on the 3 digits of coordinates as highlighted in the following video.  The historical definition of the metre dictates that the biggest of the 3 digits correponds to about 1km distance (actually about 1.1km on latitude and 0.9km on longitude). And diving requires 10m precisition, which is the smallest of the 3 digits. The heads-up display also shows the distance home, which is about 180m as shown in the thumbnail screen of the video. And the corresponding home latitude 3 digits is close to 021+(180m/11m) = 037, as shown at the landing of the video.The OSD elements' locations in the dump_all configuration https://drive.google.com/file/d/1_asy-pvVoEm3Tlr_Lams4AKPT4plXA37/ are pre-configured to be more centralized to the center of the video picture so that multiple substitute FPV cameras can see all the information elements. So, the exact element locations must be adjusted to align the latitude and longitude digits for each locale, except with the Nano3 camera in North America. For example, in the Eastern hemisphere, the missing negative sign of longitude pushes the decimal point one place to the left. The VTX setting does not use Pit Mode because the extremely low VTX power renders the video picture distorted and can be mistaken as hardware failure. The VTX setting is meant for SmartAudio VTX with 4 power levels, "powervalues 14 20 26 27" with the TBS Unity Pro32 Nano.

GPS glitches with solar flare and thick clouds are not uncommon. Here the backup is visual navigation.

FPV Landing Procedure

 Gyro-only mode landing often results in capsizing due to the drifting nature of the gyro 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 gyro-only mode also often results in a crash due to altitude drop with the large maneuvering nature of gyro mode. Gyro 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 too high at 0:05 in the video here below,
and the go-around at 0:06 results in a steep increase in craft speed and altitude drop, resulting in a crash. A seemingly smooth touchdown in gyro mode can still capsize due to the general high speed approaching the target in the last video on the right.
Forgetting about switching to attitude mode can occur during high workload situations such as combating high wind while locating an obstacle landing patch impromptu.
So, the trick is to flip SwitchC to use accelerometer-assisted leveling mode for the final approach, and that should be trained into the pilot's reflex because attitude mode landing is appropriate in nearly all circumstances. And there should be a time to familiarize the wind conditions after changing to attitude mode before the actual touchdown, as shown in the footage here    

NACA(NASA) 0015 And 0012 Airfoil Both Capabile Of Terminal Velocity Diving Pullout

The airfoil of SP-Oxy2-081 (black graphite nylon) blades and SP-Oxy2-086 (colorful nylon) are NACA 0012 and 0015 airfoils respectively. 

 

NACA 0012 airfoil stalls at 2 degrees earlier in attack angle as ploted here (50,000 Reynold's Number, between aqua color ncrit number 5 and soil color nrit 9). 

When pulling off a terminal velocity dive, the collective pitch needs to be delayed. Do not add a collective pitch first because helicopter physics dictates that the craft pitches upward with a positive collective pitch, resulting in stalled movement with a large collective pitch in a high sinking rate. The video on the right (with Sunnysky v2806 400kv motor and 20A ESC) shows the stalled, stumbled pulloff when collective pitch was applied too soon and forceful. The NACA 0012 airfoil pull-off requires more skillful, earlier, subtler cyclic pitch-up to keep the craft on the margin of stall while the stall lowers the craft; video footage below on the left. The NACA 0015 airfoil pull-off does not encounter stall; video footage below on the right.

4-series lipo is required in this procedure. The 3-series Lipo battery pulloff has a different procedure to avoid vortex ring state, discussed in the substitute parts chapter page, not on this page.

Camera Video Transmission

The 9cm video bus wire allows antennas to be on the front and the belly antenna close to the battery to allow steep tilt down while the craft faces the ground station.

The tubing of the Runcam Link antenna is of a stiff and brittle material. It is too long and can easily damage the coaxial cable. To remove a section of the tubing, use a rotary cutter to score (not cut through) the tubing material into 3 sections and give the middle section longitudinal scoring on 180 degrees opposite sides.

Once scored, the 3 seconds can be separated by hand, and the middle section can be crushed and split by pliers gripping at an off angle from 180 degrees.

Some sales of the 9cm video bus cable include a plate that needs to be removed. The plate is of molded metal and can be cracked with pliers (no rotary cutting needed). The video computer board uses 3 ziptie mount points. The lower aft ziptie needs pre-bending.

Plastic housing borehole of Walksnail Avatar 1S is only drilled diagonally from the factory. Drill the missing upper left hole with a 1.1 mm bit, so that a Kevlar string can be tied to fasten the camera onto the zip tie. But, fist insert another ziptie's knot to the ziptie to prevent the whole ziptie from rotating backward and rotating the cameras upward. The bbl gyro data file from the flight computer is loaded into blackbox.betaflight.com, as seen in the Hardware Modification section, to verify the right bbl file for Gyroflow processing. The FPV onboard recording video is also loaded into blackbox.betaflight.com to facilitate the verification of the bbl file for a video file.

It is well known that the Walksnail cameras' built-in gyro requires elaborate soft mounting to be valid. Walksnail HD V2's built-in gyro adds additional vibrations to the video when without the elaborate soft mounting, as shown in the following video comparison. The video on the left uses Betaflight black-box bbl gyro log; the video on the left uses Walksnail HD V2's built-in gyro gcsv log.

The 2 videos were stabilized in the same Gyroflow app session with identical parameters. The low-pass filter was tried with the Walksnail HD V2's built-in gyro (right-side video) without improvement.

The Kevlar tie fixed the diving vibration with a 5.6-gram Walksnail HDv2. The following 2 videos with their respective tie/missing-tie photographs beneath them are with HGLRC F722 Zeus mini; except for explicitly stated, most other videos on this page are not.

Substitution Walksnail HDv2 video transmitter's included video bus wire setup here.

In this configuration, the belly antenna is further from the battery, and when the craft faces the ground station, the antenna's line of sight may be blocked by the battery. It can be a risk depending on whether the ground effect for EM wave propagation is favorable, as shown in the video here.

Also shown here is the damage when landing vertically with the antenna tubing as installed from factory without modification.

Use Software Rendering Gyroflow; Do Not Use Rolling Shutter Correction

The GPU rendering of Gyroflow is not compatible with all desktop computers. Uncheck the GPU rendering with Chromebook Gyroflow1.6.AppImage , or err when attempting to render/save.

The rolling shutter correction, which should have been disabled, and the turning blades in HD footages with Gyroflow cause all jello/twitches in this chapter's videos wherever jello/twitches are present. It sabotages all videos, whether the original raw video is smooth or shaky, as shown in the following side-by-side comparisons.

 
 

 

The default settings in Gyroflow are all good except the rolling shutter correction. Disable it as follows.

Sources of jello are often related to shutter, as reported by Valley FPV below. A source of tremor is newer BLHeli_32 ESC that uses the same working frequency of 24kHz as the action camera's gyro sensor's working frequency, as reported by Valley FPV. But, according to the original BLHeli's manual, our ESC can not be (mis)configured to use the 24kHz working frequency.

When the helicopter blades are prominently visible in the HD camera's view, Gyroflow is confused, as in the video below on the left. Gyroflow's auto-sync shows yellow and orange flags of camera timing offset. The fix is to tilt the camera slightly down and away from the rotor blades, as in the video below on the right. 

   

Using the same craft build, the dive on the right was done one hour after the bad Gyroflow problem in the video on the left. There was no balancing work in the rotor in between. The FPV feed of the good dive is https://www.youtube.com/watch?v=1ryHxWiM1qU, which is similar in stability to the bad dive's FPV feed.

Software Gyro Noise Filter Does Not Rescue PWM 50Hz And Oversetting PID

The gyro data time series shows the Betaflight 4.3+ notch filter dramatically reduces the motor vibration noise in the following 2 screenshots. The comparison test was done with overturned PID and PWM 50Hz. Normally, PWM is set to 480Hz. All the prototype video tests on this page are done with PWM 480. There is no noticeable video improvement by the notch filter.

The actual video corresponding to the top gyro data time series (without notch filter) screenshot is at 0:29 here,

The actual video corresponding to the bottom gyro data time series (has notch filter) screenshot is at 0:28 here,

There is no subjective difference between piloting with and without a software notch filter with the HGLRC F722 Zeus Mini flight computer, which has a MPU6000 gyro chip. The dump_all configuration file does not have a notch filter, so that blackbox logs all movements of the craft for complete video stabilization.

Youtube Needs 4K 60FPS

The 2 videos are for comparison between uploading 1080p and 4k of the same video. If you watch them both at 720p, you will notice the difference when the craft is near the ground. The 1080p uploaded video has polygon blocks of blurs; the 4k uploaded video is closer to original video.

A one-minute 1080p video with H.264 encoding is about 400 MB. The above footage is 40 seconds long. Upscaling to 4k makes a file 250% as big. H.265 encoding makes a file 60% of the upscaled file size, about 400 MB as the end result. Both were 60 FPS.

540p uploading can not improve the polygon blurring, even though it reduces file sizes to 60% of the originals, as shown in the file listing below. The last four entries in the file listing below show that Gyroflow output at 720p can not reduce file sizes; the 30fps file at the bottom fifth listing has file sizes reduced by 25%, not 50%, at the expense of a very choppy viewing experience; Gyroflow produced 100% smooth videos that are more choppy in actual viewing, with only 10% file size reduction in the fourth and fifth listings. The AvatarS0162 and AvatarS0163 are nearly exactly 1 minute each.

.

Substitute T-Motor F722 Mini (US stock fast shipping)

When using the T-Motor F722 mini flight computer, the servo power tapping and the battery power input switch sides from the production build. This is because the signal bus of the flight computer is in the mirror orientation between the T-Motor F722 and HGLRC F722, as the following picture shows. This substitute flight computer is used in many videos in this page.

Flight software https://drive.google.com/file/d/1pg7u6Lu_YTL9cSmApZCHNXqaG0uHcQiw/view?usp=drive_link

dumpall https://drive.google.com/file/d/1JKzeFYqmqPGFbU8UPpW67yoY2VoHuNzC/view?usp=drive_link

When using this substitute for scientific investigation purposes, the dump_all file differs from the production build in PID sampling rate, gyro logging rate, gyro data filtering mechanism, and GPS algorithm, as follows,

test@penguin:/mnt/chromeos/MyFiles$ diff dump_all_converged_IoT_HGLRCF722.txt dump_all_converged_IoT_TMOTORF7.txt

# pinout/timer/dma/servo center/ truncated 510c504 < set gyro_lpf1_static_hz = 0 --- > set gyro_lpf1_static_hz = 125 512c506 < set gyro_lpf2_static_hz = 188 --- > set gyro_lpf2_static_hz = 0 529c523 < set gyro_lpf1_dyn_max_hz = 0 --- > set gyro_lpf1_dyn_max_hz = 500 574c568 < set blackbox_sample_rate = 1/2 --- > set blackbox_sample_rate = 1/4

# barometer/board/gyro orientation/ibata truncated 672c666 < set gps_ublox_flight_model = AIRBORNE_1G --- > set gps_ublox_flight_model = AIRBORNE_4G 710c704 < set pid_process_denom = 8 --- > set pid_process_denom = 1 714,715c708,709 < set simplified_gyro_filter = OFF < set simplified_gyro_filter_multiplier = 100 --- > set simplified_gyro_filter = ON > set simplified_gyro_filter_multiplier = 50 # camera control/pinio truncated test@penguin:/mnt/chromeos/MyFiles$

There is no difference between using lpf1 (my t-motor f722 setup) and lpf2 (my zeus f722 setup). Lpf2 filters before PID loop sampling the craft attitude; lpf1 filters after PID loop sampling, which is a Betaflight software design error. But the advantage of lpf2 is only to quash the aliasing noise frequency at the difference between gyro data sample frequency PID loop frequency. Here the t-motor f722 has no difference between the 2 frequencies - both are  8kHz.

The blackbox_sample_rate of 500 Hz in the production build is sufficient for generating fingerprints for Gyroflow to lock time-matching points.

A test with 125 Hz could not reliably make lockings of time matches. Gyroflow-smoothered video with a 500 Hz logging rate is in many videos of this page.

With the GPS connected to the same power source as the RF control receiver, the GPS power wires are twisted onto the receiver power wires. 

This allows GPS to be locked before powering on the craft with the battery. It is suspected to add interference to the gyro with the added active GPS electronics in the first few seconds of booting up the flight computer, which is the time when the gyro is calibrated by software. However, the test video on the right shows no more yaw drift than the production build's GPS powering scheme.

Sunnysky 2806 Motor On Carbon Fiber Shaft (US stock fast shipping)

Then, CA glue a #6 flat-head 1/2 inch machine screw as a pusher on the clamp.  Clamp the shaft up the second time with the push rod assembly, as shown in the picture, and remove the stock shaft of the motor. 

 It uses 3 Kevlar strand inserts for the Sunnysky 2806 motors on a worn carbon fiber shaft. 

The substitute 2806 650KV motor doesn't produce noticeable excess heat compared to a 2806 400KV motor. But, as expected, a 2806 motor has noticeable extra heating compared to a 4004 motor. This 650KV was tested in the previous section's HD camera tilt-down test. When using the Sunnysky substitute motor, trim the motor stater base as mandatory for friction fitting because the servo tabs are slightly longer than the bearing block height and protrude beneath the lower bearing block. During the pull-out of a shaft, the pressure exerted on the servo tabs and tab bolts can damage them and destabilize the servos if the motor stater base is not trimmed. As in the middle picture above on the right, all the black marked lines in the weighing picture are trimming lines. All rotary cuts are pre-cuts when trimming the stater base, leaving 1mm for safety from damaging the stater winding. Then, plier bending the material causes metal fatigue that actually makes the breaks. First, to trim the motor's stater base, preserve the outer ring as a guard against accidental rotary tool slips. Any rotary tool cuts are pre-cuts that don't go through the plate. Then, 6-inch long nose pliers bend along the pre-cut edges, and metal fatigue breaks the material. Trimming the 4004 motor stater saves 36.1-34.8=1.3 grams, as pictured below of the substitute 4004-300kv motor. The 2 pictures also reveal that the 300kv motor is about 2.5 grams heavier than the 400kv motor.

Weight breakdown of Sunnysky v2806 400kv motor - 43.8 grams. 25.828+17.748+0.2 (M3 bolt) = 43.8

Substitute Blade 180 CFX Rotor (US stock fast shipping)

The 193 mm blades' root needs to be thinned using a Lego planning sled, as shown in the following 6 pictures. The router's sled is made of 2 long, thin Lego bricks glued to the front plate of the rotary cutting tool.

The thin flat Lego brick that the blades are glued on can be reused after scraping the glue off. 

The final assembly, as tested in the "stock rotor" video, was without the hub-grip-gap washer because a test with the stock washer proved it too tight (with tactile movement during rotation). This picture here shows the assembly without the washer if you zoom in to the rotor hub.

When using the stock rotor, don't use fusion 180's DFC link (BLH05805) as they are heavy and easily bent as shown in the picture below in weighing at 1.222 g. If BLH05805 is unavoidable, turn the "dog bone" 8 half turns after purchase (4 full turns) to shorten the DFC link so that it is identical to the production build's Blade Infusion 180 DFC link length, which was used in the video with word "stockrotor" in the title in this chapter page. When turning 6 or 10 half turns, the resulting swash center test showed obvious deviation. Instead, use 180 CFX-Trio follower DFC link. The weight saving from Oxy2+180CFX parts is (6.2 + 0.8 + 0.9) - (2.934 + 0.806 + 0.889 + 1.014*2) = 1.24 grams. The grips are 1.57 grams lighter, but the CFX-Trio follower DFC links are 0.33 grams heavier.

The 180CFX follower DFC links are designed for a trio blade system, so the phase shift is not aligned with a duo blade system, so, trim the phase shift with a cutting disk as the following to get the correct alignment.

When installing his substitute DFC link, use CA glue on the outside and soaks the glue and withdraws the DFC bolt 1mm for 1 minute to let the glue cure, then unwithdraw the DFC bolt, as pictured here.

Do not apply CA glue directly on the DFC bolt because the glue seeping into the DFC bushing occurred in tests.

Non-viable Substitute iNav Flight Software

Our production build of the converted IoT platform has a servo order per iNav flight software, pictured here.

The HGLRC F722 Zeus Mini (20x20) can run either custom iNav or official iNav 8.01 software. The Walksnail OSD data works correctly with iNav 8.01 official software, as pictured here.

However, neither software allows "resource remapping," assigning the LED strip signal to the main motor ESC, as iNav is well-known for not allowing remapping. The iNav is not a viable substitution because there are no 5 physical signal outputs with the Zeus Mini board. As shown in the screenshot above of iNav 8.01 official software's resource section, the 4 servo ports B00, B01, B04, and B05 have physical solder pads, but the MOTOR1 at B06 pin does not. The pin B06 has no physical output as evident as motor 7 in default configuration in the default Betaflight software installed in the Zeus Mini because the physical output bus connector only allows 4 motor signal wires. The reason the motor is at the 7th output signal wire is because just above the first picture of this section is the plane's engine signal 7, depicted as s7. But, even if it were programmed as signal 5, it sill won't fit into the 4-signal-wire bus connector.

 

The custom iNav flight software should not have any servo output. The heavier 30x30 HGLRC F722 Zeus might have 5 physical signal outputs but its weight approaches 9 grams. 

Landing Skid Substitute 

The older Blade 230 landing skid has the same geometry, strength, and weight as the production build's Blade 235 landing skid.

ESC Substitute And Motor Heating Characteristics

The alternative is to use Favorite Littlebee 20A OPTO, also 1.25 startup power.

When using 1.25 startup power, the motor heat buildup curve is identical between the Littlebee and the Blade Thrust 20A ESC. After 3 minutes of attitude mode in-place hovering in hot air above 100F, the "lick" test indicates the motor core is too hot to keep the tongue in it, but the temperature drops to a comfortable warm-soup level in just a few seconds; in cool air about 60F, the core is only comfortable warm-soup level, never uncomfortable to keep the tongue in it. This setting is verified at https://www.youtube.com/watch?v=dL72Br5WKHw with 3280 RPM attitude mode and 3460 RPM diving/fast travel.