Copter: Trust get-pilot-desired methods check RC input for validity

[peterbarker]

.... which they do, for the most part.

This PR removes special-case logic in Loiter and ZigZag which check for radio failsafe before updating the loiter controller with values returned from them (etc.).

Those methods already check that RC input is good (improvements coming there, however!). So rely on those methods returning sensible values when there's no RC present. Several other modes already make the assumption that these methods do sensible things (eg. ModeAltHold!).

Note that clear_pilot_desired_acceleration just sets (0, 0), and get_pilot_desired_lean_angles sets target-roll/target-pitch to zero if RC input is bad).

There is a second fix in here where checks were insufficient when looking at RC values. This is the update_simple_mode method matches. We not only have to check that a new frame has been received, but that the values are generally good ie. not coming in at bind-mode values. This is a minimal patch to allow for the first patch to go in - there's plenty else wrong in the radio codepath which will be fixed in a future PR (eg. incorporating bind-time values into the throttle filter, setting the throttle-zero flag). This is also a bugfix for several methods which already transform the pilot inputs. - this was moved to a different PR

[rmackay9]

LGTM, thanks.

The only function change is in update_simple_mode() which doesn't directly check the failsafe.radio boolean but instead checks the ap.new_radio_frame. So this is a slight change in behaviour in that the RC roll and pitch values could be updated now when they weren't before. I think there could only be an issue if the failsafe cleared without ap.new_radio_frame becoming true. It's slightly hard to imagine how this could happen and how it could cause a problem

[peterbarker]

LGTM, thanks.

The only function change is in update_simple_mode() which doesn't directly check the failsafe.radio boolean but instead checks the ap.new_radio_frame. So this is a slight change in behaviour in that the RC roll and pitch values could be updated now when they weren't before. I think there could only be an issue if the failsafe cleared without ap.new_radio_frame becoming true. It's slightly hard to imagine how this could happen and how it could cause a problem

Yes, quite right - but we're already calling that method in similar circumstances. And it should be fixed by #30071 :-)

[lthall]

This is a good change.