Can RC(n)_OPTION be used to initiate a custom MavLink command?

Today I set up the shoulder button on my HereLink to operate my camera shutter by configuring the HereLink settings so that a shoulder button short-press would transmit PWM 1900 on RC channel-7.

This required setting parameter: RC7_OPTION=9 (Camera Trigger)

CubePilot advises not to use these HereLink level button assignments for flight modes - recommending instead that flight modes be set in the Apps that send MavLink commands for the flight mode changes over the telemetry link.

CubePilot also recommends using the HereLink level button assignments - which are configured to send PWM signals on RC channels - for all other inputs to the flight controller - where possible.

Following that recommendation, the actions HereLink buttons can perform are limited to the options on the RC(n)_OPTION parameter.

There’s a long list of possible options defined for RC(n)_OPTION - including a couple of “user function” or “custom function” options. (labeled differently depending on where in the wiki you reference)

While the list of options is quite extensive, it might be of even greater value if a custom MavLink commands with parameters could be set for some of these options.

Is there a way to accomplish this - or has there been any discussion about adding such a capability?

Lua scripting adds almost exactly this. It’s typically a bit odd to send a telemetry message to the flight controller from the flight controller, so instead the recommended mechanism for an unsupported scripting feature that would otherwise be triggered via MavLink is to request or write a backend binding to the C++ method that invokes the desired feature.

It’s almost certainly unwieldy to write a library to act on any given MavLink message via RC, given the number of checks and parameter assumptions required to do so.

But if Lua ain’t your thing, and you have a specific feature request, that might be possible.

No doubt, there’s a role for LUA scripts.

But consider this situation - suppose you wish to simply have a HereLink button to point the camera down for the NADIR position for photogrametry or other similar needs. This is done in a mission with the DO_MOUNT_CONTROL statement:

A HereLink button that initiates a simple Mavlink command such as this:

Would be quick and easy to implement of RC(n)_OPTION could be assigned to such a MavLink command.

And by setting the first parameter to “0” the gimbal can be placed back up in the level position for parking.

Being able to easily use a HereLink button to position a gimbal “down” with a short press, and position the gimbal to “up” with a long press, would be really useful - without having to deal with the complexity of writing and implementing a LUA script.

There is an existing Lua binding for mount:set_angle_target(instance, roll_deg, pitch_deg, yaw_deg, yaw_is_earth_frame), which is, I think, the method acted upon by the message in question.

This seems the ideal case to leverage it. I think commanding NADIR on a switch would be quite simple via scripting unless I’m misinterpreting this binding.

Consider the number of possibilities this feature has. It would require 6 additional parameters to define the park and user commanded position, along with a channel definition. Now imagine how many additional parameters might be required to implement MavLink messages of choice on RC, accounting for all variation or user preference. It gets unwieldy very quickly.

Lua scripting is made available, in part, to implement custom features like this without contributing to overall code bloat.

FWIW, I think I could write this script in a matter of minutes, including some custom parameters you could use to command desired behavior. Again, assuming I am correct in my assessment of the binding’s behavior. Because the states are binary, there’s not even a need to differentiate long vs short press. A press of the button could simply toggle between park and NADIR. I could provide such an example if you are interested.

I should say, also, that Lua scripting is at the whim of your imagination rather than depending on release cycles. So if you want a feature now, it’s often to your advantage to simply script it.

As an example of the speed at which features can be added, I decided to just write the script. 44 lines of Lua, attached below.

Enable scripting and upload the script per the wiki. The default heap size should be fine. Once active, the script will create a series of “MNTS” parameters.

Reboot and look for the MNTS_* parameters. Set MNTS_RC_CHAN to the channel you wish to use for control. If you change MNTS_RC_CHAN, reboot to take effect.

Use that channel as a momentary toggle. When it goes from low to high, the script will toggle gimbal positions.

Your use case should be included in the default angle parameters.

mount_toggle.lua (2.1 KB)

1 Like

Yuri - I really wish you’d stop hijacking my posts to promote alternate ideas of your own. You’ve done it before - and now again here. As a result - these subsequent comments on this thread will likely cause others to pass over it - thinking that the matter is closed.

The ability to launch LUA scripts is a documented options for RC(n)_OPTON. And the ability of a LUA script to issue a MavLink command is no surprise. So all you’ve done is proven the obvious - which is something quite different than what I proposed.

The number of MavLink commands, combined with possible values of their seven parameters, make for a impossibly huge number of combinations. Writing a LUA script for each is impractical - even for those who are seasoned at writing LUA.

Maybe there’s a way to do what I propose with the existing firmware - maybe not. Maybe the DEV’s will agree to add it - maybe not. But the ease of using MavLink command directly tied to a RC Channel PWM signal would be a great boon to people who own things like the CubePilot HereLink - which has a limited number of controls.

Yuri - you have great initiative, and notable ability. But please showcase those in some place other than my posts when they are counter to my query or proposal.

I generally avoid your topics because it’s clear we don’t see eye to eye. In this case, I truly thought I was helping - quite a bit, in fact, by implementing the exact feature you suggested. Have nothing to gain from any so-called self-promotion.


It’s easy enough to avoid misunderstanding by asking questions.

Example: Would the ability to have a LUA script issue a MavLink command meet your need?