This isn't an exhaustive list of channels used for auxillary input, so
that makes this wrong.
RC_Channel goes off the raw get_radio_in values, so setting these is a
pointless and potentially confusing state change.
Also, Plane and Rover don't do this - so things are more consistent
after this.
this stops us using uninitialised values in modes like circle which
can operate either with or without RC input. If we didn't have a RC
receiver attached then they would use a maximum yaw rate (which
produces quite a spectacular result for a tuned up racing quad)
this implements what betaflight calls 'air-mode'. This gives attitude
control when throttle is at zero, allowing for zero-throttle maneuvers,
plus keeping the copter level on the ground.
This was already implemented if an interlock switch was setup, but it
should also work with an arming switch. If using an arming switch then
throttle should not be considered zero as long as the arming switch
hasn't gone low.
when H_SV_MAN=1 we do direct pass-thru so the user can test swash
range. The problem is that it uses norm_input() for throttle, which
depends on RC3_TRIM. Nowhere else in heli or copter do we depend on
RC3_TRIM, so the user gets a misleading idea of behaviour when testing
their swash.
Copter-3.5 testing resulted in a significant number of users reporting various issues like poshold and autotune were not functioning because their RC inputs were straying out of the deadzones
Pixracer boards can take 1 second (or possibly longer) to start reading RC input. This ensure we see the user's high throttle to indicate the user wants to perform the ESC calibration
Further to refactor of RC_Channel class which included
adding get_xx set_xx methods, change reads and writes to the public members
to calls to get and set functionsss
old public member(int16_t) get function -> int16_t set function (int16_t)
(expression where c is an object of type RC_Channel)
c.radio_in c.get_radio_in() c.set_radio_in(v)
c.control_in c.get_control_in() c.set_control_in(v)
c.servo_out c.get_servo_out() c.set_servo_out(v)
c.pwm_out c.get_pwm_out() // use existing
c.radio_out c.get_radio_out() c.set_radio_out(v)
c.radio_max c.get_radio_max() c.set_radio_max(v)
c.radio_min c.get_radio_min() c.set_radio_min(v)
c.radio_trim c.get_radio_trim() c.set_radio_trim(v);
c.min_max_configured() // return true if min and max are configured
Because data members of RC_Channels are now private and so cannot be written directly
some overloads are provided in the Plane classes to provide the old functionality
new overload Plane::stick_mix_channel(RC_Channel *channel)
which forwards to the previously existing
void stick_mix_channel(RC_Channel *channel, int16_t &servo_out);
new overload Plane::channel_output_mixer(Rc_Channel* , RC_Channel*)const
which forwards to
(uint8_t mixing_type, int16_t & chan1, int16_t & chan2)const;
Rename functions
RC_Channel_aux::set_radio_trim(Aux_servo_function_t function)
to RC_Channel_aux::set_trim_to_radio_in_for(Aux_servo_function_t function)
RC_Channel_aux::set_servo_out(Aux_servo_function_t function, int16_t value)
to RC_Channel_aux::set_servo_out_for(Aux_servo_function_t function, int16_t value)
Rationale:
RC_Channel is a complicated class, which combines
several functionalities dealing with stick inputs
in pwm and logical units, logical and actual actuator
outputs, unit conversion etc, etc
The intent of this PR is to clarify existing use of
the class. At the basic level it should now be possible
to grep all places where private variable is set by
searching for the set_xx function.
(The wider purpose is to provide a more generic and
logically simpler method of output mixing. This is a small step)