Issues adding custom Mavlink message to QGroundControl and px4

I am trying to add a custom Mavlink message to a custom QGC build and have the message display on a simple widget. It’s a pretty basic message consisting of 3 float values. We created a uORB message to populate the Mavlink message, we added a fact group for the sensor for QGC, and went through this guide, and our uORB is publishing as expected. We elected to give the message an ID of 344 (unallocated prior to our usage) and made sure that the mavlink version used in all devices is version 2. The only changes we made outside of the guide was to add the ‘configure_stream_local’ function for the new topic in the ‘Mavlink::configure_streams_to_default’ in ‘mavlink_main.cpp.’ Also, I did not enable the stream within “ /ROMFS/px4fmu_common/init.d-posix/rcS” as outlined in the guide as this is only for SITL, not for NUTTX and HITL which is the target usage we desire.
The problem is that we do not see the Mavlink message being published anywhere. Our custom Mavlink c2_library was added accordingly to QGC and it builds fine. On the flight controller (PX4 on fmuv_3 arch), the Mavlink stream is set up and listed as active in both instance 0 and 1 (shown in image below: custom message is fuel_status)

, but I checked to see if any Mavlink messages with the same id as the custom message are being received in QGC but no messages with our ID are located (made a custom factgroup and parse for the custom message: this could very well be our issue, but other factgroup and facts did no see our message. I have noticed a small amount of packet loss listed in QGC, which I know isn’t abnormal, but when I take out the Mavlink stream for the added Mavlink message, the packet loss is zero. Any help on setting this up correctly? It seems like the guide listed only gets you so far. On the whole we are trying to located if our issue is on the QGC or autopilot side. Any help would be greatly appreciated!

1 Like

That is most likely because your new message is in the stream Vehicle->QGC but the mavlink parser is not parsing because there is something wrong with how you created the new mavlink headers or how you added them to QGC.

So then this is likely a QGC issue? The px4 side was quite easy to follow and due to the stream being labelled as ACTIVE leads me to believe it is being published ok. Since the same custom c2_mavlink_v2 library was used in both builds (autopilot and QGC), I’m not sure how there can be an issue with the header format. It is possible that they werent added to the QGC build properly but the header file shows up fine (macro definitions show up where included etcetc) and the fields of common.h that needed to be changed for the new addition I assume were correct as the autopilot side seemingly works.
Is it reasonable to assume that this is purely a QGC build issue since we have legitimate packet loss with our message enabled and the stream status is listed as ACTIVE?

It is an issue with your specific build of QGC not with QGC in general. You likely have something set up incorrectly somewhere. The ability to build your own version of QGC with a new version of mavlink which includes additional messages has been proven to work fine many times. If I had to guess either:

  • You have not updated all of the headers in the mavlink directory only some of them. You need to copy the whole thing over
  • You maybe added something outside of common.xml. If that is the case keep in mind that QGC uses the ArduPIlot dialect of mavlink which is a common superset
  • You built the mavlink headers wrong but that seems less likely since you get firmware side to compile

To figure it out you will need to debug the mavlink stream from the QGC side to figure out what is going wrong. You can hack the parser in QGC to look at the stream to see if it is getting the message id at all.