Found a bug in mavlink_msg_gps_input.h and would like to report it

[Pawel Pocwiardowski]

Hi there

I found a bug in mavlink_msg_gps_input.h in MavLinkC_v2 which does not correspond to the definition on the MavLink2:

https://mavlink.io/en/messages/common.html#GPS_INPUT

Several members are out of order which makes the packing and sending not possible. 

The correct definition is:

typedef struct __mavlink_gps_input_t {
 uint64_t time_usec; /*< [us] Timestamp (UNIX Epoch time or time since system boot). The receiving end can infer timestamp format (since 1.1.1970 or since system boot) by checking for the magnitude of the number.*/
 uint8_t gps_id; /*<  ID of the GPS for multiple GPS inputs*/
 uint16_t ignore_flags; /*<  Bitmap indicating which GPS input flags fields to ignore.  All other fields must be provided.*/
 uint32_t time_week_ms; /*< [ms] GPS time (from start of GPS week)*/
 uint16_t time_week; /*<  GPS week number*/
 uint8_t fix_type; /*<  0-1: no fix, 2: 2D fix, 3: 3D fix. 4: 3D with DGPS. 5: 3D with RTK*/
 int32_t lat; /*< [degE7] Latitude (WGS84)*/
 int32_t lon; /*< [degE7] Longitude (WGS84)*/
 float alt; /*< [m] Altitude (MSL). Positive for up.*/
 float hdop; /*<  GPS HDOP horizontal dilution of position (unitless). If unknown, set to: UINT16_MAX*/
 float vdop; /*<  GPS VDOP vertical dilution of position (unitless). If unknown, set to: UINT16_MAX*/
 float vn; /*< [m/s] GPS velocity in north direction in earth-fixed NED frame*/
 float ve; /*< [m/s] GPS velocity in east direction in earth-fixed NED frame*/
 float vd; /*< [m/s] GPS velocity in down direction in earth-fixed NED frame*/
 float speed_accuracy; /*< [m/s] GPS speed accuracy*/
 float horiz_accuracy; /*< [m] GPS horizontal accuracy*/
 float vert_accuracy; /*< [m] GPS vertical accuracy*/
 uint8_t satellites_visible; /*<  Number of satellites visible.*/
 uint16_t yaw; /*< [cdeg] Yaw of vehicle relative to Earth's North, zero means not available, use 36000 for north*/
}) mavlink_gps_input_t;

I do not know how to report it to proper people so it gets fixed for others to use. 

So I will leave it to someone from this group to guide it please. 

thanks

Pawel

[Michael Oborne]

i dont believe what you found is an error at all
re https://github.com/mavlink/c_library_v2/blob/master/common/mavlink_msg_gps_input.h

the first thing to note is
xml order and packet order are not the same.

the fields are sorted by data type width, and then any mavlink2 extensions are appended to the end.

This was to optimise byte alignment for cpus that take a performance hit for non aligned reads.

Thanks

Michael

--
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/3545182c-14a4-42bd-8e6f-1f4ffa91f1b2n%40googlegroups.com auf.

[Pawel Pocwiardowski]

Hi Michael

OK, so I do I know what is a correct members orders in the structs?

The documentation on the MavLink shows different order. 

Which one to trust? It is a bit confusing that in such as strict formal as MavLink the documentation and code do not match members order.  

Should I always go with the repository code? 

thanks

Pawel

[Hamish Willee]

The ordering is documented here: https://mavlink.io/en/guide/serialization.html#field_reordering

Essentially things are ordered based on size of the data field, large items first (e.g. uint_64t ahead of uint_8) and if there are multiple items of the same type they then follow declaration order in the XML file. 
Then all fields in after an <extension> tag in the XML appear in XML file declaration order.

[Pawel Pocwiardowski]

Roger that

Thank you for the explanation.