Mavlink_receiver.cpp doesn't include signal_quality for distance_sensor messages

[tuloski]

distance_sensor uORB message includes a signal_quality field.
In the mavlink_receiver.cpp when some mavlink messages (as DISTANCE_SENSOR #132) should be translated into uORB messages, that field is not filled, causing the message to not be accepted as valid.

It is also not very clear how to generate that field from mavlink messages, since there is not a field in the mavlink message that can be translated into a signal_quality. Just put 100 (perfect signal)? Or -1? Derive a value from covariance?

Example of missing field: https://github.com/PX4/Firmware/blob/73ed9deac507c86892afadee5bca2024b5b8da17/src/modules/mavlink/mavlink_receiver.cpp#L824-L834

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.

[julianoes]

Thanks for the issue, sorry for the late response. I would vote "Or -1?" given the fact that it's unknown. Are you interested in making a pull request?

[tuloski]

Yes I can make a pull request.
Probably in a few days.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[mcsauder]

UPDATED/EDITED: I just dug into this, there is a mismatch between the distance_sensor_t definition and the mavlink_distance_sensor_t definition. The signal_quality field is missing from the mavlink_msg_distance_sensor.h definition of mavlink_distance_sensor_t:

I've opened PR #13131 to address this issue and will open an RFC in the mavlink rfc repo as soon as I can to propose a future change.

[tuloski]

@mcsauder I don't think MAVlink should be modified. It's the autopilot that should adapt to MAVlink, unless those fields are really important for that message type.

[TSC21]

@mcsauder I don't think MAVlink should be modified. It's the autopilot that should adapt to MAVlink, unless those fields are really important for that message type.

The message fields are not modified: you can extend the message by adding new fields. I don't see any issue on adding a sensor quality field on the Mavlink message (the other three already exist).

Closing this as it was solved in #13131.

[mcsauder]

Thanks @tuloski and @TSC21 !