Converged AIoT Developer Kit | Build Notes | Operating Notes | Ground Station Setup | Near The Edge Of Space | Endurance | Weight 250 Grams Breakdown | Build and Operation Substitutes | Prototype
AIoT Use Yolo Model With Non-yielding Process
The options in the Zero form factor or smaller, accounting for weight, are in the following table. Gray highlights a trouble spot with possible workarounds. Sub-100MB SDRAM AI systems relies on limiting recognition models, such as car-and-pedestrian-only, reducing accuracy, and limiting applications. MicroPython is well-known for its unpredictable memory garbage collection schedule, which slows down the mission process and, even after disabling garbage collection, is 10-100 times slower than binary executables, making it unsuitable for production.
After burning radxa-a733_bullseye_cli_r6.output_512.img.xz (500MB download) with Chromebook or any Linux onto a USB-adapted SD card, before using it on the AI computer, modify the boot partition "before.txt"'s WIFI section's SSID/password, and find the AI computer's IP address by scanning with this bash command (change the IP network part of the address accordingly):
$ for i in {1..255}; do ping -W1 -c1 10.236.101.$i; done
. A WIFI router may change the first 3 octets of a host machine frequently, but the 4th octet $i generally stays the same for the same host machine's MAC address. So, once you figure out the AI computer's 4th octet $ i$, you will not need to run the scan again because your laptop, which connects to the same WIFI router, readily shows you the first 3 octets.
Use SSH to operate the AI computer. Then, enabling the camera:
radxa@radxa-cubie-a7z:~$ sudo rsetup # enter the "Manage overlays" menu selection choice
$ # also, disable hibernation in the "System" menu choice while in the rsetup
$ sudo apt update
$ # copy below to a text file and concatenate to a single line before executing
$ sudo apt install gstreamer1.0-tools
gstreamer1.0-plugins-base gstreamer1.0-plugins-good
gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly
v4l-utils libgstreamer1.0-dev gstreamer1.0-plugins-base-apps gstreamer1.0-rtsp
We need libOmxVenc.so/libOmxVdec.so to work with Allwinner's proprietary VPU hardware-accelerated h264 encoding/decoding kernel driver cedarc:
$ wget https://github.com/radxa/allwininer-debian/raw/7f592b79a85cb7b5ef86dabaf2016013b85a8d4d/packages/arm64/libcedarc/libcedarc-dev_2.0.0_arm64.deb
$ sudo dpkg -i libcedarc-dev_2.0.0_arm64.deb
$ sudo ldconfig
$ dpkg -l | grep cedarc
$ sudo apt install build-essential libasio-dev
$ sudo apt install libopencv-dev
$ sudo reboot
Please download this 200MB YOLO neural network model that runs on Vivante NPU invoked under GStreamer API .so library-based C++ program to transmit real-time video:
radxa@radxa-cubie-a7z:~$ tar -xzf awnpu_model_zoo-v1.0.0-20260423-f562dd16.tar.gz
radxa@radxa-cubie-a7z:~$ git init; git remote add origin https://gitlab.com/mpls-phone/converged-aiot; git fetch; git checkout -f main
radxa@radxa-cubie-a7z:~$ cd converged_aiot/
radxa@radxa-cubie-a7z:~/converged_aiot$ g++ -std=c++20 converged_aiot.cc ~/msp-master/build/CMakeFiles/msp*/src/*.cpp.o ~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/common/npuruntime/*.cpp.o -o converged_aiot -I ~/msp-master/inc/msp -I ~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/examples/yolo11 -I ~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/common/npuruntime -I /usr/include/opencv4 $(pkg-config --cflags --libs gstreamer-1.0) -pthread -L ~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/common/npuruntime/lib_linux_aarch64/A733/ -lopencv_core -lopencv_imgproc -lopencv_imgcodecs -lNBGlinker -lVIPhal -lm
$ sudo rsetup
$ cat ~/.bash_profile
sh /home/radxa/stream.sh
$ cat /home/radxa/stream.sh
cd /home/radxa/converged_aiot && LD_LIBRARY_PATH=~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/common/npuruntime/lib_linux_aarch64/A733/:$LD_LIBRARY_PATH converged_aiot_model=~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/examples/yolo11/model/yolo11s_6_uint8_a733.nb ./converged_aiot v4l2src device=/dev/video1 en-largemode=0 do-timestamp=1 ! video/x-raw,format=NV12,width=1280,height=720,framerate=60/1 ! identity name=add_crosshair ! omxh264videoenc control-rate=2 target-bitrate=4000000 ! h264parse ! rtph264pay ! gdppay ! udpsink host=10.11.138.190 port=9000 sync=false 2>&1 | grep -e PERSON -e BICYCLE -e tty
.
The converged_aiot executable is infused with the christianrauch/msp C++ library, which controls Betaflight. The pipeline is made of 7 segments (red->orange->yellow->green->cyan->blue->purple->) with an additional video picture manipulation:
Input: v4l2src eliminates the earlier Raspberry Pi models' two OS processes, I/O piping, and process-switching delays. The en-largemode needs to be turned off to prevent two-halves overlapped maximum photo sensor utilization, the do-timestamp enables more accurate time stamps with the SBC's system clock so that times between ground station and the craft don't drift apart and induce latency after hours of streaming, verified that turning it off does not reduce latency. Matchup: x-raw means the lowest delay with the parallel MIPI CSI ribbon cable. Do not be alarmed by the Radxa camera spec RAW10/RAW12 CMOS photo current value data mismatching the "NV12" image planar format. The VPU "secretly" converts RAW data from the MIPI CSI connector into NV12 color-space YUV planar data onto system SDRAM.This is also why a generic USB camera for Orange Pi Zero 3W has much more delay than the Radxa system. A generic USB camera converts RAW data to color space data (but not planar) in YUY format (Y, not V) in system SDRAM. Then YUY needs to be converted to YUV all in software, community support abandons Orange Pi's image and instead uses Radxa's image as a impossible solution. In addition, the next step h264 encoding hardware driver is also missing in Orange Pi's image. Identity is a hook for multiple custom C++ functions to modify the video picture, which we add a green crosshair. Video compressed data: Allwinner proprietary plugin code omxh264videoenc connects the gst process with the kernel module cedarc to use VPU hardware acceleration. The control-rate=2 is known to elimiate B frames that adds latency. Split the video stream into fragments of pictures. RTP header Codec h264 or h265 preamble at the very beginning of the stream. UDP/IP heade sync=false is verified to reduce 40ms latency, and the 10.42.0.x address is the ground station address when the AI computer also acts as a WIFI access point.
Viewing it in a bare-metal computer, such as a Chromebook dual-boot for minimum latency, by reversing the pipeline processes (purle->blue->cyan->green->yellow->orange->red)
$ sudo apt install gstreamer1.0-vaapi intel-media-va-driver-non-free
$ sudo -E gst-launch-1.0 udpsrc port=9000 ! gdpdepay ! rtph264depay ! h264parse ! vaapih264dec low-latency=true ! vaapipostproc ! autovideosink sync=false
The "-E" option allows displaying window of superuser account to display in regular account. The vaapih264dec decoder requires the low-latency=true setting to avoid the "standard" store-and-process-in-batch behavior, which is stuttering in real-time viewing. The AMD driver radeonsi_drv_video.so is open source and pre-installed in Ubuntu so that no counter part installation of "non-free" package as with Intel GPU.
For a test run, starting the application from the command line:
radxa@radxa-cubie-a7z:~/converged_aiot$ sudo LD_LIBRARY_PATH=~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/common/npuruntime/lib_linux_aarch64/A733/:$LD_LIBRARY_PATH converged_aiot_model=~/awnpu_model_zoo-v1.0.0-20260423-f562dd16/examples/yolo11/model/yolo11s_6_uint8_a733.nb ./converged_aiot v4l2src device=/dev/video1 en-largemode=0 do-timestamp=1 ! video/x-raw,format=NV12,width=1280,height=720,framerate=60/1 ! identity name=add_crosshair ! omxh264videoenc control-rate=2 target-bitrate=4000000 ! h264parse ! rtph264pay ! gdppay ! udpsink host=10.42.0.66 port=9000 sync=false > /dev/null
The glass-to-glass latency is about 130ms, as pictured here below (60fps), here(90fps), here(60fps), here(20fps), here(20fps), and here(20fps). It is well known in OpenIPC SSC338Q that changing FPS and resolution can significantly reduce latency. But in our SoC's architecture, the difference between 20 fps and 90 fps is not obvious.
This shows that adding the minimum video frame modification, such as the crosshair, does not add detectable latency.
Also shown in the above picture is the 10.42.0.x network IP address that is with the Radxa board acting as a WIFI hotspot AP, and there is no video latency improvement or penalty compared to having a dedicated WIFI router. Such an AP can be created with "sudo nmcli device wifi hotspot ifname wlan0 con-name radxa ssid radxa password ********" and viewed with rsetup, as shown in the picture on the right.
The AP configuration can be turned on and off without us completely losing access to the Radxa AI computer by setting either the WIFI client station before.txt configuration or this new AP configuration to "Automatically connect", but not both.
As soon as we toggle this AP configuration on or off with "sudo nmcli connection up/down <SSID>" to switch to the working network, we break the current SSH session to the Radxa computer using the previously toggled connection. All we need to do is abandon the broken SSH session (press tilde [~], then period [.]), then reconnect on the post-toggled network.
The following picture shows that it doesn't improve delay with a queue in the pipeline, changed frame rates, smaller resolution, and a heat sink. Actually, the missing "control-rate=2" added B-frames and a 50ms delay, and the missing "sync=false" added another 40ms delay. This test also showed that the software avdec_h264 is as fast as Intel's hardware decoder vaapih264dec when not processing 4K video, which is well known. But, independent of the additional latencies, the avdec_h264 and videoconvert have buffering stutters once every few seconds, which is also well known.
This picture also shows the mentioned "two-halves overlapped maximum photo sensor utilization" problem when en-largemode=1.
The alternative AIY Vision kit with Raspberry Pi image aiyprojects-2021-04-02.img allows setting up a Raspberry Pi without any HDMI monitor or FTDI terminal connection. Instead, an Android app Google AIY Projects gives your WIFI hotspot's password to the Raspberry Pi with Vision Bonnet board, as shown in the following screenshots.
Once the Raspberry Pi Linux system receives the WIFI password, it connects to the WIFI hotspot that assigns a DHCP IP address to the Linux system. From then on, the Raspberry Pi Linux system's pre-running SSH server accepts connection from any computer on the WIFI network.
The vision Bonnet needs to be removed to keep the takeoff weight below 250 grams.
Raspberry Pi's raspivid runs hardware-accelerated h264 encoding. And Raspberry Pi, by default, auto-log in to the "pi" user account, which invokes the "bashprofile" program. The setup in the craft follows (the AIY Linux system image has a default video transmission service, "joy_detection_demo", incompatible with the 1.6-gram, 160-degree FOV camera, and needs to be disabled).
pi@raspberrypi:~$ sudo apt install gstreamer1.0-tools
pi@raspberrypi:~$ sudo systemctl disable joy_detection_demo
pi@raspberrypi:~$ cat .bash_profile
sh /home/pi/stream.sh
pi@raspberrypi:~$ cat /home/pi/stream.sh
pi@raspberrypi:~$ cat .bash_profile
sh /home/pi/stream.sh
pi@raspberrypi:~$ cat /home/pi/stream.sh
raspivid -t 0 -rot 180 -b 1700000 -w 640 -h 360 -o - | gst-launch-1.0 -v fdsrc ! 'video/x-h264,width=640,height=360' ! h264parse ! queue ! rtph264pay config-interval=1 pt=96 ! gdppay ! udpsink host = 192.168.1.1 port=9000
pi@raspberrypi:~$
Alternative to gst-launch autovideosink app is Android's Raspberry Pi Camera Viewer by BigDotSoftware
The app in Android above is the setup, with the Android phone as the WiFi hotspot, itself at IP address 192.168.1.1, as the example, which is the target of h264 video streaming.
 |
| https://archive.org/download/yt-lZT_nN0aTgk/yt-lZT_nN0aTgk.mp4 |
The Viewer app must start receiving the video data stream before the video transmission starts because the app can not determine the video stream's frame positions in the middle of the stream. The app has an implied gdpdepay that determines the positions of the codec frames using the gdppay data at the beginning of the stream. In the video, the Viewer app starts at 0:02, and you can hear the craft powering up at 0:04 with ESC's beeping sequence. The receiving of the video data stream starts at 0:09 before video data transmission starts at 0:48.
This video also reveals the landing process with a line of sight, heading away from the pilot as it descends.
So, what is the fuss with VLC that we can not use it? The fuss with VLC is that it is a fuss. VLC is a GUI-oriented application well-suited to Android and other highly GUI-focused environments. It watches FFmpeg broadcasting using an SDP file (generated by FFmpeg) that contains codec parameters out of the box on Android, but the parameters for optimizing delay and buffering characteristics are buried in the GUI, not easily specified as in terminal/bash scripts. And VLC does not work on general Linux computers. The protocol for communicating codec parameters is a different paradigm from that used by gst-launch in GStreamer, so VLC cannot play gst-launch videos. VLC is stuck with FFmpeg broadcasting, and FFmpeg hardware-acceleration components are not supported by hardware vendors.
So why mute FFmpeg? FFmpeg is indeed a muting software design because it treats all streaming input/output/codec/conversion as independent parameters common in GNU free software, rather than the linear organization by processing sequence afforded by gst-launch in GStreamer. The linear organization by processing sequence is the correct, prominent design, favored by NVIDIA alikes. FFmpeg is still useful for non-customized, open-source, pure software input/output/codec/conversion. And without VLC's GUI, FFmpeg can capture and stream 640x480 videos and play them back with about 2.2 seconds of delay, more than 1 second faster than VLC. Using VLC to watch a 640x480 video from FFmpeg has about 3.5 seconds of delay, pictured below. All these multi-second latencies preclude them from real-time applications.
What happens when using the containerized internal Linux of a Chromebook to run the ground station computer is a 40ms extra latency of the socat forwarding process, as shown in Chromebook UDP Port Forwarding documentation. But the worst part is that the Chromebook kernel does not have VPU kernel modules readily compatible with containerized internal Linux's vaapih264dec and vaapipostproc libraries. Remember, the kernel is built by Google, and the vaapih264dec and vaapipostproc libraries are built by Debian for the containerized Linux, and are not coordinated with one another. The only option is the purely software avdec_h264 and videoconvert substitutes (which, as mentioned previously, have stuttered buffering every few seconds, in addition to the 40ms extra latency). To run sudo in container'ed internal linux of Chromebook, merge environment variables as so,
sudo xauth merge /home/$USER/.Xauthority && sudo DISPLAY=$DISPLAY gst-launch-1.0 udpsrc port=9000 ! gdpdepay ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink sync=false
.
.
What happens with extreme heavy load HD 60fps and every frame attempts to run full neural network object detection is 330ms latency, here in picture
See gitlab project for this setup https://gitlab.com/mpls-phone/converged-aiot
Avionics Computer With Stabilization Precedence In Air: The Only Solution
The racing drone avionics computer software is 2025's betaflight_4.5.2_STM32F7X2_HGLRCF722_f3b67204.hex. The configuration is dump_all_converged_AIoT_HGLRCF722_4pin.txt or dump_all_converged_AIoT_HGLRCF722_6pin, depending on the avionics computer hardware version, even though there is only one avionics software. The Configurator doesn't need to be installed; it runs online on a Chrome browser, and Chromebooks have the correct USB port permission out of the box.
The avionics computer can have 3 operating modes: pass-thru (no computer stabilization), accelerometer (leveling attitude), and gyro (holding attitude). But the pass-thru(manual) mode is not operable for the main rotor as shown in this video.
 |
| https://archive.org/download/yt-CsPT7BiAaVE/yt-CsPT7BiAaVE.mp4 |
tilt right and backward - 0:01
attitude mode to rescue - 0:02
tilt right and forward - 0:03
to attitude mode - 0:04
tilt left straight - 0:05
attitude mode - 0:06
tilt backward - 0:08
attitude mode - 0:09
tilt forward - 0:10
attitude mode - 0:11
landing approach too high - 0:25
backing off far and fast - 0:35
good landing approach - 0:40
touch down - 0:53
So, the OpenTX transmitter should engage in a stabilization mode before liftoff.
The problem of erratic, forceful PID Integral over-correction (winding) is common throughout nearly all helicopter avionics computers. An example of the same problem is with Blade230's AS3X; in the video on the right, during the spool-up, the error rolling to the right is at 0:14. This is because the PIDs are tuned for flying in the air when rotor RPM is sufficiently high, but the ground contacts force the craft attitude out of the planned aviation envelope when the spooling-up rotor RPM is too low to correct in time. To overcome this problem, we cancel the PID process and use pass-thru-manual mode during rotor spool-up. The spool-up RPM should be controlled directly by the pilot by the throttle proportion on channel 5 to ensure safety, and the pilot's control with the stick should only be relinquished and set by the fixed RPM with the pilot's explicit input on channel 6 switch, even when the throttle position reaches full speed. The spool-up options note discusses the reason for this channel switch assignment and the substitutes. The spool-up throttle channel setup is pictured here on the right.
 |
| https://archive.org/download/yt-WlGsfWhF-I4/yt-WlGsfWhF-I4.mp4 |
To solve the problems of the previous two paragraphs together, we configure the avionics computer to give the pass-thru mode a channel switch, and this channel switch for the pass-thru mode is tied to a constant negative collective pitch. The negative pitch prevents a takeoff while the pilot spools up the rotor with the CV1 curve. In blue bars, we highlight the disabling of the accelerometer and/or gyro sensors. The flesh color underneath all aviation modes is for the same set of PID coefficients throughout all modes.
To convert the fraction system to the avionics computer's PWM timing system, Betaflight/F7 needs to anchor the endpoints to the nearby 25 points of the 1000us-to-2000us range, which is the range the OpenTX can produce after 98% scaling of 989-2011us.
 |
| https://archive.org/download/yt-As-KcwBbU4I/yt-As-KcwBbU4I.mp4 |
 |
| https://archive.org/download/yt-LweuRPNU0Vs/yt-LweuRPNU0Vs.mp4 |
When the first mode does not set the collective pitch to -23(that prevents liftoff) via an extra channel one mixer page in a faulty improvised setting, the pilot may forget to switch channel six to the middle position when attempting to reduce time to takeoff to save battery life in the midst of enabling video recordings and operating other equipment. The result is forceful crashes due to the high power applied for takeoff and the high-speed drift of the manual mode. The video of such a crash is on the right.
When the transmitter and avionics computer setups are improvised out of sync, the takeoff can happen in gyro-only mode. This happens even after a hand-tethered hovering test because the gyro-only mode hovering can be successful without the pilot knowing that the modes are out of sync, for that gyro-only mode does have stabilization characteristics. Then the actual takeoff will, again, crash badly due to the high craft momentum nature of the gyro-only mode. The video of this gyro-only mode takeoff is on the right. This field fault occurs when we are tempted into setting a single 2-position switch on Aux2-channel6 for a cruise-only mission. In the field, the PWM for profile switching appears to need more than 33%, say 40% or 50%, weight to expand over the 1/3 spool-up region at a low position. And that is true for a 2-position switch, but Betaflight would interpret the high position (2000-1500)*0.4+1500=1700 in the gyro-only setting because the weight scaling is centered at 1500, not 1000, as depicted in the diagram on the right.
Betaflight is not replaceable with iNav avionics software: Our production build of the converted AIoT kit has a servo order per iNav avionics 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 avionics 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.
Motors: Use Multi-Rotor ESC Software For Fast Response
| Endurance prototype | Racing prototype | Converged production | |
| Main motor size | 4004 | 4004 | 2806 |
| Main motor RPM | 2640 | 3100 | 3250 or 3430 |
| Main rotor diameter | 18.6 in/472mm | 18.6 in/472mm | 16.1in/410mm |
| Li-ion Battery | 3 or 4 in series | 3 or 4 in series | 4 in series |
| Main motor software | MAIN | MAIN | MULTI |
| Tail motor software | TAIL | TAIL | MULTI |
| Main motor governor | Compensation with collective pitch | Compensation with collective pitch | BLHeli governor or Betaflight Vbat compen. |
| Avionics software | CC3D | CC3D | BF4.5.2 |
The endurance optimization chapter optimized the prototype power plant for racing with a 2806 motor with a 4-series (13.6+ volts) battery and 180 mm blades. According to airfoiltools.com data of the Joukowsky airfoil that has motor heating inline with the prototype NACA0015 blades, the production build uses the optimized setup. The motor heating at an extraneous collective pitch is just as good as the prototype power plant.
In prototype builds, it was not obvious whether fixed RPM will be required during takeoff and landing. The CV1 spool-up throttle curve picture on the right is super-imposed by collective pitch curve, and the 2 curves were simultaneously in effective with build test hovering. The test showed that the region between the 2 red dash lines had tail punches (yaw turn to the right), indicating insufficient RPM brought on by variable RPM configuration. So, the production build is determined to require fixed-RPM with ESC governor for both takoff and landing, not with the spool-up throttle curve. The question was which software among MAIN, MULTI, and TAIL to use with variable RPM in-air. And, MAIN code with the RPM governor disabled, resulted in a RPM change delay of roughly 3 seconds whenever throttle-up and resistance were detected. That meant when the protype craft descends too fast approaching an obstacle, I couldn't punch up the craft immediately because the ESC senses blade foil drags with throttle-up and gives small increments of torque over 3 seconds to prevent damage to the helicopter pinion/gear. There is no resistance reduction gearing in the gearless helicopter setup of our converged AIoT kit, so the ESC needs to apply the torque regardless of resistance, just like a multi-rotor system. The answer is shown in the BLHeli ESC assembly code, which indicates that the MULTI code is simpler/cleaner, without torque detection, and should be used in our AIoT production build.
The assembly code shows that MULTI code has all the MAIN code functionalities, including fixed-RPM governor, without the unwanted spool-up torque detection, and that MULTI code has all TAIL code functionalities except the unneeded idle spin, and hence the MULTI code should be used for both the primary and tail rotor of converged AIoT builds. To configure the ESC, we use the generic F722 Betaflight 4.2.5's passthrough USB-to-UART connection program with BLHeli Configurator Chrome WebApp. Betaflight versions newer than 4.2.5 often have bugs in the PWM protocol ESC passthrough, and version 4.5 completely removes the passthrough. Betaflight 4.2.5 binary hex file for the F722 CPU based avionics computer boards is betaflight_4.2.5_STM32F7X2.hex, downloadable here.
%20(1).png)
For the pass-thru program to work, the MOTOR 1 pin needs to be temporarily assigned to the SERVO pin of the tail motor(SERVO 4 in CLI), while the 4.2.5 software is not supported by the latest Betaflight configurator GUI. This means loading the dump_all config file into the CLI terminal (which is supported despite the GUI being unsupported) to do the "resource" reassignment commands and the "save" command. This also means forcefully running a "save" command after loading the dump_all config because there are command features of the version 4.5.2 software that are not supported by 4.2.5, and multiple errors occur during the loading of dump_all. In the above screenshot, the Betaflight software version is reloaded for configuring the ESC properly, but the resource reassignment is wrong, servo 5 instead of servo 4, and the result is the failure in flashing the ESC software, screenshot here. This means that the signal wire needs to be resoldered when flashing ESC software to the servo 4 lead.
Safety precaution dictates that motor power with ESC battery should be applied last after all connections and software are set up, and motor power should be the first to be torn down after any configuration/software flashing. With that in mind, power only the avionics computer by connecting a micro USB cable, start the BLHeli app, and click "Connect" with the default baud rate and auto-detected tty port. The computer now reboots into the USB-to-UART adapter program. But, wait, there is sometimes a 1-minute delay for the reboot to occur if the BLHeli program determines that the Internet connection is available but the software website is unreachable, so the best is to ensure Internet access of the laptop PC. Now connect ESC's craft battery power, then click "Read Settings" to connect to the ESC computer. If the "Read Settings" button is unavailable, it is still in the 1-minute period. After flashing ESC with motor software, remove ESC's craft battery power plug first as a safety precaution. Then tear down software/other connections. If you don't tear away the power, when the program switches back to Betaflight software, the motors will spin up to compensate for craft orientation or to match any unintended RF transmitter command signal, posing a great danger. The prototype "compensation" throttle setting for a specific motor, case-by case, is not applicable for large-scale deployment with varying hardware. The solution is to use ESC's RPM control PID governor or (future) avionics computer automatic Vbat compensation. I-Gain needs to be high at 3.00 to track RPM precisely. P-Gain at 0.5, to prevent motor governor oscillation. The governor in the MULTI software doesn't detect torque and has a much shorter acting time than 3 seconds. The entire configuration is as screenshot here. The latest, and last BLHeli version is v14.9, and the correct main motor RPM control gains (P=0.5, I=3), startup power (1.25), and damped off were determined during the endurance optimization building to reduce heating and prevent RPM collapse.
The production build uses Favorite LittleBee 20A Opto because the substitute DYS SN20A, as rebranded as Blade-Thrust, has multiple issues, such as this screenshot here, that need software overwrite.
.png)
With a software overwrite with DYS SN20 MULTI software version 14.9 (latest and last BLHeli version from opensource github.com, also downloaded here https://drive.google.com/file/d/1VR40QiSTiCpBNoLuRfzF2tX-r1SYDhEg/view?usp=sharing, https://drive.google.com/file/d/1VRZuM9waIJCqShnFd6Oaq3NoW2o6_C_5/view?usp=sharing), the ESC's life span is shortened to about 5 power cycles, resulting in short circuit (danger) or MOSFET failure.
.png)
⚠️ IMPORTANT TECHNICAL UPDATE: DYS SN20A / Blade-Thrust 4.35V Li-HV Failure Warning
DO NOT run 4.35V Li-HV cells on the DYS SN20A / Blade-Thrust ESC when flashed with BLHeli v14.9 MULTI firmware.
Recent testing has revealed an critical hardware-to-firmware architectural limitation that will permanently destroy this ESC within roughly 5 power cycles, resulting in a dangerous catastrophic short circuit or total MOSFET blowout.
The Root Cause of the 5-Cycle Burnout:
- No Dedicated Gate Driver IC: Unlike the Favorite LittleBee 20A (which utilizes an active MP1907 driver chip), the DYS SN20A relies on a cheap, passive network of discrete transistors to build the high-side voltage boost needed to open its N-channel MOSFET channels.
- Gate Deficiency & Thermal Runaway: Fully charging a 4S Li-HV pack hits the power rail with 17.4V, forcing the high-side gates to require nearly 27.4V to fully saturate. The passive discrete driver cannot build this overhead fast enough. The MOSFETs become trapped in their high-resistance linear conduction region, generating immense, localized thermal spikes.
- Shoot-Through Current at 17.4V: The hardcoded dead-time in the
DYS_SN20Av14.9 firmware target is explicitly calibrated for standard 4.2V LiPo boundaries (16.8V max). At 17.4V, the FET switching propagation delays slow down so drastically that the high-side and low-side FETs briefly conduct simultaneously (shoot-through), creating a direct battery short circuit.
Safe Operational Mitigation:
- Cap Voltage at 4.2V: If you must use the DYS SN20A hardware with v14.9 MULTI code, you must restrict your power supply to standard 4.2V per cell LiPo limits (or undercharge your Li-HV packs to a maximum target of 4.20V per cell). Dropping the rail to 16.8V restores the necessary switching speeds and prevents the linear region thermal collapse.
- The True Hardware Fix: For pure high-voltage endurance builds (like 4S Li-HV or deep-conduction 2S Li-Ion setups), the Favorite LittleBee 20A OPTO remains the mandatory production choice. Its active hardware charge pump guarantees full gate saturation under any voltage swing.
The 4.2.5 software does not have the one-click-installation feature to allow the installation of our production build's 4.5.2 software.
 |
| https://archive.org/download/yt-Zj24aEOyTWs/yt-Zj24aEOyTWs.mp4 |
So, once you finish using 4.2.5 software and are ready to move back to 4.5.2, use the bootloader button on the Zeus board to enter DFU mode, and then install the 4.5.2 software with the "No reboot sequence" option, as pictured here.
.png)
Calibration, configurator needs tentative(first click Live mode and don't click Save in the GUI) Servo 6's MIN set to the high position of 2000. The tail ESC is "Servo 5" in the GUI.
The tentative MIN position only takes effect after you click Enter or click on a different field in the GUI as shown in the screenshots above. The scaling is finalized when setting back to 1000 to save the calibration.The motor is not configured as a motor in the mmix section of the dump_all. The motor can not be controlled with Motors GUI because Betaflight motor mmix is tied to throttle channel T, a collective pitch channel in our AIoT build, after all other substitutes were ruled out.
Here the 200-point RF control (2000-point ESC control) calibration is assumed to perfectly corresponds to 1000us to 2000us RF transmitter PWM output, and if the RF transmitter uses the 989us to 2011us range, such as Frsky's X9 Lite or QX7, the RF transmitter needs scaling the channel by (2000-1000)/(2011-989)=97.8%.
 |
| https://archive.org/download/yt-PYnob2ACtBQ/yt-PYnob2ACtBQ.mp4 |
Research by SiieeFPV here shows that there is no definitive trend of startup power and stuttering.
So, the solution for the tail reset is not a particular startup power. But it was the most documented configuration with the production 1303.5 motor during extreme robotics build with tail ESC's startup power at 0.5 for startup without delay and without stuttering.
The configuration for racing for the tail ESC is the rightful solution for the converged AIoT, shown in the following screenshot and video. Damped off as required to prevent ESC overheating in summer, and is the only tested and documented setting.
|  |
This also enables the Low RPM Power Protection feature to protect the ESC in case of a crash when the propellers are stopped by the ground or other solid objects.
With the production dump_all PID configuration, the production build's tail reset is infrequent and needs deliberate efforts to reproduce the tail reset problem, as in the following 2 videos.
 |
| https://archive.org/download/yt-WGdQgZWNbdQ/yt-WGdQgZWNbdQ.mp4 |
 |
| https://archive.org/download/yt-GzQXtR7BZfU/yt-GzQXtR7BZfU.mp4 |
📝 Technical Update & Correction:
While initial troubleshooting pointed to multiple airframe and aerodynamic factors to fix the tail swing after a terminal velocity dive pulloff, the root cause was later identified as an inherited parameter mismatch in the ESC.
While initial troubleshooting pointed to multiple airframe and aerodynamic factors to fix the tail swing after a terminal velocity dive pulloff, the root cause was later identified as an inherited parameter mismatch in the ESC.
The flight controller configuration mistakenly used an ESC governor I-gain of 3.0, which was carried over from the older, larger 4004 motor setup. The higher dynamics of the new 2806 motor require a much more aggressive response to control tail authority in high-speed clean air. Increasing the I-gain to a range of 4.0 to 8.0 completely resolves the stabilization lag during the high-G pulloff.
Hover At RPM 3250 With 5.47° Collective Pitch For Fuel Economy
The endurance build and extreme robotics build investigated why the prototype NACA0015 blade's PIDs and collective pitch curves can be directly transplanted into the production build with a different airfoil, as well as the subtle differences. Here, we set the pitch curve identical to the prototype build when operating the pitch curve from the common PWM signal 1000us to 2000us.
Production PIDs and pitch curves ARE the prototype PIDs and pitch curves.
Prototye rotor RPM for level hovering is 2640/minute = 44/s . Rotor diameter 0.48m , speed at 3/4 blade span is 0.48m x 3.14 x 44/s x 3/4 = 50m/s . Reynolds number is 50m/s x 18mm / 1.46 x 100000 = 62,000 . It is very well known that the highest cL/cD (numerically equivalent to fuel economy) of NACA0015 between Reynolds number 50,000 and 100,000 is at alpha 6 degrees to 6.25 degrees.
For simplicity of collective pitch angle calculation, we choose servo arm length identical to blade pitch lever length, in the prototype build, 12 mm pictured above and on the right. The Oxy2 Sport grips and the Align 250 grips have congruent geometry as shown in the picture above. When all 3 pillars of the swash plate are raised evenly, the blade lever and angle are congruent to the servo arm and angle. The angle of travel of the RF control PWM 1000-2000 µs is 83 degrees in the above picture and 84.6 degrees in another test with the avionics computer PWM 1000-2000 µs, averaging 83.8 degrees.
As tested by FlightPoint, the angle of travel of PWM 989-2011 µs is 85.4 degrees, as pictured here.
Also in the -50 mix lines, the source 0 and 1 are stabilized roll and pitch respectively. Source 7 is throttle channel 1, not an aux(source 8+). The problem of assigning collective pitch control channel to Aux is that avionics computer TPA(Throttle PID Attenuation) and TPS(Thrust PID Scaling) only corresponds to throttle, not AUX. The consideration with throttle input channel 1 in TAER being recognized as the throttle means arming for throttle position should not near 1500us to avoid stick function commands. After considering all substitutes, the arming is set to have a large negative collective pitch for low throttle. This large negative collective pitch is set as the inverted hovering pitch angle for racing RPM, which is -23 points, or 1500-23/200*1000=1385us. The F7's min_check=1385us can mislead us to think that a hypothetical RF calls for -57 point of 1215us collective signal will be conflated to 1385us in F7 setup, but F7's signal 7 is raw RF signal, not processed nor conflated.
TAER is considered "american RC" by Christian Rauch in the MSP C++ code https://github.com/christianrauch/msp/blob/master/src/FlightController.cpp .
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 avionics 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.
.jpg)
One out of three purchases of the swashplate requies 2 loop strands of Kevlar inserts to fill the slop gap between the swash ball and servo rod socket, to prevent pitch trap instability, discussed here https://nocomputerbutphone.blogspot.com/2018/10/oxy-210-blade-characteristics.html. The prototype's optimal lift-to-drag ratio pitch angle doesn't mean the overall motor-propeller-battery combination is the most fuel-efficient, but just the propeller optimal. The production build is optimized for overall fuel efficiency and uses a 6.0-degree collective pitch for cruising. The production build's servo arm length is 2/3 of the grip pitch arm width, which attenuated the collective pitch by the same fraction, so the dump_all has an allocation of the swash movement needs to be exaggerated by the inverse of the fraction, 50% * 3/2 = 75%, as the following 3 lines,
smix 1 2 7 75 0 0 100 0
smix 4 3 7 75 0 0 100 0
smix 7 4 7 75 0 0 100 0
. The production build has collective pitch curve points 0, 15, 30, 45, and 45, same as the prototype build. The production build's first servo is on the back, the second servo on the left, and the third servo on the right, by the craft's own perspective.
The production build is more sophisticated and conveys 2 information points: neutral hover and mid-throttle stick. The prototype conveys only 1 information point: the mid-throttle stick is neutral hover.
This concludes that RPM 3250 in the production build gives the highest fuel efficiency (numerically equivalent to cL/cD) when the production build hovers in place at alpha 5.47 degrees. The NACA0012 airfoil (equivalent to cuspid 0010.5) has the highest cL/cD from alpha 5.0 to alpha 5.5 as Reynolds number goes from 50,000 to 100,000.
Swashplate Setting
For swashplate leveling, our spool-up is performed in manual mode. If the swash banks to one side of the craft, there is no PID correction by the computer and no heavy battery or long tail lever on the sides of the fuselage to counter the tipping. Use a zip tie with the half-cut end, as shown in the below picture, to check that all 3 pillars nearly touch the servo linkage. This zip tie should only be used after checking for enough room between the swash and the hub after booting up the avionics computer.
It is well known that servos accept PWM range 1ms to 2ms, or 1000us to 2000us. But, the consensus is that manufactures specify margin of error of 150us between avionics computer and servos when viewed in BLHeli configurator. So, it is safe to give servos PWM between 1000-150=850 and 2000+150=2150. The spline count of the servo arm is 15; the servo arm travels 83 degrees for 1000us. So, each spline dial notch is equivalent of 1000.0*(360.0/15)/83.0=289us PWM change. The actual testing result is that 1 spline dial is equivalent of 310us PWM at the near center. That means that when attempting to set the high-end PWM to larger than 1660us, you could dial the arm position up 1 spline and increase PWM on top of 1660-310=1350us, which will set the high-end PWM closer to the central 1500us in the tolerated range.
When changing the servo PWM center micro-second value, the change should be multiples of 10us because it doesn't have the resolution of the full 1000 PWM points; instead, it only changes with 1/100 of the full range. Considering that the full range of the servo arm is 83 degrees, 1/100 of the range is 0.83 degrees. To center the swash plate, check the top of the blade boltings pictured on the right. Change all the 3 PWM center neutral values 10us at a time. Indoor Hovering With RF Receiver With Proximity Cutoff
In the following video, XM+ receiver's LED starts out green, the transmitter antenna is shifted to create stronger radio coupling with the receiver at 0:01. The cutoff occurs at 0:02, the LED turns red, fail safe takes effect. The camera moves forward to zoom in to the receiver. The movement inadvertently shifts the transmitter antenna again , weakening the proximity coupling. The cutoff is released at 0:07, and LED returns to green.
 |
| https://archive.org/download/yt-oJo2eLmeVjw/yt-oJo2eLmeVjw.mp4 |
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 prototype, the receiver sits on the pedestal as appropriate for the small, geared motor under 22mm diameter of stater, spaced across the cage. In production, when 4004 direct drive motor is used center in the cage, the receiver signal is severely jammed by the spinning motor. So, production build does not use the pedestal.
Takeoff Procedure With Safety Checks Applicable To Both Prototype And Production
Motor bolting failure in-air has the same characteristic left turn, resulting in twisted tail motor wires and missing bolts after recovering the wreckage. The tail wreckage of such a case is pictured here on the right.
The takeoff procedure for the prevention of mechanical failures follows.
1. DFC bolts marking on the installed position. Twist the tail motor and tail props to see no loose screws.
2. Plug in the craft battery. Check the rough zero pitch and level of the swashplate. If the servo arm clutch is sprained during the last mission or handling, dial it to correct it.
3. Position the craft on the takeoff surface with friction that prevents it from sliding. Remember, during the spool-up of the main rotor, there is no counter-torque compensation unless the tail yaw is applied manually. The blades should not scrape grass or thin twigs on the ground because the initial spool can bend the foldable hinges, throw the rotor off balance, and sprain the servo arms.
The following steps show the OSD percent display of channel 1 throttle in a video clip for illustration only. Our base build does not require OSD; RF control transmitter LCD is. The corresponding RF control transmitter LCD point displays are next to the OSD percent. The production build hovers at 13%, 0.7 degrees, less collective pitch than the mid-stick position, but this is within the margin of error between build variations. In particular, the half-turn of the servo linkage ball socket can cause a collective-pitch "jump" with a thread pitch of 0.35mm. Remember, helicopter linkage rod threading is often "more coarse" than "standard coarse" metric thread pitching to allow deeper thread cutting and more robustly "grab" onto the rod material. And servo PWM resolution is about 10us jumps.
 |
| https://www.youtube.com/watch?v=rFdlgMNyZsU messed up with https://archive.org/download/yt-rFdlgMNyZsU/yt-rFdlgMNyZsU.mp4 |
4. Leave the craft and power on the RF control transmitter. The video above shows that the collective pitch changes from neutral to -4.8 degrees at 0:00 when the LCD display point of channel 1 throttle changes from 0 to -22.5. The throttle percent shown at OSD goes from 18 to 0. The 0 percentile display refers to the PWM signal at min_check from the RF transmitter, which is a negative collective pitch. The 18 percentile display refers to the actual neutral zero collective pitch at 1500us in the scale from min_check = 1386us to 2000us.
5. Arm the craft. This occurs at 0:00 of the video.
6. Spool up the main rotor slowly to the hovering RPM at 2/8 stick, as seen in the above video from 0:05 to 0:17, reaching the top red line of the soil color region in the table on the right. Slowly make the spool up so that the craft doesn't capsize due to an unbalanced rotor with folded blades. Then the craft should have no movement after the shaking because the friction of the ground overcomes the main rotor torque, and the negative pitch lift force presses down the craft firmly on the ground.
7. Switch on stabilization attitude mode with the throttle stick at 2/8 position, as seen in the above video at 0:18. The collective pitch will suddenly become positive 3.4 degrees, as shown as 14-15 LCD throttle point, also shown as 30 percent in the upper right OSD of the video. The craft will swing for a few seconds for computer stabilization to settle.
8. As shown in the video, raise the collective pitch to 3/8 stick from 0:18 to 0:24. The craft will stay on the ground.
9. Raise collective pitch toward 1/2 stick slowly; craft will reach neutral buoyancy between 3/8 and 4/8 stick and lift off at 25.5 throttle LCD display points or 39 percentiles shown in OSD, as shown in the video from 0:24 to 0:27.
10. If the drift is acceptable, raise the collective pitch to mid stick 4/8 at 29.3 throttle LCD display points, or 42 percentiles in OSD. The climb starts. At this point, the collective pitch is at the most fuel-efficient angle for level cruising as verified in the endurance build. To benefit from the fuel economy, start the forward movement of the craft to reach the optimal configuration.
Overall, the craft flies in the blue-sky region of the table on the right and stays on the ground in the green-grass region. The production build feels like a "punchy build" in flight because it has an extra 13% collective pitch beyond what's needed for hovering.
Reduce Trimming From RF Control
The Takeoff Procedure shows rolling to the right when switching to Attitude mode due to the required 4-degree tilt (align_board_roll = 4 in dump_all config) of the helicopter hovering physics. The RF control has a small right-roll trim. The rolling and self-correction don't need pilot input to correct. However, some builds may need a 5-degree tilt. If the avionics computer configuration is off and the roll trim is large, the RF control trim will cause more rolling than shown in the video and can be a risk for tip-over.
 |
| https://archive.org/download/yt-sz0uScNMNcA/yt-sz0uScNMNcA.mp4 |
Accidental Manual Spool-Up Mode
The negative collective pitch of the spool-up mode with tailspin somehow results in near-perfect craft inversion. In the footage on the right, the accident occurred at 0:05 during hovering with a hovering throttle (collective pitch) in attitude mode. The recovery is flipping the mode switch to attitude mode, keeping the same throttle (collective pitch) at a hovering level. The altitude drop from the corrective action of flipping the switch to attitude mode to stabilizing altitude is 6 meters.
Failsafe Setup
 |
| https://archive.org/download/yt-CMaeS6-ue3M/yt-CMaeS6-ue3M.mp4 |
Summary RF Control Setup
In gyro-only mode, the accelerometer is not used, and the outer loop calculation of PID in avionics software is zeroed, so the RF control's trim from the transmitter handset is inappropriate. And so, the roll and pitch RF control mixer should have 2 separate pages for each axis, one with trim, another without trim.
To summarize, with all substitutes rejected, the montage of 25 screens of created/edited pages are here below. Navigate-thrugh pages without needing to modify the page are skipped here.
 |
 |  |  |
|
 |  |  | ||
 |  |  |  | |
 |  |  |  | |
 |  |  |  | |
 |  |  | The above cell avoids mixing disarming channel 7 into a motor cut so that accidental disarming does not cause motor jerking when rearming | |
 |  |  |
The 26 pages don't need to be set up at once. For a hand-launched hovering test, one single mixer page on the left is all that is needed to map an RPM curve and a throttle pitch curve, and add an arming channel mix. As pictured on the left, the bare minimum pages serve as the first page for each channel's mixer, allowing the craft to continue building to its full capabilities. In the absence of channel 6 aviation modes, the default middle 1500us is presumed in the avionics computer, which assumes the accelerometer-stabilized mission.
Balance The Rotor Or Tip Over On Takeoff
 |
| https://archive.org/download/yt-gnn21smGVrQ/yt-gnn21smGVrQ.mp4 |
As seen in the video explanation on the right, vibration can result in seemingly deliberate mechanical movement that produces erroneous attitudes by the micro-electro-mechanical gyroscope during takeoff.
The building step of trimming the feathering shaft discovered that the feathering shaft slop contributes the most to a rumbaling unbalanced rotor. When the slop is larger than 0.2 mm, the infinitesimal imbalance shifts the feathering shaft to either side of the blades after spooling up, and the direction of the shift is unpredictable and only observed after spooling down. When the feathering shaft's centering slop is less than 0.2 mm, the balanced rotor with smooth hissing can easily be achieved with thin, clear tape squares of 1cm sides.
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 punch-up at 0:11, but video stabilization patches up the insufficient PIDs below on the right.
 |
| https://archive.org/download/yt-HctMf5u_FlE/yt-HctMf5u_FlE.mp4 |
 |
| https://archive.org/download/yt-3dlDJGPbN48/yt-3dlDJGPbN48.mp4 |
 |
| https://archive.org/download/yt-zmk7UEjQD1U/yt-zmk7UEjQD1U.mp4 |
 |
| https://archive.org/download/yt-NDLGmJJ1axI/yt-NDLGmJJ1axI.mp4 |
Make Rotor Stiffness Consistent And Balanced For Stable Video
A prototype with overly loose grips that draped before turning the craft to the side 90 degrees, as the video below on the left shows, was recorded to have off-standard PID settings, as in the video below on the right.
 |
| https://archive.org/download/yt-O2LQsu6K7kk/yt-O2LQsu6K7kk.mp4 |
 |
| https://archive.org/download/yt-JVFXiyKf_lg/yt-JVFXiyKf_lg.mp4 |
For consistency, we set the drape at 90 degrees as the "standard" because we don't have a consistent gauging method.
| Stuck Blades At 90+ Degrees | Blades Drape At 90 Degrees | ||||||||
Raw video has mast bumpings during a dive
Post-stabilization cannot fix the mast bumping
| Immediately after loosening the bolting
Post-stabilization results in undetectable bumping
|
Change Rotor RPM With Locale/Weather
According to the NASA education page screenshot below on the left, density affects blade lift linearly; in the screenshot below on the right, the lift is proportion to RPM to the square power. Using binomial approximation, blade airspeed RPM should be adjusted by half the percentage of air density change with weather reports.
Overclocking RPM can cause craft instability and/or vibration because the avionics computer PID gain is tied to rotor angular momentum and proportional to rotor RPM.
Our reference condition is the middle of the Fahrenheit scale of 0-100, 50 degrees Fahrenheit, 10C temperature for RPM 2643 at 27 throttle points in the -100-to-100 points scale of the 1000us-2000us PWM signal range. Weather, temperature, and pressure can change air density from normal conditions by 11%. For example, a typical winter temperature weekly low of -10C produces air density 293.0/(293-20-10)=1.11 times the reference air density around Boston suburbs. Barometric pressure generally does not affect air density as much as temperature; for example, a 13% pressure change from 30 inHg to anything below 26 inHg would approach world records for the eyes of an intense cyclone. On the other hand, locale consideration for elevation, many cities above the elevation of 3000 feet, such as Tucson, northeast of Los Angeles County, El Paso, Denver, can reduce air pressure by 11% by altitude. However, the simple square relation doesn't consider turbulence effects with Reynold's number, and the simple square relation consistent for both drag and lift in response to blade speed change would contradict the deviation of Cl/Cd ratio curves when Reynold's number changes. The effect of blade speed is more powerful than the second power proportion because the higher the blade speed, the higher Reynold's number and the higher the Cl/Cd ratio. So, we will use a spreadsheet table on the right for RPM adjustment, approximating the blade speed effect to the 2.5th power.
AI Shahed Tracking/Intercepting
The converged_aiot executable in the converged_aiot.tar.gz package uses the very popular christianrauch/msp to command Betaflight on roll/pitch/yaw setpoints. Currently, it sets the roll/pitch/yaw attitude to a fixed continued navigation path before engaging the autopilot/navigator, while the video streaming continues in a separate thread in the main program.
TODO: With the publicly available Shahed loiter munition YOLO model, similar to https://zir-system.com/en/product/automatic-guidance-module-zir-ai-betaflight/, we need to integrate converged_aiot's fcu_thread with detected object screen coordinates to steer the craft with the setRPYT() function accordingly. Engineering page here.
ToDo: to synchronize with CC3D:
set gyro_lpf1_type = PT1
set gyro_lpf1_static_hz = 20
set gyro_lpf1_dyn_min_hz = 20
set gyro_lpf1_dyn_max_hz = 20
set gyro_lpf2_type = PT1
set gyro_lpf2_static_hz = 53
set dyn_notch_count = 0
save
set dterm_lpf1_type = OFF
set dterm_lpf1_static_hz = 0
set dterm_lpf1_dyn_min_hz = 0
set dterm_lpf1_dyn_max_hz = 0
set dterm_lpf2_type = OFF
set dterm_lpf2_static_hz = 0
save
