(Quadplane) Back Transition Improvements

Hi everyone,

We are unhappy about three things of our back transitions:

  1. It takes too long.
    We are using the Generic AAVVT v-tail plane airframe with Quad VTOL airframe (13007), which doesn’t support pusher thrust inversion. (Corresponding mixer file: https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/mixers/vtol_AAVVT.aux.mix) Is there a reason for that, other than it has just not been done? I could create a PR copy-pasting the corresponding lines from the Deltaquad mixer.

  2. When using a VTOL transition command, the drone flies back to the waypoint where the transition was triggered. (https://github.com/PX4/Firmware/blob/ca0b5700ab0ba6dd2c088564dc13988af27d3263/src/modules/navigator/mission.cpp#L997-L1019)
    Why was this code added? We don’t see any benefit in this behaviour. If the drone overshoots, it flies back only to fly forward afterwards. Surely there must be some use for it though, otherwise it wouldn’t have been added in the first place.
    We would like the drone to continue to the next waypoint after the transition command. If this is in favour with most people, I can also create a PR.

  3. One of the reasons why we don’t use the VTOL Transition & Land command is that the pusher gets disabled when landing. (https://github.com/PX4/Firmware/blob/ca0b5700ab0ba6dd2c088564dc13988af27d3263/src/modules/vtol_att_control/standard.cpp#L342-L346)
    Flying in high winds without pusher assist has already almost cost us a drone on a previous flight when the drone couldn’t advance against the wind. We understand that for drones with no feet it’s not a good idea to have the pusher spinning when touching the ground. Our preferred solution would be to keep the pusher active above MPC_LAND_ALT2 or similar. What do you think of this?
    A simpler alternative would be to add a parameter to activate/deactivate the pusher on landing.

We would be glad to know your thoughts on our ideas :slight_smile:

Hi @TSt,
All very valid points!

  1. No reason that some frames don’t have it. Would be cool if you could add it to the generic VTOL frame types!
  2. I will look into more detail into the specific lines you mention. I agree that the backtransition should be made smoother, and more robust to external disturbances/bad mission planning. Would be cool if you would find a way to improve the behaviour - we need to make sure though that every change doesn’t break other stuff. With the current implementation of Navigator you can never be too sure about this, so if you find stuff to simplify/refactor in it that would also be awesome!
  3. This excact same adaption to pusher support as you speak about is also something that I had wanted to implement since some time but didn’t get to it. A PR for it would be most welcome/I’ll gladly support you on it!

Hi @sfuhrer,

Thanks for your response!

  1. I will soon have time to do it, I’ll post the link to the PR here.

  2. Here’s a log where I deactivated the above-mentioned lines: https://logs.px4.io/plot_app?log=230ad8b1-b8d4-4d0c-bfc0-eb31e47b2e0f
    It’s hard to see the change “live” in SITL, and also not easy on the flight review plots, but in plot juggler / looking at the csv files you see when it changes to the next waypoint:
    image
    To compare, this is when it doesn’t advance the mission (current master):
    image
    Note the plateau during the transition and that it’s still on WP 18 afterwards.

Since the corresponding lines only get called when executing a back transition command in a mission (not VTOL and Land), I wouldn’t know what else it could screw up in the navigator. And from the SITL log it works as expected when deleting these lines. But better safe than sorry, I appreciate if you look into the code.

  1. I feel like there are a few tricky bits to be considered for a proper implementation. For VTOLs without enough clearance for the pusher propeller you need to be sure that at the moment of touching the ground the pusher is deactivated in all landing situations, including emergency landings on top of a hill, for example. Or simply landing at a different spot than take off. If no altitude above ground measurement is available, MPC_LAND_ALT2 is with respect to home altitude if I’m not mistaken. If you land on something that is higher than MPC_LAND_ALT2 wrt home, you risk having the pusher activated unless you add some specific conditions for all these cases. I unfortunately don’t have time for a proper implementation, let alone testing all cases on a real drone. (I need to finish my master thesis within a month and afterwards I’m travelling for 5 months :D)

2: The idea is that the VTOL_TAKEOFF is considered either just a takeoff with transition, or also the first waypoint. If you set it away from your home point you must set it far enough for the vehicle to perform the transition withing the distance set. It is never a good idea to drift from the planned path.

3: Pusher assist during landing can make your vehicle very unstable as lift would be generated from the wings. You will be pushed down when pitching forward and that should be fine during descent. If this would be changed i would recommend to base it on a parameter.

Hi @sanderux,

2: I was talking about using a VTOL Transition command attached to a normal waypoint to initiate a back transition. It may not be the usual way for most people to perform a back transition, but there are good reasons why in some cases you’d want to use it. Depending on the landing area (for instance if the final landing destination is in a constrained space), you might prefer to transition to MC where you have enough space and do the last bit of precise navigation in MC mode. Or one might prefer to keep the pusher activated for the first part of the descent. Which leads us to point 3 :wink:

3: What do you mean by very unstable? That you hit mixer saturation / airmode because of the generated lift, with oscillations that follow? That the descent becomes painfully slow? That the land detector shortly sets throttle to 0 mid-air? We’ve seen all of them :sweat_smile: But nothing was quite as scary as seeing the drone being pushed back and unable to recover its desired horizontal position. I don’t pretend to have the perfect solution (if there even is such a thing) and I understand that it’s not clear which of the problems is the worst. But I think we should at least allow the user to make the choice.