MAV_CMD_NAV_VTOL_TAKEOFF: Heading not considered

[sfuhrer]

Describe the bug
The MAV_CMD_NAV_VTOL_TAKEOFF message has a field the specifies the heading of the transition:

As far as I can say, this heading setpoint is currently not considered during the transition on the firmware side.

It would also be nice to improve the UX in QGC about the transition direction (e.g. be able to select 'Heading from home to VTOL_TAKEOFF waypoint'). I will create an issue there as well.

To Reproduce
Plan a mission in QGC with a VTOL_takeoff. Set heading of this waypoint to some value (not sure though if this actually sets the correct field in the MAV_CMD_NAV_VTOL_TAKEOFF)

Expected behavior
I would expect that after the vehicle has reached transition altitude, it waits with the transition till the heading specified is reached before starting the transition. It should then fly in fixed-wing to the VTOL_TAKEOFF waypoint.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[hamishwillee]

This looks very relevant. Was it fixed as part of #12630?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[dayjaby]

@sfuhrer Any update on this? On master this issue still persists.

[sfuhrer]

@sfuhrer Any update on this? On master this issue still persists.

Yes still persists, though not something I consider too high on my priorities currently.
When you plan a mission in QGC with a VTOL takeoff wp (which is the default first mission item for VTOL) then the direction of the transition (in the GUI) shouldn't anyway be set (maybe we should even think about removing the option there).

[hamishwillee]

@sfuhrer Is this something that @dayjaby or someone else could reasonably implement themselves? PRs welcome :-)

[sfuhrer]

@sfuhrer Is this something that @dayjaby or someone else could reasonably implement themselves? PRs welcome :-)

I'd say so yes! You mean now disabling the "set heading" option in QGC, or to enable the heading set there to be consumed by PX4? For the 2nd option some changes in Navigator would be necessary, around here:
https://github.com/PX4/Firmware/blob/18754225c93ee18c76c227cc66f687835e4a0046/src/modules/navigator/mission.cpp#L979

[hamishwillee]

@mrpollo I recall you were putting together a team of community members who could help with development. This might be something for someone in the team to consider.

[dayjaby]

I am only interested to have the yaw aligned to the next waypoint correctly, without any artificial waypoints before the transition.

I achieved good results by setting the mission_item yaw to 0.0f in https://github.com/PX4/Firmware/blob/18754225c93ee18c76c227cc66f687835e4a0046/src/modules/navigator/mission.cpp#L770 and looking currently why it doesn't work with the calculated heading.

Update:
I logged the positions in line 770 and got this result for a mission with VTOL TAKEOFF, WAYPOINT, WAYPOINT (the vtol takeoff is positioned directly on top of the drone):

PX4_INFO("Lat: %.5f, long: %.5f -> Lat: %.5f, long: %.5f", (double) _navigator->get_global_position()->lat, (double) _navigator->get_global_position()->lon, (double) _mission_item.lat, (double) _mission_item.lon);

INFO [navigator] Lat: 53.54490, long: 10.00780 -> Lat: 53.54490, long: 10.00780

The yaw calculation should take the next waypoint into consideration, shouldn't it?

[sfuhrer]

@dayjaby it will do the transition into direction of the VTOL_TAKEOFF wp, so if you place it right above your takeoff point then you probably will have some quite random transition direction. The logic unfortunately currently isn't smart enough to chose the first wp after VTOL_TAKEOFF for the direction if the the distance to the VTOL_TAKEOFF is to short.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[hamishwillee]

This still a problem @sfuhrer ?

[sfuhrer]

I think it would be rather a "nice to have" than a problem - unless you want to point out that we're not fully mavlink-spec compatible as we don't listen to the VTOL_TRANSITION_HEADING param of MAV_CMD_NAV_VTOL_TAKEOFF, but always do it in direction of the next waypoint. The current behavior is okay for me atm (I want to keep it as simple as possible for the user), and I thus have not a big intention to work on anything else.
Therefore we should rather close this issue, unless somebody else wants to pick it up.

[hamishwillee]

Hi @sfuhrer
Thanks for coming back to this. FWIW

1. We're not mavlink compatible because of this, but with upcoming improvements to MAVLink at least we will be able to report the specific incompatibility. Don't see this as a major issue.
2. I presume the reason this exists is that it makes a difference what direction you are facing when you transition? E.g. this would allow you to transition "into the wind" for example. Is that not useful?
3. It is indeed simple :-).

If you're not going to fix, add wontfix and close :-)

Then review PX4/PX4-user_guide#747 which captures this :-)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[Hylke-Atmos]

@hamishwillee (and @sfuhrer) please do not close this ticket, since I personally see two problems here.

1. As (currently) stated in the documentation: "the heading to the next waypoint is used for the transition heading". This means if the next waypoint is "with the wind", the transition will not be done in the wind and might cause some funny (maybe even dangerous?) behavior (in particular when the vehicle is facing the wind and has its next waypoint behind it), right (also take non-standard tail sitters in mind)!?

2. This might be less of a problem, but more of an inconsistency/inconvenience. We are creating a customized ground control system using MavLink, which (as specified by MavLink) is also doing a validation check (low level hash) between the uploaded flight plan and the returned flight plan. This check is currently failing because the (optional) value is simply ignored and therefor not send back on a mission list request.

Although the second problem is debatable whether it should or shouldn't send information back that is not used, it is breaking the Mavlink specifications! In particular in QGC it isn't even detected that it is ignored, since QGC does not execute a validation check after upload.