Typhoon H 480 PX4 v1.10 (Stability issues ;-)

h-elsner · Dec 16, 2019

Surprise: I found one MCU unit from H480 that has a SD card slot mounted. Indoor test was not successful. The SD card remains empty (used a fresh formatted with FAT32). File system remains untouched.

@Pöllö: If you want, I can send you this part. Maybe the SD-card can be adressed somehow. Getting ulog files would be nice.

Seems they use the CPU als IMU heater or why is the IMU placed in this brass block?

BTW: The telemetry on ST16 will be stored as usual in the FlightLog directory? Or will we get tlog files as usual in PX4?
I think the ST16 firmware was untouched, or?

One great feature would be GPS on/off by Aux-Button (Switch) = CH12.

br HE

h-elsner · Dec 21, 2019

@Pöllö
Regarding the telemetry: I don't know what you have solved up to now but looking at the code in #38 I wonder how you found the meaning of all this communication. I spent a lot of time to understand the values in telemetry but with minor success. Due to a missing documentations from Yuneec it is a lot of guessing.
Interesting that current is in 0.5A steps. I have updated my charts with that. Status bytes are still a mysterium for me.
The optionbytes containing flight mode and vehicle type. From my point of view those are enum. My enum matches a lot of your observations.

f_mode	Meaning	Display
0	Stability mode (Blue solid)	THR
1	Blue flashing - GPS off	THR
2	Blue - GPS lost	THR
3	Angle mode (Purple solid)	Angle
4	Purple flashing - GPS off	Angle
5	Angle mode (Purple solid) - GPS lost	Angle
6	Smart mode	Smart
7	Smart mode - GPS lost	Angle
8	Motor starting	Start
9	Temperature calibration	Temp
10	Pressure calibration	Pre Cali
11	Accelerator calibration	Acc Cali
12	Emergency/Killed	EMER
13	RTH coming	Home
14	RTH landing	Land
15	Binding	Bind
16	Initializing, Ready to start	Ready
17	Waiting for RC	No RC
18	Magnetometer calibration	Mag Cali
19	Unknown mode
20	Agility mode (Rate)	Rate
21	Smart mode - Follow me	Follow
22	Smart mode - Follow me - GPS lost	THR
23	Smart mode - Camera tracking	Watch
24	Camera tracking - GPS lost	THR
26	Task Curve Cable Cam	CCC
27	Task Journey	JOUR
28	Task Point of Interest	POI
29	Task Orbit	ORBIT
32	Indoor Positioning System	IPS
33	Waypoints	WAYPOINT

Value	Vehicle Type
1	Yuneec H920
2	Yuneec Q500
3	Blade 350QX
4	Blade Chroma (380QX)
5	Yuneec Typhoon H or H Plus
6	Reserved for H920+ but never used
7	Reserved for H520 or Typhoon H+but never used

Alarm byte 0 seems to be:

Bit	Error Flag
7	ERROR_FLAG_AIRPORT_WARNING (NFZ)	1000 0000
6	ERROR_FLAG_FLYAWAY_CHECKER_WARNING	0100 0000
5	ERROR_FLAG_COMPASS_CALIBRATION_WARNING	0010 0000
4	ERROR_FLAG_TEMPERATURE_WARNING	0001 0000
3	ERROR_FLAG_COMPLETE_MOTOR_ESC_FAILURE	0000 1000
2	ERROR_FLAG_MOTOR_FAILSAFE_MODE	0000 0100
1	ERROR_FLAG_VOLTAGE_WARNING2	0000 0010
0	ERROR_FLAG_VOLTAGE_WARNING1	0000 0001

Note: My observations are the output in telemetry from ST16, not the input from SR24 serial.
All I found is here in chapter 3: http://h-elsner.mooo.com/pdf/Q500log2kml_en.pdf
Or in GitHub: h-elsner/Q500log2kml

br HE

Pöllö · Dec 22, 2019

dylanfm said:
I have been working on the CGO3+ serial communication for about a week now. Here are my observations:
- It is 115200 8n1 LSB first.
- The first byte is 0xFE
- 2nd byte is the total length of the packet minus 10 (size of the payload? implying the header is 10bytes?)
- 3rd byte is the sequence number/packet count.
- There are a lot of different packet sizes, but I focused mostly on the 0x1A packet because that seemed to vary when I changed the switches and knobs on the ST16.
- In the 0x1A size packet, bytes 24 and 25 are the gimbal pan command (ST-16 K1)
- In the 0x1A size packet ,bytes 26 and 27 are the gimbal tilt command
- In the 0x1A size packet, I think that bytes 28 and 29 are the tilt mode switch (ST-16 S1) but I need to verify that
- In the 0x1A size packet, bytes 30 and 31 are the pan mode switch (ST-16 S2)
-I'm pretty sure that the last 2 bytes are a CRC and have spent most of the week trying to decode it without much luck.
-Right after start up the TH sends 3 almost identical short packets to the camera. They have 3 byte payloads (13bytes total), and the only values that vary are the sequence byte and the 2 CRC bytes. I have been trying to use those to decode the CRC, but I'm almost sure there is additional info that is being included in the CRC calculation
- Last night I found that the packet format is pretty similar to the Mavlink V1 protocol (Serialization · MAVLink Developer Guide). The first 3 bytes are the same. It is different in that the header size is only 5 bytes. The Mavlink V2 protocol has a 10 byte header, but then other parts of the packets don't match. Maybe it is a combination of v1 and v2? maybe it is customized in some other way?
- IF it is Mavlink like, then there is a CRC_Extra byte that gets added into the CRC calculation somehow. The CRC_Extra byte the CRC of the string name of the message id. So if it uses the standard mavlink message names and ids, I should be able to figure all of this out. I think I'm going to start with finding some arduino code to decode mavlink messages and then feed some packets into it and see what happens.

Hi dylanfm,

That sounds great, fantastic job! If we could get the communication between the camera and drone resolved, that would open the ST16-initiated calibration functions, backup control link, pan control, OTA FW upgrade and probably some of those "smart modes" for custom-built drones and the Thunderbird. ;-)

As the Thunderbird is getting ready for first release, I could also take a look at those (probably next year ;-). Interesting that it uses the Mavlink-ish protocol.

About the CRC, have you tried the st24_common_crc8(); above? The SR24 uses only one byte for the CRC, that extra CRC byte sounds quite exotic.

Br, TR

Pöllö · Dec 22, 2019

h-elsner said:
Surprise: I found one MCU unit from H480 that has a SD card slot mounted. Indoor test was not successful. The SD card remains empty (used a fresh formatted with FAT32). File system remains untouched.
View attachment 19386

@Pöllö: If you want, I can send you this part. Maybe the SD-card can be adressed somehow. Getting ulog files would be nice.

Seems they use the CPU als IMU heater or why is the IMU placed in this brass block?

BTW: The telemetry on ST16 will be stored as usual in the FlightLog directory? Or will we get tlog files as usual in PX4?
I think the ST16 firmware was untouched, or?

One great feature would be GPS on/off by Aux-Button (Switch) = CH12.

br HE

Wow! Good find! I am definitely interested in getting that part! ;-) Please tell me how much you would like to have for it and for its shipping. ;-)
I have one main board too with the SD card slot soldered on, but I wanted to keep that unmodified. It is in my first Typhoon, that is a very early model that I want to keep stock, from first batches that were delivered to Finland when the drone was new, and I discovered the presence of the SD slot in it only couple weeks ago.

It seems, that Yuneec has made some cost-down "improvements" on the TH during its life, like removing the slot and components related to it. The SD card is probably not used for anything in the stock firmware, but the PX4 is capable of storing flight logs and parameters to it. Actually, it is more common for the PX4-enabled flight controllers to have a SD card slot, than not. This caused me some issues when porting the PX4 to Typhoon. The Thunderbird, being based on Omnibus F4SD board target on the PX4, saves parameters on STM32's Flash, right after the bootloader and before the actual PX4 code. Due to limited amount of writes and the behavior of the STM32, no flight logs can be saved to STM32's flash as writing it halts the program execution. Which is pretty nasty when the very same program tries to fly the machine.. ;-) I think there is no reason why we could not write the logs to the SD card on boards that have it.

The board with the SD card slot in place, is probably from a rather old Typhoon. The later ones could be probably also retrofitted with one if required.

There indeed is a IMU heater inside the brass block. It is software controlled, the driving circuitry is on front-facing edge of the board. At the Thunderbird FW, I am currently having the heater "always on", that heats the MPU 6050 to 40-50 degrees of C. I am going to make that controllable by the PX4 before summer... ;-) The MPU 6050 IMU does not like cold at all. Nasty things start to happen, when the temperature drops below -8 C. If an unheated MPU 6050 is providing data for a camera gimbal, it starts to tumble (Like the Yuneec GoPro gimbal). Or if it runs a drone in a board like Naze32, the drone tumbles, too.

The ST16 is completely untouched .. for now. ;-) Even the profile is intact, I wanted to keep it that way, so that the Thunderbird would be as easy as possible to use. The GPS on/off is already there, too. On my drone (and in the parameter file I will release), I have mapped the flight mode switch so, that the top position is Stabilize (same as flying the stock TH with GPS disabled), the middle position is well, Position (like normal stock TH) and RTH is RTH. Of course, you can map these how you like, here are the flight modes that are available: Flight Modes · PX4 v1.9.0 User Guide

In the attachment there are two of my mainboards. The upper one is the one I am using for development, with SWD wires attached to make my development easier. I removed the IMU when I was probing the board, and I was a bit worried if I could reattach and align it properly... until I saw how precisely Yuneec aligned it on the lower board.

Br,

TR

h-elsner · Dec 22, 2019

Pöllö said:
About the CRC, have you tried the st24_common_crc8(); above? The SR24 uses only one byte for the CRC, that extra CRC byte sounds quite exotic.

It looks like a 16bit CRC. The whole discussion about the serial link to the gimbal/cam was moved out from here tp avoid "hi-jacking" your thread.
Here it is: CGO3+ serial link

br HE

Pöllö · Dec 22, 2019

h-elsner said:
@Pöllö
Regarding the telemetry: I don't know what you have solved up to now but looking at the code in #38 I wonder how you found the meaning of all this communication. I spent a lot of time to understand the values in telemetry but with minor success. Due to a missing documentations from Yuneec it is a lot of guessing.
Interesting that current is in 0.5A steps. I have updated my charts with that. Status bytes are still a mysterium for me.
The optionbytes containing flight mode and vehicle type. From my point of view those are enum. My enum matches a lot of your observations.

All I found is here in chapter 3: http://h-elsner.mooo.com/pdf/Q500log2kml_en.pdf
Or in GitHub: h-elsner/Q500log2kml

br HE

Hi HE,

Thanks for the information, awesome work with the Q500Log! ;-)
There are indeed plenty of similarities with your charts, although what is transmitted over the air, seems also to differ slightly. It was indeed a lot of guessing to resolve the contents of the telemetry protocol. There was some code already in the PX4 which was a good starting point, but few items like the status and option bits I had to resolve by myself.

How I found the meaning for the bits was basically good old black box protocol sniffing. ;-) I managed to find one Typhoon with no arms, landing gear etc. that I used in testing and development. I wired the SR24's TX (outgoing) wire to USB to Serial adapter, and started capturing telemetry traffic of the stock TH in various configurations (Drone inside, outside, gps / mag removed etc.). That, combined with the PX4's st24.h and some hints online, gave me a good starting point for the protocol. I then wrote that Arduino sketch that I pasted here, and started to toggle the individual bits on the bytes while observing how the ST16 reacts, which eventually revealed me the meaning of those bytes. ;-)

Br,

TR

h-elsner · Dec 22, 2019

I will send you a PN.

Pöllö · Dec 22, 2019

The Thunderbird is now based on the PX4 v1.10.0 stable and after many test flights I am starting to feel confident to release it... ;-)
The weather has been pretty hostile here, so majority of test flights have been done in complete darkness and no major issues were found. And I have done some really stupid things with it, trying to deliberately make it malfunction. ;-)

Here are two videos for you to see:

Here is how precise and stable it actually is. The deadzone is gone, so no cruise control etc. is needed for smooth low-speed flying. ;-)
(The Typhoon really does not want to go back to its box... ;-)

And here is test of different flight modes and their behavior. A smooth takeoff, a full power climb (The Thunderbird really lives up to its name, this thing can be brutal!) in Stabilize mode, then some smooth low-speed flying in Position mode with no cruise control (it is there if someone still needs it ;-) and the flight ends with a completely autonomous Return to Home / Failsafe landing with no radio control.

dylanfm · Dec 22, 2019

Pöllö said:
Hi dylanfm,

That sounds great, fantastic job! If we could get the communication between the camera and drone resolved, that would open the ST16-initiated calibration functions, backup control link, pan control, OTA FW upgrade and probably some of those "smart modes" for custom-built drones and the Thunderbird. ;-)

As the Thunderbird is getting ready for first release, I could also take a look at those (probably next year ;-). Interesting that it uses the Mavlink-ish protocol.

About the CRC, have you tried the st24_common_crc8(); above? The SR24 uses only one byte for the CRC, that extra CRC byte sounds quite exotic.

Br, TR

I did try the ST24 CRC functions. The discussion as been moved to this thread:

CGO3+ serial link

@dylanfm: I'm intrested in that MAVlink-like message format that you found. Up to now I saw two different format in the sensor files, one from Typhoon H has packet start ID &BC and the messages from Typhoon H Plus start with $FD. The last one van be decodes according this: mavlink/c_library_v2...

yuneecpilots.com

Ultimately I was able to calculate the CRC using the Mavlink Checksum and an CRC_extra bye =0 (It doesn't come out right with out that).

h-elsner · Dec 23, 2019

Perkele! This works great. A second life as fun-copter for the old H480.
May I get the FlightLogs from ST16 of those test flights? My e-mail is in the PN.

Pöllö said:
Realsense (I don't have one and that one could be a bit too time consuming to implement regarding its use cases.. ;-)

RealSense is something nobody really needs, especially for a fun-drone. Intel used Yuneec as "test platform", no more.

br HE

Pöllö · Dec 23, 2019

Here it is! ;-)

Source repository:

GitHub - tonirosendahl/Thunderbird: Thunderbird Firmware, A fork of PX4 Autopilot Software for Yuneec Typhoon H

Thunderbird Firmware, A fork of PX4 Autopilot Software for Yuneec Typhoon H - tonirosendahl/Thunderbird

github.com

Compiled binaries:

Thunderbird/Thunderbird_19122019_FT.zip at Typhoon_H_480 · tonirosendahl/Thunderbird

Thunderbird Firmware, A fork of PX4 Autopilot Software for Yuneec Typhoon H - tonirosendahl/Thunderbird

github.com

The firmware binaries (bootloader and main autopilot firmware in the zip file) are the same that are flown in the last two videos. Actually, those flights were intended to be last test flights before releasing the firmware for you. ;-)

I am going to write a proper documentation for this of course and update my first post accordingly when I have finished it. However, very rough instructions: connect the test pads to STLink flasher or STLink on the STM32 Nucleo development board (see photos below, I am using https://www.st.com/en/evaluation-tools/nucleo-f767zi.html). Use STM32 ST-Link utility (STSW-LINK004 - STMicroelectronics) to verify connection. Remove RDP protection using the ST-Link utility. This erases Yuneec's bootloader and original firmware. Please note, that you can NOT get them back any more. The TH is going to be the Thunderbird from now on. ;-) Flash the bootloader using ST-Link or stflash on Linux (see the bootloader script inside the zip). Then connect the usb and use the python script to flash the main firmware. Launch QGroundcontrol, restore the .params file. It has my PID tuning values and settings. Do sensor calibrations (dont use mine!) like you would do for a fresh PX4 drone (see Basic Configuration · PX4 v1.9.0 User Guide ). Do not try to calibrate ESC's; it will not work and is not required. Verify settings, check calibrations and sensors. In my settings, the top position of the flight mode switch is Stabilize (Typhoon without GPS), middle position is, well, Position (Typhoon with the GPS) and bottom one is RTH. The acro/rattitude mode are not there, be careful with those. The red button does NOT arm or disarm the drone. How to start it - you have to find out this by yourself by going through the PX4 documents for this one (As it is highly recommended to read how to operate the PX4, I want you to take a look at them). Arming and disarming (this is important to know!) requires the speed selector to be in FAST mode. You do not have to do anything in ST16 side. Stock settings there are OK. If you want to re-bind, run "bind" command on the PX4's command line. Bind and reboot. Go flying and have fun! ;-)

Merry Christmas! ;-)

Pöllö · Dec 23, 2019

h-elsner · Dec 26, 2019

I have prepared my MCU board for flashing with small socket connectors. Matching pins come from legacy electronic parts like resistors.

Programmer board was ordered. Beginning next year I'm ready to flash (or finally burn) my spare MCU...
I'm really curious about that.

br HE

Pöllö · Dec 26, 2019

h-elsner said:
I have prepared my MCU board for flashing with small socket connectors. Matching pins come from legacy electronic parts like resistors.

Programmer board was ordered. Beginning next year I'm ready to flash (or finally burn) my spare MCU...
I'm really curious about that.

br HE

Looking good! Unless you shorted something out while soldering, burning your MCU board using the SWD would be quite a stunt. Please take care of ESD precautions, however, while handling the board and the open drone. ;-)

There are two jumpers on the Nucleo board, near the SWD header. When they are in place, the ST-Link flashes the Nucleo's F7. If they are removed, the ST-Link flashes whatever is connected to the header. Remove the jumpers and connect the board to the computer. There are two USB connectors, one is on the ST-Link (that removable part of the board) side, another one is on the opposite side. This is USB OTG for the F7. What is good to know, that there is a warning in the manual that the board does not like to powered from this. Use the ST-Link's connector.

Install the STM32 ST-Link utility, it is available here: https://www.st.com/en/development-tools/stsw-link004.html
Manual: https://www.st.com/content/ccc/reso...df/jcr:content/translations/en.CD00262073.pdf

Go to Target -> Connect to verify that the MCU is connected. If not, check the wiring. Set RDP protection to level 0 on Target -> Option Bytes. RDP Level 0 = No protection. 1 = Memory Readout Protection (you can not read back data from the Flash: Yuneec's bootloader and application), 2 = Memory protected, debug disabled AND this is permanent = do not set this one. Going from 1 to 0 erases everything, and there is no going back from here.

Go to Target -> Program & Verify. In my binary zip, tonirosendahl/Thunderbird , there is "omnibusf4sd_bl.bin". Flash this to the MCU. This is a bootloader from OmnibusF4SD board, that has CGO3+ PWM initialization pulse added in my lazy and ugly way. ;-) When the CGO3+ serial communication gets resolved, this init pulse is no needed and an unmodified bootloader could probably be used. But until then, no ST-Link is needed from now on.

The MCU has now a PX4 bootloader, placed in the beginning of the Flash, 0x8000000. This is where the ROM bootloader starts up, whatever there is. There is no way to brick the STM32, the ROM bootloader will always be there, and the bootloader you just flashed, is a "second stage" bootloader, which is started by the ROM bootloader. The MCU or the ROM bootloader does not actually care what is placed into 0x8000000, whatever there is, gets started.

The actual PX4 firmware is compiled and linked so, that it starts from 0x8008000. That gives some space to save parameters, between the bootloader and the PX4 main application. The linker script, if interested, is at Thunderbird/boards/yuneec/typhoon_h/nuttx-config/scripts/script.ld but you should not need to modify it. If you want to ditch the PX4 bootloader and save parameters on a SD-card, then this is the place to modify the PX4 to start from 0x8000000. But for now, do not modify anything there. ;-).

Now, there are two ways to flash the main application.

A) The bootloader way: The PX4 bootloader you just flashed, is capable of flashing the main application via Typhoon's USB and then start it, from address 0x8008000. No need to use the ST-Link any more; you can close the drone's lid. The bootloader has few seconds delay for flashing. The flashing is done using a slightly modified px_uploader.py script. Clone my repository to get these. This script requires the .bin file to be converted to .fw file (also in the zip) after compiling. See the "flash_typhoon_bootloader.py" script, write your COM port there, and while the script is running, connect the Typhoon to your computer. I do my development in Ubuntu 16.04 LTS, I don't know how this works in Windows, I'll write soon how to setup a nice development environment, too. ;-) However, if this gives you issues, there is also...

B) The ST-Util way (aka "my python scripts suck" -way) ;-). Flash the "yuneec_typhoon_h.bin" to the MCU, the same way you flashed the bootloader, but this time, starting from 0x8008000. Done. ;-)

Reboot the drone. The drone's power button has a delay of ~8 seconds. During those, the button must be kept pressed. When all lights illuminate, release the power button. The drone is turned off by removing the battery.

Install the QGroundcontrol. Power up the drone. Connect the USB. Load my parameter file using QGC's parameter page. Re-calibrate sensors and radio, probably voltage divider. Verify my settings (Flight modes especially). Go flying. ;-)

Troubleshooting:

-If the drone does not appear as an USB device when the USB is connected AND the drone is powered off: Well, all is lost now. You are having a bootloader flashing issue OR the main autopilot firmware got accidentally flashed to 0x8000000. Re-flash everything and it will be fine. ;-)

-If the drone appears as an USB device but it does not start after a long press of the power button: The main firmware flashing went wrong. Re-flash, starting from 0x8008000

h-elsner · Dec 28, 2019

Thanks for the good description. I have successfully flashed my MCU board (not tested in real flight).

Three remarks:
1. To my picture above: I recommend to secure the small socket connectors with some superglue.
2. The MCU board must be connected with USB to PC in order to keep power supply. Main battery will shut down during deleting boot loader.
3. Start QGroundControl as Adminstrator (at least valid for Win10).

I wonder if it is possible to flash only the MCU board without having it sit on the mainboard. It seems to boot up according the LEDs blink code.

br HE

Pöllö · Dec 28, 2019

h-elsner said:
Thanks for the good description. I have successfully flashed my MCU board (not tested in real flight).
Three remarks:
1. To my picture above: I recommend to secure the small socket connectors with some superglue.
2. The MCU board must be connected with USB to PC in order to keep power supply. Main battery will shut down during deleting boot loader.
3. Start QGroundControl as Adminstrator (at least valid for Win10).

I wonder if it is possible to flash only the MCU board without having it sit on the mainboard. It seems to boot up according the LEDs blink code.

br HE

Hi h-elsner,

That's very nice to hear that the flashing went fine and thank you very much for your remarks! ;-)

1) Securing the small sockets with glue is a very good idea, as there is a risk of ripping the pads off the board. If it happens, it is not the end but things get a little more difficult. ;-)

2) The drone is powered via two power transistors on the ESC board (bottom side), that are controlled by the software. When the MCU is empty, there is nothing to turn these on, although the power button overrides this as long it is pressed down. They are connected to the PA4 pin of the MCU ("PWRLATCH", see diagram on my earlier posts). The bootloader does not "latch" these on (you have to keep that power button pressed) but as the PX4 starts, it turns that pin high and the drone will stay powered on. Alternative for the USB power is keeping the power button pressed down while flashing. ;-)

The LED's have no particular coding at the moment and the main RGB led under the drone stays blue all the time. That's my favourite color... ;-)
However, I'm going to make it change its color like it does with the stock firmware. The MCU board does not necesarily need the mainboard for flashing if you can supply it power some other way (see my pinout diagram earlier ;-).

Pöllö · Dec 28, 2019

Pöllö · Dec 28, 2019

Pöllö · Dec 30, 2019

Oops, it seems that the "typhoon_bind" application is missing from the above build. A new build and updated sources will be released and pushed to the Git as soon as I have test flown it (it's rainy outside for the next few days ;-). Thanks h-elsner for pointing this out! ;-)

h-elsner · Dec 30, 2019

Here is a tested FW upgrade procedure for Ubuntu LINUX PC. Brief description:
- Download binaries
- Find out which TTY port is used. Edit flash_typhoon_bootloader script.
- Make scripts executable.
- Power down MCU board.
- Start flash_typhoon_bootloader script
- Power up MCU board (connect drone via USB cable). Flashing starts soon...

Edit:

FW update is now part of the user manual. See post #120.