Devcall topic: consider moving MAVLink RC_OVERRIDE to the common MAVLink

[AndKe]

Feature request

Please consider moving MAVLink RC_OVERRIDE to the common MAVLink (not only Ardupilot dialect).

Additional context
This packet is very useful, having it in common would make it easier to improve and add new joystick features to QGC.
The common dialect has MANUAL_CONTROL packet, but it has fewer channels, and is less "generic".
For example, if joysick is to be used to control an robotic arm or gimbal, full freedom to override any RC channel is much more useful than 4 axis +AUX1-6

[DonLakeFlyer]

FYI: I'm in the process of updating QGC Joystick to be able to support the full extensions on MANUAL_CONTROL including the ability to calibrate joysticks to use them. With this support it means QGC would also be able to easily support RC_OVERRIDE (if it was in common) from joysticks as well. This would certainly open up all sorts of interesting possibilties.

[pranitaurlam]

@AndKe
#32047 to inform them that RC_CHANNELS_OVERRIDE is already in common.xml. Would you like me to draft a comment for the issue?

[AndKe]

Good point, we have too many variants of this packet.
ArduPilot does not seem to use RC_CHANNELS_OVERRIDE at all, ArduSub uses MANUAL_CONTROL, then we have the RC_OVERRIDE.

Would it be acceptable to use RC_CHANNELS_OVERRIDE for QGC ? - when I could add it to ArduPilot vehicles.
It seems like this needs a cleanup.

[muramura]

I believe that RC_OVERRIDE should not be recommended as a generic vehicle control interface.
Instead, MANUAL_CONTROL should be the default approach.

The reasons are as follows:

RC_OVERRIDE is based on raw PWM values and therefore strongly depends on
RC vendors, protocols, and calibration differences.

This design pushes hardware-specific knowledge onto the GCS or companion computer side.

MANUAL_CONTROL uses normalized inputs in the range -1.0 to +1.0,
representing pilot intent rather than hardware-level values.

If PWM output is required, it should be derived inside ArduPilot using RC calibration,
and raw PWM values should not be required as an external API.

[AndKe]

I have no strong opinion about the normalisation of inputs, but I see your point.
maybe the best of both worlds would be to support for MANUAL_CONTROL , and RC_OVERRIDE or RC_CHANNELS_OVERRIDE as PWM-based override of any channels?
My main "issue" with MANUAL_CONTROL is that has support for very few channels.

[peterbarker]

Please consider moving MAVLink RC_OVERRIDE to the common MAVLink (not only Ardupilot dialect).

Sorry - which message exactly?

pbarker@crun:~/rc/ardupilot/modules/mavlink((HEAD detached at origin/master))$ git grep RC_OVERRIDE
pbarker@crun:~/rc/ardupilot/modules/mavlink((HEAD detached at origin/master))$ 

[peterbarker]

Good point, we have too many variants of this packet. ArduPilot does not seem to use RC_CHANNELS_OVERRIDE at all,

confused

ArduSub uses MANUAL_CONTROL, then we have the RC_OVERRIDE.

MANUAL_CONTROL is available on all vehicles. Mostly used by sub users, however.

[peterbarker]

I've removed DevCallTopic for now as this is currently (AFAICS) completely non-sensical as an issue.

[DonLakeFlyer]

I'm not sure folks are looking at this the right way:

• Firmware tends to have support for things happening based on RC channel PWM values. Specifically gimbal stuff.
• If the firmware had support for RC_CHANNELS_OVERRIDE then a GCS could do interesting things with joysticks which output RC stuff to make things happen. Move gimbals, press buttons to take actions, operate a servo to do some payload thing, ...
• QGC already has joystick button support to make things happen all working from the GCS side. But I think this might open up even more possibilities.
• It's not about flying the vehicle with RC_CHANNELS_OVERRIDE it's about everything else that might be possible

At least that's the way I was looking at it.

[AndKe]

I am sorry for the incorrect statement about RC_CHANNELS_OVERRIDE , that was a brainfart after quick glance at GCS_MAVLink_Copter.cpp - my bad, I should have remembered that I used those packets myself a few years back.
Please do not let this issue go nowhere because of that.

What I am hoping for, is that QGC / @DonLakeFlyer can freely map any joystick axis to any channel, not just for flying, but payload control.
Now that we established that RC_CHANNELS_OVERRIDE and MANUAL_CONTROL both common MAVLink packets are available, this may be solved by QGC using those packet types depending on joystick mapping? -and no change to MAVLink is needed?

[peterbarker]

I am sorry for the incorrect statement about RC_CHANNELS_OVERRIDE , that was a brainfart after quick glance at GCS_MAVLink_Copter.cpp - my bad, I should have remembered that I used those packets myself a few years back. Please do not let this issue go nowhere because of that.

What I am hoping for, is that QGC / @DonLakeFlyer can freely map any joystick axis to any channel, not just for flying, but payload control. Now that we established that RC_CHANNELS_OVERRIDE and MANUAL_CONTROL both common MAVLink packets are available, this may be solved by QGC using those packet types depending on joystick mapping? -and no change to MAVLink is needed?

Well, the messages are all in common.xml - so at the very least the topic of this issue is wrong :-)

QGC is free to use the mavlink interface as it chooses, of course. But I have Reservations, which I'll cover in a separate comment.

[peterbarker]

* Firmware tends to have support for things happening based on RC channel PWM values. Specifically gimbal stuff.

Certainly some gimbals are connected to the autopilot using (e.g.) three PWM wires which can be used to control the gimbal. That's really rather rare, 'though, and isn't really a great setup.

* If the firmware had support for RC_CHANNELS_OVERRIDE then a GCS could do interesting things with joysticks which output RC stuff to make things happen. Move gimbals, press buttons to take actions, operate a servo to do some payload thing, ...

All of those operations are better done through specific messages rather than RC_CHANNELS_OVERRIDE. gimbals are far better controlled by sending in one of the gimbal-position or gimbal-rate messages. That allows the GCS to be agnostic about just what sort of gimbal it is talking to. I've got servo gimbals, mavlink gimbals and proprietary-protocol gimbals floating around on my desk at the moment, but I use exactly the same commands to control them.

Not really sure what "press buttons" means... but ArduPilot uses a huge list of auxiliary functions which can be triggered through a variety of sources. You actually use that list when setting (e.g.) RC5_OPTION in QGC - the population of that dropdown box is the list of auxiliary functions. These auxiliary functions can also be triggered via mission items using MAV_CMD_DO_AUX_FUNCTION, or via a direct mavlink message to the vehicle using that same MAV_CMD. The same functions are also available to our Lua scripting. You can also trigger those functions by pressing physical buttons on the vehicle! It's a cheap and cheerful interface which is really useful :-)

MissionPlanner actually has a tab set aside for aux functions in its interface. You already actually use MAV_CMD_DO_AUX_FUNCTION for toggling the interlock in QGC. These AUX functions would probably work in really well with the "quick button" array thing you can have in the QGC interface (might have been replaced with Fly View Actions now?)

There's MAV_CMD_DO_SET_RELAY to handle relays (and the "repeat" equivalents).

* QGC already has joystick button support to make things happen all working from the GCS side. But I think this might open up even more possibilities.

* It's not about flying the vehicle with RC_CHANNELS_OVERRIDE it's about everything else that might be possible

I'm afraid I don't see a compelling reason to couple anything to RC overrides. Better for the vehicle to know what it is doing so it can deal with the device in other ways (e.g. stow camera for landing, use camera/gimbal in missions, ....)

I've seen things go pretty wrong with them, however.

Don't get me wrong, they're astonishingly useful in some circumstances, particularly when setting a vehicle up, or when you need to hack something together. But where there are existing mechanisms to accomplish something we really should try to fit in with those mechanisms.