Discussion :

[L_Alexandre]

Bonjour à tous,

je me permets de vous solliciter suite à une incompréhension dans le bout de code que j'ai fait. En effet quand je compile et exécute mon code je trouve un résultat incohérent

J'utilise une API/librairie MAVLINK (https://mavlink.io/en/mavgen_c/) disponible sur internet permettant de formatter des données.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
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;
}

https://github.com/mavlink/c_library...position_int.h pour la fonction : mavlink_msg_global_position_int_pack
http://docs.ros.org/en/jade/api/mavl...8h_source.html ligne 157 pour la fonction : mavlink_msg_to_send_buffer


A la fin du formatage pour mois il me manque un octet de donnée (voir https://mavlink.io/en/guide/serialization.html pour formatage de la trame)
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) il n'y a pas le second byte, pour moi la valeur est codé sur 2 bytes, il devrait donc y avoir un zéro après le 19
198 => checksum (fisrt byte)
254 => checksum(second byte)
total size : 39

Merci beaucoup pour votre aide

[Guesset]

Bonjour,

Sans aller farfouiller dans le code de ces bibliothèques, j'observe que message est sur 3 octets ce qui est surprenant bien que peut-être légitime.

Que se passe-t-il si hdg est à 256 ? On obtient 0 1 ? Sinon il y a vraisemblablement une erreur dans la bibliothèque mais je n'ai pas le courage de la décortiquer.

Cela ressemble à l'oubli du dernier byte qui est hdg_lo (la checksum, par définition, est calculée en dehors du traitement principal - comme les 14 octets d'entête).

Salutations