problem with using mavlink library

[alexandre feijoeiro]

Hello All,

i need dome help to understand why my code doesn't work, it's very easy code which use Mavlink library in order to encode message.

int main (int argc, char ** argv){
  mavlink_message_t msg;
  int32_t lat = 10;
  int32_t longe = 11;
  int32_t alt = 12;
  int32_t relative_alt = 15;
  int16_t vx = 16;
  int16_t vy = 17;
  int16_t vz = 18;
  uint16_t hdg = 19;
  uint16_t size = 0;
  int i = 0;
 
  uint8_t buffer[280];
  for(i=0;i<280 ; i++){
    buffer[i] = 0;
  }
  mavlink_msg_global_position_int_pack(1, 2, &msg, 100, lat, longe, alt, relative_alt, vx, vy, vz, hdg);

  size = mavlink_msg_to_send_buffer(buffer, &msg);

  for(i=0;i<size ; i++){
   printf("%i\n",buffer[i]);
  }
  printf("total size : %i\n",size);
  return 1;
}

the result of this code is 

253  => ok 0xFD
27 => ok lenght
0 => inc flags
0 => ok cmp flags
0 => ok SEQ
1 => ok sys ID
2 => ok COM ID
33 => ok message 33 (fisrt byte)
0 => ok (second byte)
0 => ok (third byte)
100 => ok value of time boot ms (fisrt byte)
0 => ok value of time boot ms (second byte)
0 => ok value of time boot ms (third byte)
0 => ok value of time boot ms (fourth byte)
10 => ok value of lat parameter (fisrt byte)
0 => ok value of lat parameter (second byte)
0 => ok value of lat parameter (third byte)
0 => ok value of lat parameter (fourth byte)
11 => ok value of longe parameter (fisrt byte)
0 => ok value of longe parameter (second byte)
0 => ok value of longe parameter (third byte)
0 => ok value of longe parameter (fourth byte)
12 => ok value of alt parameter (fisrt byte)
0 => ok value of alt parameter (second byte)
0 => ok value of alt parameter (third byte)
0 => ok value of alt parameter (fourth byte)
15 => ok value of relative alt parameter (fisrt byte)
0 => ok value of relative alt parameter (second byte)
0 => ok value of relative alt parameter (third byte)
0 => ok value of relative alt parameter (fourth byte)
16 => ok value of vx parameter (fisrt byte)
0 => ok value of vx parameter(second byte)
17 => ok value of vy parameter (fisrt byte)
0 => ok value of vy parameter(second byte)
18 => ok value of vz parameter (fisrt byte)
0 => ok value of vz parameter(second byte)
19 => ok value of hdg parameter (fisrt byte) but no second byte,  value is coded with 2 bytes (uint16_t hdg = 19;) and i don't have the second one with value 0.
198 => checksum (fisrt byte)
254 => checksum(second byte)
total size : 39

Do you have an idea?

Thanks a lot

[Hamish Willee]

Almost certainly empty byte truncation: https://mavlink.io/en/guide/serialization.html#payload_truncation

Zero filled bytes are truncated off the end after reordering for sending. The C code in mavgen (for example) starts by copying the received data into a buffer of the right size. 

Hope that helps!

[Patrick Arnoul]

Hello,

I am currently  trying to send commands to my Arducopter 4.2.3 from my onboard companion (Teensy), in order to change its flight mode, please find below my code...

It doesn't work at all, I cannot see any trace of the Mavlink commands in Mission Planner "Mavlink Inspector".

The Heartbeat messages from my companion computer show up in Mavlink Inspector, no problem with that...

Thanks for any help,

Patrick

void Set_flightmode(uint8_t mode) {    // Emission de la commande set flightmode

// #define MAV_CMD_DO_SET_MODE 176

  uint16_t command=176;
  uint8_t confirmation=0;
  float param1=1;
  float param2=mode;
  float param3=0;
  float param4=0;
  float param5=0;
  float param6=0;
  float param7=0;

 
  //< ID 1 for this system
  int sysid = 2;                  
  //< The component ID sending the message.
  int compid = 191;  
 
  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];
 
  // Pack the message
  mavlink_msg_command_long_pack(sysid, compid, &msg, 1, 1, command, confirmation, param1, param2, param3, param4, param5, param6, param7 );
 
  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);
 
  // Send the message
  Serial2.write(buf, len);

 }

[Hamish Willee]

Hi Patrick

How are the mission planner, flight controller and onboard computer connected? It is possible that you're not routing commands to the mission planner from the autopilot.

Depending on how things are wired up I'd be using Wireshark https://mavlink.io/en/guide/wireshark.html to see if the traffic is moving where you expect it to. You might also be able to log on the autopilot to see if it is getting the commands.

Any command you send to the vehicle  should get back a response with a https://mavlink.io/en/messages/common.html#COMMAND_ACK with a result. That is what you need to look for. Note that setting modes is a bit of pain to get right. You should copy the approach used in pymavlink to set ardupilot modes correctly.

After trying that, suggest you re-raise the question on the ArduPilot forums, as they will have a better idea of debugging tricks and configuration for ArduPilot.

Cheers
H

--
Sie erhalten diese Nachricht, weil Sie in Google Groups ein Thema der Gruppe "MAVLink" abonniert haben.
Wenn Sie sich von diesem Thema abmelden möchten, rufen Sie https://groups.google.com/d/topic/mavlink/mRmcniPbHVg/unsubscribe auf.
Wenn Sie sich von dieser Gruppe und allen Themen dieser Gruppe abmelden möchten, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CAMR7w0C_X14RsbuJud4JUKiDDDeBHksRVfewpRuW--N1t%2Br5WA%40mail.gmail.com auf.

[Patrick Arnoul]

Hello Hamish,

Ok, I'll investigate the Ardupilot issue, it might be a sort of protection against two GCS requesting for flight mode change, or simply that only the first GCS has the right to control the UAV...

As I said, the heartbeat of my companion board go through the link, as well as the requests for Mavlink data streams.

I'll let you know,

Thanks a lot,

Patrick

Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "MAVLink" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CA%2BO3EpTNVs4NaururTXDHkxBVDNS0jxsuOuGwBwkkk8pt1J%3DdA%40mail.gmail.com auf.

[Hamish Willee]

So when you request data streams are you using https://mavlink.io/en/messages/common.html#MAV_CMD_SET_MESSAGE_INTERVAL ? And you get a COMMAND_ACK back for that? But you get no COMMAND_ACK back for  MAV_CMD_DO_SET_MODE

That is very odd. If you get an ACK back for one, you should get it back for all.

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CAMR7w0DUwjNaMpfZ9Fa6cV0ArkM5GWbp6mbei6ToovKUwQ5-Ng%40mail.gmail.com auf.

[Patrick Arnoul]

Hello Hamish,

Problem solved  😊   I discovered that there are two things limiting the flight mode change Mavlink commands from my companion computer towards the Ardupilot FC :

1/ I believe the component ID of the Mavlink source message should be a known GCS to be granted the right of submitting a flight mode change by the Ardupilot FC. I was using compid=191 (i.e. MAV_COMP_ID_ONBOARD_COMPUTER) and I happened to try compid=190 (i.e. MAV_COMP_ID_MISSIONPLANNER) to get the command accepted !  This is probably Autopilot dependent, a sort of security measure (I am right ?).

  2/ As per Mavlink routing within the Ardupilot FC, I realized that using a target sysid of 0 from my companion computer enabled the broadcast of its Mavlink messages and thus allowed me to see them in Mission Planner "Mavlink inspector". The companion messages are propagated through the GCS telemetry link. Which makes sense, right ?

The strange thing is that if I keep the source compid  MAV_COMP_ID_ONBOARD_COMPUTER, AND use a target sysid of 0 (broadcast), the Ardupilot FC *does* take into account the commands from the companion !  Which doesn't seem very secure, but it is very useful to see the mavlink packets within MP Mavlink Inspector.

I added to my code the decoding of the command_ack messages to make sure the command is granted (yes, my change mode messages are properly acknowledged by the FC.

Thanks again for your support   😊

Patrick

> Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CA%2BO3EpRjreXeX9%2BHSxnY5L32ep_YcFXKGO2XO8W4Sv%3DNVti9aA%40mail.gmail.com auf.

[alexandre feijoeiro]

Hello Hamish,

thanks a lot for your help :)

Alex 

[Hamish Willee]

Hi Patrick,

1. You might be right about the cause being an expected component ID. If so though, that is probably a bug since IDs are used for routing and for a component to determine if it is the expected target of a message. A destination shouldn't decide whether it is the intended target based on the source of a message.
2. 0 is the broadcast address - so if a message has target_system, target_component of 0 (or does not have those fields) recipients know that they need to handle the message. A routing component should forward broadcast messages from one channel to other channels. A routing component should forward targetted messages to channels if it has seen the target HEARTBEAT on that channel.
  
   If your companion computer is sending a command to set the mode https://mavlink.io/en/messages/common.html#MAV_CMD_DO_SET_MODE it should set the target id and component of the FC. The autopilot should respond to the source address of the command with an ACK. If that doesn't work, but heartbeat's do then there is something wrong with the routing.

It is worth reading this: https://mavlink.io/en/guide/routing.html to understand routing. It has nothing to do with security. There is almost no security at all, though you can set what operator is in control using https://mavlink.io/en/messages/common.html#CHANGE_OPERATOR_CONTROL on some flight stacks, and messages can be signed and you can choose to only obey signed messages.

You'd be best asking on the ardupilot discussion boards, outlining how the messages flow between GCS, FC, and companion computer and what you are seeing - I can only comment on what the specification expects.

Regards

Hamish

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CAMR7w0A9w6jBckTqC5WTNQckgWe6eRgLdzw8mfCqT3v1sJpcNw%40mail.gmail.com auf.

[Patrick Arnoul]

Hello Hamish,

Thank you very much for the accurate information, I believe there is an Ardupilot implementation fact, and I found a way of dealing with the constraints    :-)

I posted my problem in the Ardupilot.org Facebook, and the day after how I solved it, along with the facts of using system and components IDs.

No answer so far.

Best regards,

Patrick

PS: There is no Command Ack from the Ardupilot FC for the data stream requests. Mission planner is requesting the same data streams every minute or so. I am doing the same from my companion computer.

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CA%2BO3EpT0niTpzBhmBze2nEcLEK%2BN85Urf6NS7vnzDmDCqhApnQ%40mail.gmail.com auf.

[Hamish Willee]

Hi Patrick

1. I assume you mean you get no response to https://mavlink.io/en/messages/common.html#MAV_CMD_SET_MESSAGE_INTERVAL when directed to ArduPilot unless you use the mission planner component ID.
2. Personally I think facebook is the poorest of places to ask technical responses - it doesn't hold the answers for easy retrieval. I'd post on https://ardupilot.org/ -
3. Suggest you raise again. Make sure your statement is worded as a query and explains what you tried and where the messages go - i.e. if it is GCS <> Companion <> FC, OR GCS <> FC <> Companion, or something else.

Lastly, these are solved problems in Pymavlink, MAVSDK, etc. If I had to debug this I would try using pymavlink to set the command. That works and can change modes. So should give you an idea of what is going wrong if you inspect the messages.

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/CAMR7w0AETCNup0iVWxoTqdWf-ntLPXg0S4tv8g2DFO1OeJis_w%40mail.gmail.com auf.