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

[h-elsner]

Sorry, The link in documentation is too old. The latest FW and default parameter file is here: Thunderbird/Thunderbird_170521_FT_LATEST.zip at Typhoon_H_480 · tonirosendahl/Thunderbird
To download use the button:


br HE

 

[Niels]

Hello guys i'm thinking to switch to thunderbird. I've read the docs but I still have one question. Why is the sonar not supported and what about the realsense. Is it hard to add it to the firmware? Does px4 not support it natively?

 

[h-elsner]

Thunderbird FW was a one-man show of Pöllö from Finland. He did the necessary parts of the FW to get it fly, no more. Now he is doing other things and disappeared from this forum.
Unfortunately no other developer of the community is interested in to continue the project. PX4 supports a lot of sensors, RealSense. LIDAR and so on, but it needs developer. Typhoon H is a niche product with little recognition in the PX4 community and is also relatively old. It is near the Intel Aero which was abandoned by Intel a long time ago.

I do not expect that we get something more as we have today. I found some problems in FW "Thunderbird_170521_CD". I think it is better to use still "Thunderbird_030420_CD".

br HE

 

[1midniterider]

Thunderbird FW was a one-man show of Pöllö from Finland. He did the necessary parts of the FW to get it fly, no more. Now he is doing other things and disappeared from this forum.
Unfortunately no other developer of the community is interested in to continue the project. PX4 supports a lot of sensors, RealSense. LIDAR and so on, but it needs developer. Typhoon H is a niche product with little recognition in the PX4 community and is also relatively old. It is near the Intel Aero which was abandoned by Intel a long time ago.

I do not expect that we get something more as we have today. I found some problems in FW "Thunderbird_170521_CD". I think it is better to use still "Thunderbird_030420_CD".

br HE

Could this firmware be installed on the PixHawk 2.4.8 or the PixHawk 6C?

 

[h-elsner]

This FW is made especially for the Typhoon H hardware. You can install it on another flight controller but this will not work.

 

[1midniterider]

In the flash documentation, it states there are two methods of connecting the FC to the firmware flash board. Is one method preferred over the other? It would seem that using the detachable cable would be preferred...

 

[h-elsner]

Which method you use depends on:
- your soldering experience
- how often you want to reflash the boot loader (standard case is to do it once -> method 1)
- avalibility of the connectors (method 2)
You can also think about using pogo pins if you plan a "mass production" of new-flashed mcu boards. See #207.

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

A new version of the User manual is available now for review: https://github.com/h-elsner/Thunderbird/tree/Typhoon_H_480/Documentation Major updates done in chapter "Flying". br HE

yuneecpilots.com

 

[1midniterider]

It would appear my board is slightly different than the ones depicted in the firmware flashing document. Instead of pin holes for the test points, mine has actual pads.

 

[h-elsner]

All MCU boards have only pads. It's up to you how to connect those five wires to the SWD port at the ST-Link (soldering wires or tiny socket connectors). I have used three possibilities:
- wires direct to the pads: fast and easy, but it is dangerous if you want to do it twice or more...
- pin holes broken out from a connector row: this can be used very often if you are careful - use case for intensive testing, that was the MCU board I have used for the pictures (may be misleading but show one of the possibilities)
- if you have soldering skills and the tiny connector at hand, the the connector can be used do flash bootloader as often as you want.

Alternative and most professional would be an adapter with pogo pins. But this is only needed when you plan to flash a lot of boards.

The normal use case is one-time-fashing. For this I prefer now to solder thin wires direct to the pads.

 

[1midniterider]

Those are awful small pads... My soldering skills are bit lacking... Guess I need to find another way...

 

[h-elsner]

In this case I would go to pogo-pins. Some suppliers offer single pieces, but most in 100 pieces packages. No need to have a 3D printer. I would take a piece of wood and provisional part with the 4 pins (ground is easy to find. (Wood is a under-rated material)

 

[filelan]

-- Reposting here regarding my plan to help on this custom firmware dev. Posted in the other thread, but I am thinking this is actually the correct location --

Ok, I decided I am in to help. I can't promise how much time I can commit but will help as much as I can as possible (with family, work, and other commitments). I am building the custom drone and can focus on opening up the controller as much as possible. There might be a possibility to just swap in a new radio or do a combo of a rewrite for the app for the controller + add another module for the radio to make it open. Since the original module in there after I did the tear down is just a Zigbee with a simple serial connection. Opening it up should not be too big of a deal. I can also take a look at the custom firmware for the actual drone. But, I do not have a Yuncee drone. I may be able to port part of the code and check it on my own hardware I am building and contribute back to that part of the project that way. My handle on Github is FileLAN.com and I just starred your project and followed. Soon as I can make some progress I will post up a pull request. Is there a specific area where the development got stuck at if you have been following. Or where the other developer that left, stopped working on X feature? Look forward to working on this should be interesting.

 

[Vaklin]

I asked before but the question looked stupid or the answer was so simple, so I didn't get any advice.

Let someone explain step-by-step how to compile and implement the whole project. I have some ideas, which I probably can implement but the first is to compile the present source.

 

[h-elsner]

My status regarding PX4 Autopilot for Typhoon H flight controller (Thunderbird FW):

* Compile FW from source: No success - problems with tool chain. Script to setup the tool chain runs with errors (hick-up with Python versions 2/3) but after this all environment variables for compiler are missing.
he@XEON:~/git/Thunderbird$ ./build_px4_typhoon.sh
-- PX4 version: v1.10.0-rc1-138-gdfa55a08f8
-- PX4 config file: /home/he/git/Thunderbird/boards/yuneec/typhoon_h/default.cmake
-- PX4 config: yuneec_typhoon_h_default
-- PX4 platform: nuttx
-- PX4 lockstep: disabled
-- cmake build type: MinSizeRel
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- The ASM compiler identification is unknown
-- Found assembler: arm-none-eabi-gcc

* Understand source: I don't like C/C++, hard to read but doable - have to learn. Some concepts are nor clear for me (i.e. initiate serial connections).

Changes made in RCInput.cpp
* Typo corrected for flight modes in telemetry (Stability as flight mode 0 instead 1)
* Untested try to replace absolute altitude to relative altitude in telemetry (altitude like Typhoon H on ST16, absolute altitude not very helpful during flight).

New feature that I would like to have except both above:
* Add a new instance for MAVlink that shall be routed to a serial connection, best would be the RealSense UART. HW: RealSense is connected to PA0 and PA1 on STM32.
Currently we have only one instance routed to ttyAMA0 (USB).
instance #0:
GCS heartbeat: 835008 us ago
mavlink chan: #0
type: USB CDC
flow control: OFF
rates:
tx: 14.106 kB/s
txerr: 0.000 kB/s
tx rate mult: 1.000
tx rate max: 800000 B/s
rx: 0.038 kB/s
FTP enabled: YES, TX enabled: YES
mode: Config
MAVLink version: 1
transport protocol: serial (/dev/ttyACM0 @2000000)

* UART support for gimbal control (tilt, rotate). This will need a lot of research/high effort.

 

[Vaklin]

* UART support for gimbal control (tilt, rotate). This will need a lot of research/high effort.

MAGIC = {0x05, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0xC8, 0x00, 0x7F, 0x00, 0x01};

#define UART_BAUD_RATE 115200

Send the MAGIC to the copter's camera UART every second. Log what the copter sends to you. Without a camera attached. Paste here what you have received. If this is done I'll paste some text too.

 

[Vaklin]

To don't waste time about the CRC>

#include <stdint.h>
#include <stddef.h>

uint16_t crc16_mcrf4xx(uint16_t crc, uint8_t *data, size_t len)
{
uint8_t t;
uint8_t L;
if (!data || len < 0)
return crc;

while (len--)
{
crc ^= *data++;
L = crc ^ (crc << 4);
t = (L << 3) | (L >> 5);
L ^= (t & 0x07);
t = (t & 0xF8) ^ (((t << 1) | (t >> 7)) & 0x0F) ^ (uint8_t)(crc >> 8);
crc = (L << 8) | t;
}
return crc;
}

 

[Vaklin]

and a bit more...
uint16_t crc16_mcrf4xx(uint16_t crc, uint8_t *data, size_t len);

struct Mavlink_V1 //https://mavlink.io/en/guide/serialization.html#v1_packet_format
{
uint8_t magic;
// ---
uint8_t len;
uint8_t seq;
uint8_t sysid;
uint8_t compid;
uint8_t msgid;
uint8_t msgTypeH;
uint8_t msgTypeL;
// uint8_t payload[255];
uint16_t checksum; // -
uint8_t crcLow; // |
uint8_t crcHigh; // -
};

uint16_t initCRC = 0xFFFF, calcCRC = 0x0000;
uint8_t magic[] = {0xFE};
uint8_t zero[] = {0x00};
uint8_t crc[] = {0x00, 0x00};

int count;

int receivePacket(uint8_t *read_buffer)
{
struct Mavlink_V1 mavlink;

int
position = 0x00,
receivedBytes = 0x00,
count = 0x00;

do
{
if (uart_gets(&mavlink.magic, 1) == 0)
{
return count;
}
}
while (mavlink.magic != 0xFE);

while (uart_gets(&mavlink.len, 1) == 0);
read_buffer[position++] = mavlink.len;

while (uart_gets(&mavlink.seq, 1) == 0);
read_buffer[position++] = mavlink.seq;

while (uart_gets(&mavlink.sysid, 1) == 0);
read_buffer[position++] = mavlink.sysid;

while (uart_gets(&mavlink.compid, 1) == 0);
read_buffer[position++] = mavlink.compid;

while (uart_gets(&mavlink.msgid, 1) == 0);
read_buffer[position++] = mavlink.msgid;

while (uart_gets(&mavlink.msgTypeH, 1) == 0);
read_buffer[position++] = mavlink.msgTypeH;

while (uart_gets(&mavlink.msgTypeL, 1) == 0);
read_buffer[position++] = mavlink.msgTypeL;

do
{
receivedBytes += uart_gets(&read_buffer[position + receivedBytes], mavlink.len - receivedBytes);
}
while (mavlink.len != receivedBytes);

while (uart_gets(&mavlink.crcLow, 1) == 0);

while (uart_gets(&mavlink.crcHigh, 1) == 0);

count = position + receivedBytes;


calcCRC = (uint16_t) crc16_mcrf4xx(initCRC, read_buffer, count + 1);

 

[Vaklin]

MAGIC = {0x05, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0xC8, 0x00, 0x7F, 0x00, 0x01};

#define UART_BAUD_RATE 115200

Send the MAGIC to the copter's camera UART every second. Log what the copter sends to you. Without a camera attached. Paste here what you have received. If this is done I'll paste some text too.

Forgot to remember you should not forget to pack the telegram properly.

int sendPacket(uint8_t* send_buffer, int send_buffer_size)
{
...
{
calcCRC = (uint16_t) crc16_mcrf4xx(initCRC, send_buffer, send_buffer_size);
calcCRC = (uint16_t) crc16_mcrf4xx(calcCRC, zero, sizeof(zero));
crc[0] = calcCRC & 0xFF;
crc[1] = (calcCRC >> 8) & 0xFF;

uart_puts_raw(magic, sizeof(magic));
uart_puts_raw(send_buffer, send_buffer_size);
uart_puts_raw(crc, sizeof(crc));
}
...

 

[Vaklin]

* Compile FW from source: No success

Is there a way to ask the owner of the project for one-time support?

 

[DoomMeister]

I have been working out logic diagams and some other docs to release in the near future specifically for the controller modding. Would it make sense to start a new thread separate for the controller subject to separate from the autopilot firmware side? I will start a github repo as well for modding the controller soon as I get some more work time on it.

That would be a good idea so we can keep the two things separate and avoid confusion.

I will try to place all recent controller related posts from this thread in a new one this weekend.