Support for MavLink Telemetry and PixHawk based Flight Controllers

[careyer]

Hi there,

could you include support for MavLink based Flight Controllers as well (e.g. Pixhawk, PixRacer aso...)? It is a highly standardized protocol also much used in robotics. That would be gorgeous! Thanks in advance and keep up the excellent work!

Cheers!
Thomas

[seeul8er]

MavLink telemetry will be supported in the android app and the telemetry module in the near future.

I was about to add some things to the control module to make it confirm waypoint uploads etc. That will open the door for MavLink as well.
At the moment it is just a serial pass through and does not care about the protocol. Nor does it confirm anything.

I will consider MavLink when designing and implementing missions.

[fingadar]

I agree, supporting Mavlink would be very good. I'm using INav and Pixhawks as well.

But congratulations to your project!

Bg, Stefan

[careyer]

@seeul8er : Also gratulations to the very professional looking projekt from my side and for supporting MavLink in the near future! That will be a huge Plus! Keep up the excellent work!!!! It's always good to see that people are tinkering themselfs rather than getting ripped off by DJI and competitors.

[fingadar]

Short question: "tx" in Dronebridge means ground side, "rx" means rover (air) side?

It's a little bit irritating, since in original EZ-Wifibroadcast, "tx" is (mainly) the rover side and rx the ground side.

[seeul8er]

@careyer Thank you! Really appreciate it! Gotta make it look killer so people take a closer look 😄

@fingadar Yes. For everything concerning DroneBridge: TX is ground. I know that WifiBroadcast does it the other way around and as video transmission goes from drone to groundstation it makes sense. When I first looked into WifiBroadcast that confused me the most as TX usually is RC. As DroneBridge is more than just video I decided to go with that.
If more people complain I might change things back.

Thanks for your interest! Happy to help.

[careyer]

Hi there,

Since at some point in time WiFi broadcast became a bidirectional solution it is also a good practice to talk about "AirPi" and "GroundPi". No more confusions this way ;-)

[geofrancis]

Did you make any more progress on Mavlink?

[seeul8er]

Yes! Mavlink telemetry is supported by the Android app and the telemetry module. The control module still has some issues with Mavlink but I started working on it again today! This means you can only get Mavlink telemetry for now.
I will release a new version of the app and DroneBridge at the beginning of next week no matter what. SUMD-RC output is untested and Mavlink uplink as well.
But I think its about time to release a new version.

[seeul8er]

MavLink telemetry is now supported via telemetry module, control module, android app and WBC OSD

release during the next days

[geofrancis]

how are you sending your mavlink telemetry? are you using the mavlink libraries or is it just a pipe, ez-wifibroadcast has issues currently since the standard mavlink libraries are not fully compatible with ardupilot due to a crc check that causes it to drop a lot of packets.

[seeul8er]

Telemetry module: Simple pass through. Chunks of 128 bytes per packet are passed through.
Control module: Parsing of MAVLink stream to separate telemetry from rest of the messages. Latest version of the mavlink libraries is used.

I am not sure if I tested the telemetry module with MAVLink in the last few weeks, but it worked back in the days when I implemented it. The telemetry module provides no MAVLink uplink to the drone. The config described in "Setup guide" uses the control module to read telemetry.

Let me know what worked for you.

[geofrancis]

Have you got uplink working?

[seeul8er]

Uplink should work. I will setup the MAVLink SITL to verify it.

[careyer]

That is great news! I'll have to give it a try!

[seeul8er]

Did some SITL testing yesterday. Uplink works but has too much packet loss. Also I needed to modify the code a bit to get it working with QGroundcontrol.
I keep you posted. For now I'd say you wait a little till I figured out whats wrong. Should do more testing in the future 😄

[geofrancis]

have you been following the ezwifibroadcast thread on rcgroups, the standard mavlink libraries dont work properly with ardupilot only px4. ardupilot has some checksum that is not implemented in the regular mavlink libraries.

[seeul8er]

yep. read about that some time ago. Thanks for posting!

The problem I am trying to fix with the uplink appears with both (MAVLink and MSP) stream. Spent half the day testing. With the nightly branch the uplink works just fine, but only when I stop transmitting the video. With WBC-Video running I can barely get packets through. Strangely the DroneBridge RC uplink is not (or only insignificantly) affected by any of it. So the long range throughput seems to be OK.
The moment I turn on video downstream & RC-uplink, the MSP/MAVLink uplink almost stops completely. I use 60% channel utilization and get barely lost packets/bad blocks.
Tested everything while being connected via Wifi to the groundstation. But that should not affect it much as uplink barely improves when i turn off forwarding of the video stream to UDP/Wifi, so there should be enough capacity.
Right now I have a hard time finding the weak link as everything seems to make no sense. I hope I can find my old switch within the next days. Then I'll connect via ethernet. That way wifi problems can be ruled out.
Maybe it is just a bad power supply. I am testing it with my 2A & 3A chargers that never caused problems till now. Maybe I'll should hook it up to my 3A BEC for my drone.

Just a little status update. I'll keep you posted.

[geofrancis]

i think this is why rodzio moved to parsing the mavlink packets, the problem is the px4 library is not fully compatible so his uplink is not transmitting specific packets due to crc problem.

the libray that it needs is here : https://github.com/ArduPilot/mavlink

if you can just replace rodzios mavlink libaries in 1.6 with these you will fix all of it.

[seeul8er]

The problem was not the parsing but the lossy link and throughput. I think I got it figured out.
Uplink is working just fine. I think the problem lies with the programs used with the link. Mwptools (iNAV) seems to have a one-second timeout. That causes the interruptions in the stream even if only one packet is lost. I think that that is the case with Qgroundcontrol as well when I tested it. UDP does not guarantee delivery and so does DroneBridge. That's why I used it instead of TCP. The sender/end-point needs to control the flow/requests/timeouts.

I'll craft a new release with all the changes within the next days so you guys can test it out if you want.

[careyer]

@seeul8er : Thank you very much for the update. Indeed EZ-WifiBroadcast also suffers from this phenomenon (unreliable MavLink Up-& Downlink). Looking forward to your solution. If you find a solution it would be best practice to share knowledge with the WifiBoadcast project.

Cheers!

[geofrancis]

I am currently using transparent mode on v1.5 and get about 99% of packets through using changes from here: rodizio1/EZ-WifiBroadcast#31

[leonmelson]

Hi I have been using EZ Wifibroadcast on my setup for a while and it works good for Video and ok for Mavlink.

I use a APM 2.6 with a Pi zero for the airDrone

For the UART coms I use a voltage divider from the APM TX 5V to the PI Zero RX 3.3V and directly connect PI Zero TX 3.3v to APM RX 5V. This works fine for me until I receive my Voltage logic converter.

I use a Pi 3 model B v1.2 on the GroundStation.

I setup DroneBridge 0.5 cause I like the way this project is going and do not like having to remove the sd cards to change settings.

At first I could not get it to work and found that on wifi or lan I could only get video not telemetry or app control.

But if I use usb tethering it works 100%.
I switched Tower and Qgroundcontrol to use port 1604 for telemetry.
and changed the DB android app port to 1605.

I have not done any flights yet but will be soon.

I also just want to say thank you Wolfgang for the awesome work.

Maybe in the future you can add special funding futures like maybe OPENCV ROI follow. Have people fund your time to create it then you can keep the app free or you can create stuff like this and have people pay for the app that will be up to you.