Steep altitude change when manually changing current mission item

[mlaiacker]

Hi, if you change the active waypoint in Mission mode in fixed wing (not tested in copter) it will fly in a nice straight xy line to the new waypoint but will change the altitude as fast as possible towards the altitude of the newly selected waypoint instead of continuously changing the altitude.

The same happens when activating mission mode from any other mode, the plane will try to reach the altitude as fast as possible.

Is this intended behaviour? Why?

Describe problem solved by the proposed feature This is dangerous when flying in mountains where it could be safe to fly in a 3D line to the selected waypoint but not go down as fast as possible.

Describe your preferred solution Use the current position as the start of the 3D line towards the selected waypoint. I guess this can be changed in: void Mission::on_activation() bool Mission::set_current_mission_index(uint16_t index)

Additional context Simulated with v1.10.1 and make px4_sitl gazebo_standard_vtol https://logs.px4.io/plot_app?log=d91a8471-41fc-4593-81a3-7c31d9230297

[sfuhrer]

Hi @mlaiacker , I think this behavior is intended, yes. With a fixed-wing you usually want to fly as much as possible in level flight, and not be continuously climbing/descending. Because level flight should be the state that's optimized for most range/flight time. Nevertheless, I see your point, that in hilly terrain where you want to perform some sort of terrain tracking, a straight line tracking also between altitude setpoints would be cool. Maybe we could add another altitude tracking flight mode for it? Would you be interested in looking into how to implement it?

[mlaiacker]

I have implemented a solution where where it will do line tracking in mission mode when switching to mission mode or change the active waypoint. It will allays do it like that. Maybe it could be enabled by (yet another) parameter.

[sfuhrer]

Cool, feel free to make a PR if you'd like to upstream it!

[stale[bot]]

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

[sfuhrer]

@mlaiacker We actually already have a first-order hold altitude following for fixed-wing. I guess it was broken when you tested it, it looks correct now: https://review.px4.io/plot_app?log=656df6c4-acec-43c8-bfa5-9b8b5ae90c7f

Related RP that got in a couple of months ago: https://github.com/PX4/PX4-Autopilot/pull/15677

[mlaiacker]

Thanks for the update.

So it is fixed in master and also in stable 1.11.3?

I think I tested it again with 1.11 but was still changing the altitude as fast as allowed and then continue on the waypoint altitude.

It happens when you fly for example from waypoint 2 -> 3 and between these waypoints enable, for example, waypoint 5 that is far away and at a different altitude.

[sfuhrer]

So it is fixed in master and also in stable 1.11.3?

I quickly tested it, and it looks correct when the normal mission order is kept, but not if you change the current index. Same for master. Any chance you'd have time to look into it?

[mlaiacker]

@sfuhrer What can I do?

I submitted a pull request that should fix this issue when changing the current index. That's what this issue is all about.

[sfuhrer]

@mlaiacker I had a look. The reason it (first order hold climb) doesn't work with "Set Waypoints" is that in this case, the previous waypoint is invalid, and thus the altitude setpoint is immediately adjusted to the new waypoint altitude. https://github.com/PX4/PX4-Autopilot/blob/f13c3a7d44c58f69c77f9e4f82cf3d6a41ec9551/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp#L788

A similar thing actually also happens for multicopter: on selecting a waypoint with a different altitude, the vehicle stops moving horizontally and climbs/descends vertically to the new altitude. If we want to change the behavior than I guess we should do it on a Navigator level such that it's consistent for MC and FW flight. Personally I'm not that sure what's the better UX, to have the vehicle follow the FOH altitude ramp from current altitude to the altitude of the newly selected one, or to climb to the new altitude immediately. @mlaiacker Can you give an example for which mission scenario it would be clearly better to use the FOH ramp when switching waypoints?

[mlaiacker]

Hi @sfuhrer, I gave an example in the original issue description:

"This is dangerous when flying in mountains where it could be safe to fly in a 3D line to the selected waypoint but not go down as fast as possible."

This of-cause mostly apply to BVLOS missions over not flat terrain. For example you plan a longer mission up a slope and at some point you decide to abort the mission and go back to the beginning of your landing approach. The UAV would probably go strait down into terrain. I think the same would happen if you activate return home with a "land start" marker. Lets say you fly at a constant altitude above ground level of about 100m but your ground altitude increases by more than 100m along your mission if you now select a mission waypoint close to the start point it will fly into terrain when its not flying in a 3D line back to that lower waypoint. I also think it is more efficient to decent slowly with a fixed wing than as fast as possible and convert all that potential energy into drag and then continue at constant altitude.

I fixed this by setting the previous waypoint valid and to the current UAV position in mission mode. This works fine but maybe there is a better solution.

Climbing is no problem most of the time. The only problem could be airspace restrictions that only allow you to fly at max AGL but no collision risk.

[sfuhrer]

Thanks for the detailed explanations @mlaiacker . In general I think I agree with you that a 3D line also when changing WP is the better default state - I would though also say that when flying in hilly terrain, changing the execution order of the planned waypoints in general sounds quite dangerous, and I would rather recommend to fly manually/with "GoTo" and "Set Altitude" to the position where you want to continue the mission.

. I think the same would happen if you activate return home with a "land start" marker.

No actually RTL is a different case. It will not descend to the land marker altitude, but keep the current until it has reached the landing start (ofc, it could be an issue if one is currently flying lower than the mission landing, but that's pretty clear from the RTL description in my eyes.)

@dagar how easy do feel it would be to make the changes in Navigator to pass a valid previous_pos_sp (e.g. the current position of the vehicle) when doing a "change mission item"? Do you see another issue coming if we'd do it like that?