MAVLink message from SITL to MP - Seqno Error

Ground Control Software Mission Planner
, ,
1

Hello guys.

I have created a new message in ArduPilot (running SITL inside a virtual Linux machine) and in Mission Planner.

<message id="202" name="ROI_INTERRUPTION_DATA">
  <description>Data related to interruption due to ROI scanning</description>
  <field name="status" type="uint8_t">status (1 - interruption detected)</field>
</message>

The headers have been created in both ends, everything is okay in ths part.
The problem is that all messages that I send from ArduPilot to Mission Planner are being lost because of its sequence number. How can I fix this?

2

the only reason the seq number could be wrong is you are not using the built in library’s to send the message correctly. otherwise the seq number would be automatically set on send.

3

Hello, Michael. Thanks for your reply, I’m really glad you took a little time to look at my issue. Let me try to give a few more details. It got a little big, because I tried to give as much detail as I could. If you need anymore details, I’ll be happy to present.

In ArduPilot (running as SITL in a Ubuntu virtual machine), I created the message (as mentioned before) in ardupilotmega.xml. The exact same code is in the same file in Mission Planner’s MAVLink.

After compiling ArduPilot, the headers have been created succesfully in ardupilot/build/sitl/libraries/GCS_Mavlink/include/mavlink. Inside ArduPilot code, I call the generated method as follows:

  • In libraries/GCS_MAVLink/GCS.h, I edited the ap_message enum, adding an item called MSG_ROI_INTERRUPTION_DATA (it is placed in the enum before MSG_RETRY_DEFERRED).
  • In ArduCopter/UserCode.cpp, I am calling the method gcs_send_message(MSG_ROI_INTERRUPTION_DATA) from inside the FastLoop method, which is called at ~100 Hz.
  • In ArduCopter/GCS_MAVLink.cpp, I edited the try_send_message() method, inserting a new case, as shown in the figure below:

  • The send_roi_interruption_data() method just sends the message using the automatically generated method, as show in the figure (interruption_detected is a uint8_t variable set in other place, no worries there):

Well, that’s all in ArduPilot. Now, heading to MissionPlanner, that got a little tricky because I’m trying to understand the code for myself, which is not very easy because I’m just getting started with these studies. As far as I found out, the best way to detect the message that I could think of was editing the mainloop() inside FlightData.cs. My code is built like this:

while (threadrun) {
   try {
      MAVLink.MAVLinkMessage mavLinkMessage = MainV2.comPort.MAV.getPacket((uint)MAVLink.MAVLINK_MSG_ID.ROI_INTERRUPTION_DATA); 
      if (mavLinkMessage != null) {
         CustomMessageBox.Show("It works!", "Works!", MessageBoxButtons.OK);
      }
   }
   catch { }

This messagebox never showed up :sweat:
Then, I enabled console to read messages from MAVLink, and I found out that I was losing packets due to seqno. I’m sure those are my packets, because when I stop sending those messages, no packet is lost.

Sorry for the long post. Hope you can help me.

4

I did another test. Now I tried to just modify an existing message. Here is the procedure:

Ardupilot:

  1. I added a new field to the attitude message (id 30 in common.xml of the ArduPilot’s mavlink code).
  2. In ArduCopter/GCS_Mavlink.cpp, I edited the send_attitude() method, inserting a value 0.0 for the new field:
  3. Inside the ardupilot folder, I executed the command waf copter to build

Mission Planner:

  1. I added a new field to the attitude message (id 30 in common.xml of the MissionPlanner’s mavlink code).
  2. In the folder MissionPlanner/ExtLibs/Mavlink, I executed the file regenerate.bat.

In order to test, I run MissionPlanner in my Windows 10 notebook through VS2017, while the ArduPilot code is running inside a Linux virtual machine in VirtualBox (the SITL technique).

Well… the results were the same. Without this modification, no package loss. With the modification, all attitude packages were lost. No roll, pitch or yaw data was shown in Mission Planner.

What am I doing wrong?

5

because I cant see what you have done I cant really comment.

the seq no’s from either side stay sequential when using the correct library sending methods. if they are not sequential then there is either packet loss, or packets are failing to decode correctly

6

Several months have passed, and I still have the same issue. With the logs that I implemented, I am sure that:

  • My message is being sent by Ardupilot to the UART via method _mavlink_send_uart() present in mavlink_helpers.h
  • The method MAVLinkInterface::readPacket() in MissionPlanner does not recognize my message in the buffer.

The situation, according to the logs, is the following:

Ardupilot:

  1. Writes ATTITUDE message to UART
  2. Writes NEW message to UART
  3. Writes SIMSTATE message to UART

Mission Planner:

  1. Enters readPacket() method, reads ATTITUDE with seqno 39
  2. Enters readPacket() method, reads SIMSTATE with seqno 41
  3. Accuses packet loss: mav 1-1 seqno 41 exp 40 pkts lost 1

Would you mind trying to create a new message sent regularly by Ardupilot (via UserCode::mediumLoop(), for example) and see if you can reproduce the issue?

7

have you modified the MP code as well? as the new mavlink message will need to be known about as well as the crc extra.

8

Yes, I have modified it and I came to the conclusion that my code works. I got myself a Raspberry Pi and tried building and running my custom code in it. Works perfectly when communicating directly to MP. SITL still does not work.

With this result, my guess is that the problem is in the way that MavProxy forwards Mavlink messages to MissionPlanner. Any thoughts on this subject?

9

did you update pymavlink to include your new packet type?

10

That’s exactly the step that was missing, thank you very much!

I went to the tutorial on how to add a new MAVLink message to check if I was paying so little attention that I missed this step. Turns out that it was added to the tutorial only 3 weeks ago, so it was not entirely my fault :slight_smile:

Thanks for your kindness and patience.

12

@reddylopes I am having this same exact issue. Was this fix done in the Mission Planner code or on the Ardupilot side?

13

On the Ardupilot side, Just follow the updated instructions in this link and you will be fine.