Support MAVLink MANUAL_CONTROL.aux extension #22108
Conversation
| @@ -2063,6 +2063,19 @@ MavlinkReceiver::handle_message_manual_control(mavlink_message_t *msg) | |||
| // For backwards compatibility at the moment interpret throttle in range [0,1000] | |||
| manual_control_setpoint.throttle = ((mavlink_manual_control.z / 1000.f) * 2.f) - 1.f; | |||
| manual_control_setpoint.yaw = mavlink_manual_control.r / 1000.f; | |||
|
|
|||
| if (mavlink_manual_control.enabled_extensions & (1u << 2)) { manual_control_setpoint.aux1 = mavlink_manual_control.aux1; } | |||
There was a problem hiding this comment.
| if (mavlink_manual_control.enabled_extensions & (1u << 2)) { manual_control_setpoint.aux1 = mavlink_manual_control.aux1; } | |
| if (mavlink_manual_control.enabled_extensions & (1u << 2)) { manual_control_setpoint.aux1 = mavlink_manual_control.aux1; | |
| } else { | |
| manual_control_setpoint.aux1 = NAN; | |
| } | |
There was a problem hiding this comment.
That's exactly where I was going but first I need to make sure that's documented and handled appropriately. Then I feel confirmed and will do that 👍
There was a problem hiding this comment.
I realized I have to clarify my wording here:
Until now any RC channel not being mapped/available results in the corresponding manual_control_setpoint field being set to zero. See for example here:
This is neither explicitly documented nor does it allow the client to detect it's not available. So I'm happy to change this but I would not make it part of this pull request because it will be a lot of changes requiring extensive testing and only the suggested else cases need to be added for the functionality added in this pr.
MaEtUgR
force-pushed
the
maetugr/mavlink-manual-control-aux
branch
from
2668eca
to
5cda4f4
Compare
Note that in uORB we don't currently know if the aux fields are specifically valid or not so we can also not set the corresponding bits in the field.
MaEtUgR
force-pushed
the
maetugr/mavlink-manual-control-aux
branch
from
5cda4f4
to
6529a51
Compare
|
I tested it against a degenerate MAVSDK example and fixed a scaling issue, so it now works as expected. The uORB manual control fields' validity using NAN needs to be addressed in a separate PR because all components need to be adapted. I can follow up. |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/control-aux-channels-with-usb-joystick/41686/5 |
Solved Problem
When working on #22102 I realized there's no way to get auxiliary continuous inputs in over MAVLink. That's why we came up with the suggestion to support it in MAVLink mavlink/mavlink#2031 and this pr brings the implementation to PX4.
Solution
MANUAL_CONTROLfields when it's an inputmain use case
MANUAL_CONTROLas telemetryonly done sent with the USB telemtry profile
Changelog Entry
Alternatives
Note that in uORB we don't currently know if the aux fields are specifically valid or not so we can also not set the corresponding bits in the field and vice versa. I'll propose to set the fields differently from just zero-initialized to indicate them being valid or not.
Test coverage
I have no counterpart to test this with just yet.
Context
The requirement to have these auxiliary inputs available for a remote communicating via MAVLink arose from mapping a knob to slow down an axis in #22102