Plane: allow for different orientations for landing rangefinder

[tridge]

this is principally for tailsitters where rangefinders would be orientation with RNGFND1_ORIENT=12 (PITCH_180), but also allows for custom orientations which will be useful if the rangefinder is tilted forward

Tested in SITL using the quadplane-copter_tailsitter frame

[IamPete1]

I do have a PR for this #20074 (it does need a rebase). That automatically selects the rangefinder closest to down for the current attitude. The potential problem there is that it will switch in flight.

Would the new set HAGL command work here too? It just seems a bit mad that we need a parameter to tell us which way down is. In the longer term I would like to use all rangefinders all the time using a average with weighting bases on how close to down they are.

[tridge]

I do have a PR for this #20074 (it does need a rebase). That automatically selects the rangefinder closest to down for the current attitude. The potential problem there is that it will switch in flight.

it also doesn't support custom orientations which I think will be useful on some vehicles. The switching in flight issue I think is a real problem, especially with the code we have for starting the use of a rangefinder.
We could use the HAGL method, but I think the parameter is warranted as tailsitters become more common. In the future we could support value -1 for "automatic", but that just complicates things for now

[IamPete1]

Note that the rangefinder orient param does not list custom 1 and custom 2 as valid values.

[IamPete1]

In fact it also gives 4: Back. Here you have 12: Back. One is ROTATION_YAW_180 and the other ROTATION_PITCH_180. For a rangefinder it amounts to the same, but this should match the rangefinder params so selecting "Back" for both works as expected.

[tridge]

the problem with using YAW_180 is the special handling of the yaw values in Aircraft::perpendicular_distance_to_rangefinder_surface() in SITL - YAW_180 is assumed to be a proximity sensor, so if you use YAW_180 you can't test in SITL
Using YAW_180 will work on a real aircraft, just not SITL

[tridge]

@peterbarker looks like you added the special handling for the YAW values in SIM_Aircraft::perpendicular_distance_to_rangefinder_surface() ? does it really need to be that way or can we have some other way to hack in the proximity sensors?

[IamPete1]

The problem is that the GCS may just give a drop down not the value, so if the user selects "Back" both this and the rangefinder orient it won't work. Maybe you could add "SITL back", or just don't have that case in the values, its not in the values for rangefinder either.

[tridge]

unless we change that hack in SITL then we can't use YAW180 and make it testable in SITL
we could make the AP_RangeFinder library use pitch180 instead?

[IamPete1]

I'm only talking about the @values, the two "Backs" must be the same (4). You can still use a value that is not listed for in SITL and it should work fine. You were already having to set a value not in the @Values for the rangefinder, you will just have to do that too for the new param.

[tridge]

we can change the meaning of "Back" in the rangefinder library to be 12, but I'd like to discuss that on the call
or we could rename "4: Back" to "4: Back(Yaw180)" in the rangefinder library and add "12: Back" there

[peterbarker]

LGTM

[IamPete1]

Just need to change the default, looks good apart from that.

fixed

[IamPete1]

Looks good.

[peterbarker]

Whoops. Killed the Rover RangeFinder test - we also use those posts in Europe to test Rover's horizontalk rangefinder, and that seems to be busted.

[tridge]

Killed the Rover RangeFinder test - we also use those posts in Europe to test Rover's horizontalk rangefinder, and that seems to be busted.

I've fixed it up