Support for N-Position switches via flexible channel ranges

[lvale]

Issue details

Support for N-Position switches via flexible channel ranges.

Currently the flight mode CH5 is the only that supports fixed ranges for multiple actions (different flight modes)

There is a limited support for 3 fixed positions switches on some AUX/Options channels, again with fixed range (max-mid-min)

So this could be split on 2 stages.

1st stage - enabling flexible channel ranges 2nd stage - extend the flexible range options to the AUX/Options channels

This would require support to configure from the GCS devs.

Version

All

Platform

[X] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover

Airframe type

All

Hardware type

All

Logs

N/A

[peterbarker]

Related issue: it would be nice to replace FLAP_IN_CHANNEL with an RCn_OPTION value - but FLAP_IN_CHANNEL is not a switch, it's a continuous input.

It's also related to the elimination of RC_MAP.

[WickedShell]

@peterbarker there is a bit of an happiness with having multiple things/options on a channel though, which would be painful to see go away. (I have several functions mapped ontop of my flight mode channel for example)

[peterbarker]

Sure. How do we represent this information in the parameters nicely?

For the flight mode switch we have 6 magic parameters (at adjacent offsets, no less). Adding N parameters to RC_CHANNEL... not really an
option :-)

Some sort of indirection? "virtual switches" as it were?

So

RC10_OPTION=4242  // RC_Channel::aux_func::virtualswitch1
RC_VS1_1=3  // RC_Channel::aux_func::SIMPLE_MODE  // RC VirtualSwitch1 position 1
RC_VS1_2=13 // RC_Channel::aux_func::SUPERSIMPLE_MODE  // RC VirtualSwitch1 position 2
RC_VS1_3=666 // RC_Channel::aux_func::INVOKE_ARMAGEDDON   // RC VirtualSwitch1 position 3
RC_VS1_4=4242 // RC_Channel::aux_func::BLOW_MIND   // RC VirtualSwitch1 position 4
.
.
.

You're still making a continuum discrete, of course.

Any other proposal?

[peterbarker]

Ah. Re-reading @WickedShell 's post - I think he's talking "in parallel" where @lvale is talking "in series".

"In parallel" is probably best done with RCn_OPTION2 or similar - at least I haven't come up with anything better.

[lvale]

First thing would be to end the magic values and have a division in x parts of the configured range. User would choose how many functions per channel up to 6? 8? 10? The intervals should be larger than the 2 x RCx_DZ. By default this would allow to maintain the current behaviour

Then for each configured RC channel, we would have a RC_OPTIONz where z would depend on the previously configured value above.

So, for each channel, by default we would have a new parameter RC_OPTIONS_PER_CHANNEL (that by default would be the same as we have now (6 for flight mode selection, 2 for all others) So now remains how to set the available options on each channel without "exploding" the number of parameters. Considering that we could have xFF (256) possible options available the parameter to be added on each position I would say the easiest would be to store all on a single variable of length 2bytes per configured option x nr of options defined above.

[peterbarker]

There are 2^16 options available, not 256.

I don't think we can multiply parameters like this - thus the indirection concept mentioned.

[lvale]

Sorry, I wasn't clear What I meant by available options are these, and with room to expand up to 256

I would add to this list the flight modes (25?)

http://ardupilot.org/copter/docs/parameters.html#ch7-opt-channel-7-option

Values

0 | Do Nothing
2 | Flip
3 | Simple Mode
4 | RTL
5 | Save Trim
7 | Save WP
9 | Camera Trigger
10 | RangeFinder
11 | Fence
13 | Super Simple Mode
14 | Acro Trainer
15 | Sprayer
16 | Auto
17 | AutoTune
18 | Land
19 | Gripper
21 | Parachute Enable
22 | Parachute Release
23 | Parachute 3pos
24 | Auto Mission Reset
25 | AttCon Feed Forward
26 | AttCon Accel Limits
27 | Retract Mount
28 | Relay On/Off
34 | Relay2 On/Off
35 | Relay3 On/Off
36 | Relay4 On/Off
29 | Landing Gear
30 | Lost Copter Sound
31 | Motor Emergency Stop
32 | Motor Interlock
33 | Brake
37 | Throw
38 | ADSB-Avoidance
39 | PrecLoiter
40 | Object Avoidance
41 | ArmDisarm
42 | SmartRTL
43 | InvertedFlight
44 | Winch Enable
45 | WinchControl

Value   Meaning
200 Stabilize
201 Acro
202 AltHold
203 Auto
204 Guided
205 Loiter
206 RTL
207 Circle
209 Land
211 Drift
213 Sport
214 Flip
215 AutoTune
216 PosHold
217 Brake
218 Throw
219 Avoid_ADSB
220 Guided_NoGPS
221 Smart_RTL
222 FlowHold
223 Follow

Value   Meaning
230 Manual
231 CIRCLE
232 STABILIZE
233 TRAINING
234 ACRO
235 FBWA
236 FBWB
237 CRUISE
238 AUTOTUNE
240 Auto
241 RTL
242 Loiter
244 AVOID_ADSB
245 Guided
247 QSTABILIZE
248 QHOVER
249 QLOITER
250 QLAND
251 QRTL

Please note that on the flight modes table I added 200 (copter) and 230 (plane) to make them distinct from the options

As an example for a RC channel defined as 3 position we could have

200.004.018 So on each position we would have Stabilize, RTL, Land

or

200.028.009 Stabilize, RelayON/OFF, Camera Trigger

or to emulate the current 6 Pos switch we could have

200.216.213.205.207.214 all defined as flight modes.

Now on an extreme case where it was possible to have 10 ranges, and all the options were defined as Stabilize we would have

200.200.200.200.200.200.200.200.200.200

As a reasonable guess on a standard RC system where PWM on a channel goes from 1000 to 2000 and we assume a DZ of 100 we would require a 2x the DZ for each range so that would be 5 available options, or if we want to keep the 6 as max we would have 1.6x the DZ value.

at the moment we have overlap between some flight modes and options, so that would require some consolidation as an example Option 4 and flight mode 206

So on one var we could store all the available functions on that channel, and there wouldn't be a parameters explosion :)

[peterbarker]

Are you suggesting we store 200.200.200.200.200.200.200.200.200.200 as a single parameter value somehow? I'm not sure how that would work. AFAICS that would require 10*8bits to store - and that's assuming an 8-bit option range which both tridge and I independently thought would be too limiting. Additionally, apart from bitmasks, I can't think of other places we split parameters for different values.

[lvale]

ok, so why 256 options are limiting ? I agree that the more the better, but considering the number we have today.....and unless we step up dramatically the number of options I don't see it as a problem in a couple of years. But if so then lets step it up to 65536 options (4bytes)? Considering only a 2 byte for each option and 10 possible options on one channel that would be 20 bytes per rc_channel.

[auturgy]

No reason to close. It’s a valid enhancement request.

[tarantulito]

No reason to close. It’s a valid enhancement request.

Having filled #14941 I fully agree. Simply opening the possibilities to 6, as for channel 5 (mode flight change), would permit (Ch7 RC7_OPTION as example): -Assing Ch7 to a two position switch as now (RC7_OPTION=33 (brake)), repeating on three ranges. -Assign Ch7 to a three position switch, repeating on two ranges: Low: nothing (0). Mid: brake (33). *High: motor emergency stop (31). Of course, in that order for this example. -Assign Ch7 to a mix of two two position switches (four functions), repeating, or a mix to a two and three position switches (six functions), done and operated very carefully.

To be modified: -Code. -Documentation. -GCS's.

One way for understanding and implementation is through a bidimensional matrix range/function. Example for 6 ranges (as flight mode change) and 128 functions: Function F0 F1 F2...F64...F127 Range 0 1...............x 2...................x..x
3...................x 4......................x 5...................x............x.......x So each range would have assigned a 128 bits value; if 1 the function is active (this permits simultaneous functions), and the concept can be extended in ranges and functions.

[peterbarker]

On Thu, 30 Jul 2020, tarantulito wrote:

Having filled #14941 I fully agree. Simply opening the possibilities to 6, as for channel 5 (mode flight change), would permit (Ch7 RC7_OPTION as example):

The flight mode channel is handled in a significantly different manner to channels on which we have other "auxillary functions" assigned.

Note that there's nothing magical about channel 5 - it's just the default on one of our vehicle types for changing modes. You can use any channel as your flight-mode-channel.

We kind-of-sort-of have a table similar to the "virtual 6 position switch" I outline elsewhere in this issue - those are the FLTMODE1, FLTMODE2 etc fields - it's just the options are limited to changing modes rather than arbitrary channel options.

One problem with the concept of a "virtual switch" is how to handle three-position switches. If it was just activating a boolean function - motor estop, for example - it would be relatively easy. But there are plenty of auxillary options that use the mid-position to mean something special.

-Assign Ch7 to a mix of two two position switches (four functions), repeating, or a mix to a two and three position switches (six functions), done and operated very carefully.

I do wonder at the need to convey so much information on a single RC channel - remembering that any option put onto such a channel has to be mutually exclusive from all the other options - you can't put landing gear and estop on the one RC channel as you do want to be able to operate them independently.

[rmackay9]

I'm also not a huge fan of the idea of combining auxiliary switches together and/or having more positions on a single switch. I think many new transmitters have huge numbers of switches and so I think it's a better idea for users who want a lot of features available to use one of these transmitters instead of trying to pack a ton of features onto a smaller number of switches.

I also think in general that the transmitter interface is quite limited and at some point to do really complicated things a ground station (like the HereLink) is a better way.

[tarantulito]

@peterbarker @rmackay9 : your comments and viewpoints are appreciated; read below.

@peterbarker

You can use any channel as your flight-mode-channel For examples above FLTMODE_CH=5, which I suppose is universal. BTW, not any: its possibilities are 5 to 8, so if you use a three channels radio (rover) and want Ch3 for mode change you need a receiver with separate pins, attach a multiplexer and connect receiver output 3 to multiplexer input 5: having the possibility of using a PPM receiver, component added, cabling added and less overall reliability.

...you can't put landing gear and estop on the one RC channel as you do want to be able to operate them independently. With the implementation above (matrix, bit mapped modes) on a three position switch you can assign: -Low: nothing. -Mid: landing gear. -High: landing gear and emergency stop. Or with a mix on two two position switches (Gray coding): 00: nothing. 01: landing gear. 11: landing gear and emergency stop. 10: emergency stop.

@rmackay9

...many new transmitters have huge numbers of switches... But not channels: a 7 channels transmitter may have many switches, but only channel 7 (if 6 is analog) for RC7_OPTION and so only one possible function. On the other hand, it should be documented that for using n options you need a 6+n channels radio, and a capable receiver.

...to do really complicated things a ground station (like the HereLink) is a better way. Even the ancient MultiWiiConf is better in these aspect: three pulse widths and simultaneous modes:

Cleanflight/Betaflight even better: permits modifying pulse width ranges:

About BEEPER in above figure: -RCx_OPTION doesn't include continuous beeping. When loosing the copter I wonder if there is something more natural than continuously changing modes on the transmitter. -On MP GCS, if assigning Brake (33) to RC7_OPTION "Mode changed to brake" is heard when activated, but if assigning Motor Emergency Stop (31) the motors stop but nothing is heard. -Unless I miss something, there is no MAVLink message for the flight controller requesting a continuous beep on the GCS, such as on a dangerous mode as Motor Emergency Stop. So as an example if something here were implemented, the copter is far away and accidentally Motor Emergency Stop is activated the GCS would remain silent.

@auturgy

No reason to close. It’s a valid enhancement request.

Replay: I completely agree.

[peterbarker]

You can use any channel as your flight-mode-channel For examples above FLTMODE_CH=5, which I suppose is universal. BTW, not any: its possibilities are 5 to 8,

You can believe that if you like - but it's documentation, and is usually the case, wrong. At least for Copter.

so if you use a three channels radio (rover) and want Ch3 for mode change you need a receiver with separate pins, attach a multiplexer and connect receiver output 3 to multiplexer input 5: having the possibility of using a PPM receiver, component added, cabling added and less overall reliability.

Huh. That sounds like fun. I wouldn't recommend it, however.

Or with a mix on two two position switches (Gray coding):

Problem with this is that mere mortals have to understand how it works. And not just that, be able to debug it when it all goes wrong.

...many new transmitters have huge numbers of switches... But not channels: a 7 channels transmitter may have many switches, but only channel 7 (if 6 is analog) for RC7_OPTION and so only one possible function.

I'm really not sure what you mean by "analog" here. I guess you're referring to channel-6-tuning?

There is actually a way to accomplish what you're trying to do without vast number of parameters; a relatively simple LUA script would be able to do what you're describing with relative ease.

[tarantulito]

@peterbarker You can believe that if you like... Long time ago, when beginning with a rover, I took that as absolutely true, so assembled the rover accordingly. I never tried FLTMODE_CH=3. I'll try: it implies a smaller PPM receiver, no multiplexer, less cabling and maintain reliability.

I'm really not sure what you mean by "analog" here. I refer to a Futaba 7C I use. It has a potentiometer for channel 6, which I use for gimbal pitch.

...a relatively simple LUA script... I'd appreciate a brief orientation or URL on this. I looked at LUA scripts for WS2812's. As an example, two two position switches mix controlling Ch7 (four pulse widths) to get: 00: nothing. 01: brake. 10 and11: emergency stop.

[tarantulito]

With a mix on two two position switches for Ch7, and a development version on a spare controller connected through USB: ArduCopter V4.1.0-dev (30c8d7bf) I tried:

function update()
  pwm7 = rc:get_pwm(7)
  gcs:send_text(0, "RCIN 7:" .. tostring(pwm7))
  if pwm7>500 then
    if pwm7>1800 then
        param:set('RC7_OPTION', 33)
    else
        if pwm7>1400 then
            param:set('RC7_OPTION', 31)
        else
            if pwm7>1200 then
                param:set('RC7_OPTION', 0)
            else
                param:set('RC7_OPTION', 31)
            end
        end
    end
  end
  return update, 500
end

return update()

(pwm7 = rc:get_pwm(7) seems to cause syntax error on beta and stable versions).

Pulling the USB cable and reconnecting, I find that RC7_OPTION starts with the chosen value on the radio switches, so this could be the way to go.

But, does above script write every 500ms on the µP eeprom memory?

[peterbarker]

But, does above script write every 500ms on the µP eeprom memory?

It won't cause writes - those values aren't written back to eeprom with set - you need set_and_save for that.

This isn't quite what I had in mind. I thought someone had added a method to trigger auxiliary functions directly from LUA - sadly, I can't see any binding to do that :-(

[tarantulito]

@peterbarker set ... set_and_save

Thanks. Experimenting on test bench with spare controller above script (with set) with the two two position switches mix for Ch7, transmitter on and off, on MP CONFIG-> Full Parameter Tree -> button "Refresh Params" -> pulling the USB cable (no supply to controller and receiver), etc, RC7_OPTION obeys to switches, but is not saved.

So if all this works, you could perhaps (???) have simultaneous options using aditionally an unused RCx_OPTION on a non existent channel:

function update()
  pwm7 = rc:get_pwm(7)
  gcs:send_text(0, "RCIN 7:" .. tostring(pwm7))
  if pwm7>500 then
    if pwm7>1800 then
        param:set('RC7_OPTION', 33)
        param:set('RC8_OPTION', 0)
    else
        if pwm7>1400 then
            param:set('RC7_OPTION', 31)
            param:set('RC8_OPTION', 0)
        else
            if pwm7>1200 then
                param:set('RC7_OPTION', 0)
                param:set('RC8_OPTION', 0)
            else
                param:set('RC7_OPTION', 31)
                param:set('RC8_OPTION', 18)
            end
        end
    end
  end
  return update, 500
end

return update()

(500 above should be 20 for emulating the common 50 Hz pulses transmitting rate). 0/0: nothing 33/0: brake 31/0: emergency stop 31/18: emergency stop and land with careful Gray encoding.

All that was for a development version (ArduCopter V4.1.0-dev (30c8d7b)). With the same script on latest beta: 05/08/2020 11:51:46 : Frame: QUAD 05/08/2020 11:51:46 : RCOut: PWM:1-12 05/08/2020 11:51:46 : fmuv3 003C002D 50485011 20323450 05/08/2020 11:51:46 : ChibiOS: d4fce84e 05/08/2020 11:51:46 : ArduCopter V4.0.4-rc3 (d70e75b3) 05/08/2020 11:51:45 : Lua: No scripts to run