Int32 param fails but Real32 works about gomavlib HOT 6 CLOSED

It looks like the issue comes from the way the flight controller casts the parameter value. The line in question is s->val.i = *(int32_t *)val; The equivalent line for a float param is s->val.f = *(float *)val; which works correctly. It seems like even though the param set message always sends a float value, the binary data contained in that float value is directly cast as whatever datatype the PARAM_TYPE_XXX says, in this case an int32.

A potential solution is:

• gomavlib casts the data to an int32 (or other MAV_PARAM_TYPE) binary representation
• casts that binary representation to a float*
• sets the float value in the param set message to that binary representation

Does this seem like a reasonable approach? I'm not sure if this is an issue on other flight controllers or if it's only an issue for PX4.

from gomavlib.

I think I found a solution/workaround. It might be worthwhile to implement this in the gomavlib library so a user doesn't need to worry about casting datatypes. I used a standard type cast to convert the floating point value to an int, converted the int to its binary form with the encoding/binary package, and then wrote the resulting binary representation back to the address of my floating point parameter value. Things seem to work now.

from gomavlib.

Seems like this is the way the message is intended to work. The solution I proposed has been tested on hardware and seems to be reliable.

from gomavlib.

Hello, dialects are automatically generated from definitions, therefore this issue is common to all programming languages. At the moment there aren't much utilities in the library since it's already hard to support all upstream changes that come from the main Mavlink repository, so adding more stuff is out of the reach.

from gomavlib.

from gomavlib.

This issue is being locked automatically because it has been closed for more than 6 months.
Please open a new issue in case you encounter a similar problem.

from gomavlib.