Add Fixedwing path following as a separate controller state

[Jaeyoung-Lim]

Solved Problem

This PR adds an additional FW path navigation state, which uses position, tangent and optionally curvature to do path tracking.

Currently this was done by overriding control_auto_position, but since it is using more of the derivative setpoints, we thought it should be separated out as a separate mode

The behavior is as the following.
In offboard,

• When velocity setpoints are available set FW state as FW_POSCTRL_MODE_AUTO_PATH
• When only position setpoints are available, set FW state as FW_POSCTRL_MODE_AUTO, which would end up using control_auto_position

Fixes #{Github issue ID}

Test coverage

• Tested in SITL Gazebo
  • with normal mission mode
  • with offboard path tracking

Additional Context

• Offboard seems to be also completely broken, so fixed it along the way

[sfuhrer]

I agree on the separating it into the new control_auto_path() method (as opposed to control_auto_position()). Let's just be very careful with the state machine, that one is hard to see through anymore.

[Jaeyoung-Lim]

@sfuhrer Rebased and tested with ROS2: https://review.px4.io/plot_app?log=3e50cfeb-ffb5-41fa-9fab-ad5b797207c8

I agree on the separating it into the new control_auto_path() method (as opposed to control_auto_position()). Let's just be very careful with the state machine, that one is hard to see through anymore.

Fully agreed, the logic is no longer tractable. I think we should try to hash out the global variables so we can unit test the conditions.Should we revisit #21382 ?

Also, would be great if we can finally get rid of pos_sp_triplets 😄

[Jaeyoung-Lim]

@sfuhrer I don't think the CI failure is related to this PR (happening on a multirotor)

[sfuhrer]

Yes, lets get this in and move on to your next one!

[sfuhrer]

Also, would be great if we can finally get rid of pos_sp_triplets

What of the triplets is annoying you most? Maybe we can find a way iteratively work towards a better interface. Eg we can starve out PositionSetpoint further, until we can completely delete it.

[Jaeyoung-Lim]

What of the triplets is annoying you most? Maybe we can find a way iteratively work towards a better interface. Eg we can starve out PositionSetpoint further, until we can completely delete it.

@sfuhrer For me it seems like a superset of all the information we need downstream, and a lot of the information is actually unused or not properly populated, depending on the state of the controller.