I’m trying to make PX4 firmware and add a very simple MAVLINK message. To put it kindly, the tutorial to make expand on the PX4 Firmware is absolutely useless, but I’ll go on about that later. Just read the whole post because there are a lot “kinda works” and “if I do X then Y works but Z breaks” type problems.

I can build on Windows and Linux just fine, add a uORB message just fine, but cannot for the life of me get MAVLINK messages to work.

Now, if I remove the include in the XML, generate files, then move them over, I can build the firmware and it will run and send the message just fine. But the problem is QGroundControl refuses the message and drops it. I brought this up with DonLakeFlyer who mentioned it may be an issue with CRC. Lo and behold, there’s no CRC data for the custom message being included in the program. That’s in v2.0/custom_messages/custom_messages.h. That doesn’t get included because if you include v2.0/custom_messages/mavlink.h, nothing ever gets included because MAVLINK_H is already defined and everything in the file is skipped. So I have to include the message file directly to get things like the message ID, which obviously leaves out important data like CRC data. It’s a circular situation where you can’t include all the data.

There might be a fix for this as is, but it would include manual splicing of files, which I have not been successful with and is not something that a user should have to do anyway.

There is so much not working here it’s ridiculous. There is zero help in the tutorial or online I can find after over 100 hours of working this. The fact that following the steps of the tutorial causes even more issues than fucking around and trying random other things is a problem. This is all I have to go off of and no amount of tweaking, file splicing, comparing to other questions online, etc. gets me any closer.

Hi, I had the same problem. The right way is modify mavlink messages in your fork of mavlink library. This library is built automatically and deployed to c_library_v2. Also make your own fork. And set up deployment there. This will ensure, that all files will be created rightly.

Then you can change submodule URL of PX4Firmware/mavlink/include/mavlink/v2.0/ pointing to your fork. And then try it again.

And a note, you must set publishing of your message also in this file with maximal rate limit.github.com

What does using a fork do versus just a cloned version of MAVLINK? I’ve tried modifying MAVLINK separately and with the downloaded submodule with the same results. Ultimately a fork is absolutely not an option for a few reasons, so it’s obviously important I do it without a public fork.

Sorry I’m not really sure about that. I infer from how mavlink protocol works (and looks). QGC must know your message definition to decode. Because mavlink message (transmitted data) does not include message structures.

How do I properly add my custom firmware to QGC? I’ve added the custom_messages directory to the CMakeLists.txt in the root directory and think I found a place to add custom_messages.h, but I’m not sure it’s right.

Did you just straight up follow the tutorial listed above? Because at this point it leaves out so much info that I’m just beyond confused. They explain nothing, assume so much, and just… it’s ridiculous. Nothing here makes sense at all.

The reason your xml has crc issues is because of a known bug (https://github.com/ArduPilot/pymavlink/pull/339 is a fix) - basically if you have more than one level of include, things don’t currently work properly. You’re triggering this because you include ardupilotmega which itself has includes.

The root cause of this problem is as auturgy indicates above ^^^. The docs don’t mention this because they assume you’re creating a dialect off common.xml, and also I’d hoped this bugfix would be merged by now.

MAVLink creates a CRC at generation time for every message based on the field types, names and order (some docs on this here). This means that for a new message you will need to have the same library on both ends of the communication.

I have a ton of notes and private documentation I’ve written up for QGC and PX4. This stuff is my job, part of which is document my custom work and filling the gaps of the public documentation. Much of this I’m sure I’ll add in a pull request when I feel like I have a solid grasp and I’m not spitting out incorrect information.

The way around it at the moment, if you need the ardupilot messages, would be to use Ardupilotmega as the top level xml, with your dialect added to it as an include (multiple includes isn’t the problem, nested includes is), and rebuild from that.
Not ideal, but will get you moving.