New MAVLink message implementation to QGroundControl

[Nurgak]

Quick word on my goal: I'm implementing an "advanced fail safe messaging system" that has the goal of putting the user in the control loop. If something goes wrong (GPS loss, low battery...) the areal vehicle will propose solutions to the user (return to launch, fire parachute, switch to manual control...), the ground station will prompt a window where the user can click on a solution within a time window, otherwise the UAV will take a default action.

---

I'm having a hard time implementing a new MAVLink message in QGroundControl. I successfully updated the MAVLink headers and ArduPilot firmware with everything needed to send my new message to the ground station, but I don't understand how to continue from now on. QGroundControl code seems a bit convoluted and I can't find that part that handles the messages.

Right now I'd like to know if my message is actually received by QGroundControl, currently I use MAVProxy/SITL to simulate the areal vehicle. I don't see my custom message in the MAVProxy console, I assume that is because MAVProxy does not know how to handle the custom message as I have not implemented it there. I'm interested in implementing it in QGroundControl, so I thought I'd skip this step, I hope unhandled messages in MAVProxy are simply ignored and sent to the ground control anyway... am I right to assume that?

On the QGroundControl side I can't see the passed custom message, I've copied my custom headers to qgroundcontrol\libs\mavlink\include\mavlink\v1.0 and changed the _MAVLINKCONF definition in QGCExternalLibs.pri to reflect the custom messages (which is based on ardupilotmega). What I'd like, for starters, is to see in the QT console if there's an unhandled message, just as a debug to confirm that me message is actually passed through.

I'm also wondering if the tutorial on implementing new messages on QGroundControl is up to date...

[DonLakeFlyer]

I doubt tutorial is up to date. You can see if your message is getting through using the mavlink inspector widget. But only if you have set up new headers correctly. Data stream goes from SerialLink to MavlinkProtocol to Vehicle. Implement new measage handling in Vehicle

On Feb 2, 2016, at 5:12 AM, Karl Kangur notifications@github.com wrote:

Quick word on my goal: I'm implementing an "advanced fail safe messaging system" that has the goal of putting the user in the control loop If something goes wrong (GPS loss, low battery) the areal vehicle will propose solutions to the user, the ground station will prompt a window where the user can click on a solution within a time window, otherwise the UAV will take a default action

I'm having a hard time implementing a new MAVLink message in QGroundControl I successfully updated the MAVLink headers and ArduPilot firmware with everything needed to send my new message to the ground station, but I don't understand how to continue from now on QGroundControl code seems a bit convoluted and I can't find that part that handles the messages

Right now I'd like to know if my message is actually received by QGroundControl, currently I use MAVProxy/SITL to simulate the areal vehicle I don't see my custom message in the MAVProxy console, I assume that is because MAVProxy does not know how to handle the custom message as I have not implemented it there I'm interested in implementing it in QGroundControl, so I thought I'd skip this step, I hope unhandled messages in MAVProxy are simply ignored and sent to the ground control anyway am I right to assume that?

On the QGroundControl side I can't see the passed custom message, I've copied my custom headers to qgroundcontrol\libs\mavlink\include\mavlink\v10 and changed the MAVLINK_CONF definition in QGCExternalLibspri to reflect the custom messages (which is based on ardupilotmega) What I'd like, for starters, is to see in the QT console if there's an unhandled message, just as a debug to confirm that me message is actually passed through

I'm also wondering if the tutorial on implementing new messages on QGroundControl is up to date

— Reply to this email directly or view it on GitHub.

[Nurgak]

Thanks for the feedback. I made sure that the new headers were correctly set up. I used the same headers on the UAV and QGC, but I can't see the custom message being passed.

For the sending I essentially coped the GCS_MAVLINK::send_statustext_all function, with some additional arguments of my own:

void GCS_MAVLINK::send_afs_message(MAV_SEVERITY severity, uint8_t timeout, AFS_SOLUTIONS *solutions, const prog_char_t *str, ...)
{
    for (uint8_t i=0; i<MAVLINK_COMM_NUM_BUFFERS; i++) {
        if ((1U<<i) & mavlink_active) {
            mavlink_channel_t chan = (mavlink_channel_t)(MAVLINK_COMM_0+i);
            if (comm_get_txspace(chan) >= MAVLINK_NUM_NON_PAYLOAD_BYTES + MAVLINK_MSG_ID_STATUSTEXT_LEN) {
                char msg2[50];
                va_list arg_list;
                va_start(arg_list, str);
                hal.util->vsnprintf_P((char *)msg2, sizeof(msg2), str, arg_list);
                va_end(arg_list);
                mavlink_msg_afs_message_send(chan,
                                             1, // ID that must be included with reply
                                             severity,
                                             timeout,
                                             msg2,
                                             (const uint8_t*)solutions);
            }
        }
    }
}

For the receiving part I edited Vehicle.cc and added a case in Vehicle::_mavlinkMessageReceived:

case MAVLINK_MSG_ID_AFS_MESSAGE:
    qDebug("AFS message receievd");
    break;

So far no dice, I can't even see the message in the MAVLink inspector widget...

Do you have any other advice?

[DonLakeFlyer]

I'm closing this since Issues are for QGC bugs. But we can continue the discussion.

First thing I would test is change your code above to send a normal mavlink mesage text message. Then see if that message gets to QGC by dropping down the message icon in the toolbar. That way you can verify that you firmware code is at least being called and attempting to send a message.

[Nurgak]

This is what I've been trying:

void GCS_MAVLINK::send_afs_message(MAV_SEVERITY severity, uint8_t timeout, AFS_SOLUTIONS *solutions, const prog_char_t *str, ...)
{
    for (uint8_t i=0; i<MAVLINK_COMM_NUM_BUFFERS; i++) {
        if ((1U<<i) & mavlink_active) {
            mavlink_channel_t chan = (mavlink_channel_t)(MAVLINK_COMM_0+i);
            if (comm_get_txspace(chan) >= MAVLINK_NUM_NON_PAYLOAD_BYTES + MAVLINK_MSG_ID_STATUSTEXT_LEN) {
                char msg2[50];
                va_list arg_list;
                va_start(arg_list, str);
                hal.util->vsnprintf_P((char *)msg2, sizeof(msg2), str, arg_list);
                va_end(arg_list);
                GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, PSTR("Sending AFS message..."));
                mavlink_msg_afs_message_send(chan,
                                             1, // ID that must be included with reply
                                             severity,
                                             timeout,
                                             msg2,
                                             (const uint8_t*)solutions);
                GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, PSTR("AFS message sent"));
            }
        }
    }
}

I assigned my message the ID 198.

[MainReturnZero]

@Nurgak Hi, have you solved the problem? I have the same problem as yours. I add a custom message to the ardupilot and couldn't receive it on the GCS side. Thanks in advance.

[Nurgak]

@LittleBun I thought MAVProxy just acted as a proxy (because of its name) and as a special functionality allowed to inject some MAVLink messages. It turns out it's not just a proxy, it will interpret all messages and will discard the ones it cannot process. I needed to pass a custom message from customised ArduPilot code to customised QGroundControl and this non-customised MAVProxy kept eating my messages as it did not understand them. In the end I dropped MAVProxy and directly tested the code on the plane.

[visrinivasan]

I added my custom message on common.xml, created the required headers using pymavgenerate.py and rebuilt the qgroundcontrol source code. I have been successful to listen to my custom mavlink message from nsh shell but can't see the new message on Mavlink inspector.

What else apart from the common.xml changes is required to visualize the MAVLink message on MAVLink inspector?

I am relatively new to mavlink. Is there a step-by-step tutorial to obtain one?

Thanks

[DonLakeFlyer]

If you can't see them new message in mavlink inspector. Then either:

• QGC isn't compiled with the correct new headers
• The message never makes it to QGC

[visrinivasan]

Thank @DonLakeFlyer , am I expected to receive the custom mavlink message on Mavlink inspector with just adding the new message on custom.xml file in the qground control source code? My build passed on Qt creator. Pymavgenerate.py produced the header file in qgroundcontrol/libs/mavlink/include/mavlink/v2.0/common folder.

Am I missing something/required to add the header file anywhere to view it on Mavlink inspector?

Thanks.

[eMrazSVK]

@visrinivasan Yes. You actually need to send the packet. Look to vehicle code, for example ArduCopter, open GCS_Mavlink.cpp and look for MSG_HEARTBEAT (part of the code where there i a switch(id)) and find out what is need to be done to send heartbeat. Then follow this process to achieve the same (instead of heartbeat, send your own packet)

[arun2204]

mavlink_msg_custom_heartbeat.txt

Hi All, I am facing the same issue, created a custom message by modifying common.xml, generated headers using mavgenerate.py tool, did this on both PX4 side and QGC side of mavlink submodule. Now using some debug statement I can see QGC is recieving custom message(printing it's id which is 199), but unable to decode(decodeState remain 0 and error is : MAVLINK_FRAMING_BAD_CRC) Can't even see message in mavlink inspector. Following is sample code of my custom mavlink header :

define MAVLINK_MSG_ID_CUSTOM_HEARTBEAT 199

MAVPACKED( typedef struct __mavlink_custom_heartbeat_t { uint32_t custom_mode; /< Navigation mode bitfield, see MAV_AUTOPILOT_CUSTOM_MODE ENUM for some examples. This field is autopilot-specific./ uint8_t type; /< Type of the MAV (quadrotor, helicopter, etc., up to 15 types, defined in MAV_TYPE ENUM)/ uint8_t autopilot; /< Autopilot type / class. defined in MAV_CLASS ENUM/ uint8_t base_mode; /< System mode bitfield, see MAV_MODE_FLAGS ENUM in mavlink/include/mavlink_types.h/ uint8_t system_status; /< System status flag, see MAV_STATUS ENUM/ uint8_t mavlink_version; /< MAVLink version/ }) mavlink_custom_heartbeat_t;

define MAVLINK_MSG_ID_CUSTOM_HEARTBEAT_LEN 9

define MAVLINK_MSG_ID_CUSTOM_HEARTBEAT_MIN_LEN 9

define MAVLINK_MSG_ID_199_LEN 9

define MAVLINK_MSG_ID_199_MIN_LEN 9

define MAVLINK_MSG_ID_CUSTOM_HEARTBEAT_CRC 226

define MAVLINK_MSG_ID_199_CRC 226

Any help?

[DonLakeFlyer]

This isn't really the place to ask questions on how to build new mavlink variants. Thats more of a firmware thing. So you may not get good answers here.

[MaduT]

I tried to send MAVlink version 2 heartbeat message to QGC as follows:

According to the log I can see QGC send version 1 packet and the "Only accept MAVs with same protocol version" checkbox is not selected in "MAVLink" tab. Under these condition, I try to view my heartbeat message by using MAVLink Inspector. But I do not see content in heartbeat message. One odd thing I observe is I change comm setting in QGC. It seems it does not applied to it. As an example, I changed baud rate from 57600 to 115200 but my simulator (it expect baurate 57600) decodes message without any issue. Then, I try to disconnect it by clicking the disconnect button but it seems it does not disconnected since my simulator receives message. Will it be a bug in QGC released version 3.3.0? Then, I tried QGC version 3.2.4 and 3.2.7. Same behavior... Bit odd :(

I wonder will it be a bug in QGC in those version or something relevant to to my PC. Due to this there is no way for me to make sure that my heartbeat message is right or wrong? Any thought to figure out this? Will any of you be able to send one of my above heartbeat message to your GQC and make sure that is working? You may also be have to change the QGC id as well...

At one point QGC pop up a message as "There is a MAVLink Version or Baud Rate Mismatch. Please check if the baud rates of QGroundControl and your autopilot are the same." Then, I send version 1 packet and changed the baud rate to match to the simulator sending rate it. But no data in MAVLink Inspector.

Any thought?

Thanks, Madu

[DonLakeFlyer]

Automatic switching of QGC output to mavlink 2 based on input of a mavlink 2 message has been working fine for quite a while now (possibly over a year). Highly doubtful there is a QGC problem here.

[MaduT]

@DonLakeFlyer: I have not enabled MAVLINK_CRC_EXTRA to add the CRC_EXTRA byte at the end. This cause the problem. Thanks for your comment and time ....

[GaoGeolone]

@DonLakeFlyer: I have not enabled MAVLINK_CRC_EXTRA to add the CRC_EXTRA byte at the end. This cause the problem. Thanks for your comment and time ....

Could you please explain how you made this~? I define a new msg in common and generate header files , and I use an board to publish topic by /mavlink/from ,but my QGC did not display even in Analyze

[Ador2]

I'm facing the same issue now, sending a custom message doesn't appear in mavlink inspector, what do you mean by enabling MAVLINK_CRC_EXTRA

[hamishwillee]

@Ador2 The MAVLINK_CRC_EXTRA is a mavlink library #define that you should not have to set - if you're using MAVLink 2 this is set for you.

In general do not necrobump very old issues that may not apply. Ask new questions on the QGC discussion boards or raise new ones here with lots of detail on what you are doing.

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-june-14-2023/32616/3