Plane: Enable SET_POSITION_TARGET_LOCAL_NED behaviors for QuadPlane in GUIDED Mode while in VTOL/Hover

[StephenCarlson]

Feature request

Is your feature request related to a problem? Please describe.

I am using ArduPlane on a Tricopter/TiltRotor VTOL. My team and I are trying to make an automated aerial docking system using a companion computer to do the vision and higher-level decisions, which then uses a MavLink wrapper such as MAVROS or MAVProxy to command the vehicle using the SET_POSITION_TARGET_LOCAL_NED message. We've attempted this in SITL simulation using RealFlight, and it appears that only vertical altitude changes are available at the moment, along with hovering waypoints with Q_GUIDED_MODE enabled. We've studied the behavior in the Copter flight stack using the RealFlight QuadcopterX model, and that configuration does respond to SET_POSITION_TARGET_LOCAL_NED messages.

Describe the solution you'd like

We would like to have the QuadPlane respond to MavLink set position messages such that we can drive the position, velocity, acceleration and yaw fields in the same combination as is available in the Copter firmware. In particular, we desire that the yaw/heading is preserved while the aircraft tilts in whatever direction vector is commanded. For our docking scheme, a pair of VTOLs would need to point the exact same heading while the pursuant/active vehicle is issued commands for a 3D velocity (which would be renewed faster than the apparent 1 second timeout for when velocity is reset to zeros), or commands for a 3D position. In our particular case, these commands would be for the local body NED FRD frame, but the MavLink message also has options for other frames of reference.

It is noted that this behavior is likely to enable other similar tasks, such as the precision landing of a QuadPlane upon an AprilTag or other fiducial marker.

The relevant starting points in the Copter and Plane code bases are as follows:

• Copter
• Plane

Describe alternatives you've considered

We've considered "spamming" the hovering waypoint mechanism that currently exists for QuadPlane, but this would basically be a hack, and would not allow for control of aircraft yaw. We've also considered using the Lua scripting API to issue the equivalent command, but this also suffers the same issue in that the functionality simply does not exist for QuadPlane, and the binding would likely not do anything.

Platform [ ] All [ ] AntennaTracker [ ] Copter [x] Plane [ ] Rover [ ] Submarine

Additional context

On 22 January 2022, I posted in the Discord quadplane_vtol channel the following text, repeated here for completeness:

It appears that QuadPlane does not respond to position, velocity or posvel MAVProxy commands when hovering in GUIDED mode. My desire is to have the hovering vehicle respond to these commands in the same manner as Copter, which allows for local NED position and velocity commands. For completeness, it appears that mavlink messages SET_POSITION_TARGET_LOCAL_NED and SET_POSITION_TARGET_GLOBAL_INT have no effect, but altitude changes requests are effective on Quadplane. I'm wading through code starting near https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/quadplane.cpp#L3326 , but I'm guessing someone here already knows the answer/reason.

I've simulated the QuadcopterX in RealFlight, and we basically want the same functionality, wherein the SET_POSITION_TARGET_LOCAL_NED message can be sent with various masked portions. An important detail: Studying the behavior of the QuadcopterX model in RealFlight, it seems that by default, if only the position and velocity fields are passed (yaw fields are masked), the vehicle proceeds to point in the direction of motion, which is undesired in this case, as we want to have our aircraft maintain yaw heading while having them shuffle to the left or right such that the wingtips will dock. With the QuadcopterX example, this sidways shuffle is achieved when the yaw fields are also enabled (not masked), resulting in the quad drifting sideways or backward while maintaining original heading.

I would imagine that there are other groups that would be interested in this functionality; has anyone tried to have a QuadPlane land on an AprilTag yet? What is the best way to directly control the position and velocity of a hovering QuadPlane at the moment? Thank you.

Similar Issues:

19462 - Observation that the Yaw is changed if the yaw fields are masked in the Mavlink message.

[nitigit]

Hello @rmackay9 @StephenCarlson Has there been an update on this issue? I am using ArduPlane and need features similar to the ones described above. I am using MAVROS to communicate from a Companion Computer to achieve precision landing in a VTOL, but the functionality is very limited in ArduPlane. The algorithm created is (only) working with Copter using MAVROS, so any updates on this enhancement would greatly help.

[Pratiquea]

Hi @nitigit, @StephenCarlson and I have an implementation with the older version of the ArduPlane that allows us to set position setpoints while in quadplane mode. However, to do so, I had to disable the part of the code that allows guided operations for fixed-wing mode, essentially forcing the vehicle to stay in quadplane mode. If I can get some help understanding the different transitions or the logic that guides the transitions from @rmackay9, I can modify the code accordingly and create a pull request.

[rmackay9]

Hi @Pratiquea, @nitigit,

I'm probably not qualified to comment on how the Plane code should be changed, I'm really only familiar with the other vehicles (Copter, Rover, etc). I think @IamPete1 and @tridge are probably better devs to talk to on this.

[StephenCarlson]

@nitigit While it looks like the mention might not have gotten the attention of the proper parties, can we setup a way to show our implementation to you?

[nitigit]

Thanks for the replies, @Pratiquea @StephenCarlson and @rmackay9. While waiting for @IamPete1 and @tridge, I think looking at your implementation will definitely be helpful for the team on my side to come up with some inspiration to properly use a companion computer to send ArduPlane commands for our purpose. We can possibly meet virtually, we can confirm the timings once I discuss it with my team too.

[nitigit]

Thanks for the replies, @Pratiquea @StephenCarlson and @rmackay9. While waiting for @IamPete1 and @tridge, I think looking at your implementation will definitely be helpful for the team on my side to come up with some inspiration to properly use a companion computer to send ArduPlane commands for our purpose. We can possibly meet virtually, we can confirm the timings once I discuss it with my team too.

Hello @Pratiquea and @StephenCarlson, are you open to a virtual meeting?

[StephenCarlson]

@nitigit Sorry we dropped off, lets try to plan this. We are Pacific time zone (Reno), when is good? Any workday should do. -Steve