Bezier trajectory avoidance interface

[jkflying]

Describe problem solved by this pull request
Currently the avoidance interface only allows specifying single position setpoints. This PR enables sending time-parameterized Bezier messages, allowing smooth flight control from the companion computer while in auto modes.

Describe your solution
Several parts:

1. A simple 5-line function to calculate a position given an N-order bezier curve and the current T value, templated on the type of number that is used
2. Use of Dual numbers to calculate the velocity (and even acceleration), from the above simple function, without needing complex formulae for each curve size.
3. Parsing of the bezier mavlink message, and translation into uORB
4. Subscribe to the uORB, and if the newly introduced bezier message has a valid duration, use that to determine the current position and velocity indicated by the bezier curve
5. Pass these values on using the existing avoidance setpoint injection

Additionally, in order to save FMUv2 flash space, this PR moves the avoidance to a separate library and excludes it from CONSTRAINED_FLASH builds, replacing it with a dummy implementation. Thanks to @julianoes for the pointer with CONSTRAINED_FLASH - I think this is sufficient for now, but longer term I'd like to be able to do something like this via the board configuration similar to modules. @dagar any ideas on a good way to make this easy for the future, since I don't think this way scales? I'm sure there are other libraries that we'd like to replace with dummies for constrained flash builds, which can't be easily hoisted out into modules.

Describe possible alternatives
It might be better for this to not go through the smooth velocity interface, if it is shown that the companion can provide smooth enough curves, and rather send the data directly to the position controller.

Test data / coverage
Extensively unit tested. However there isn't yet a planner which can send the bezier messages, so this hasn't been flight or SITL tested.

FYI @Stifael , since you did some earlier Bezier work.

[hamishwillee]

@jkflying Can you update https://docs.px4.io/master/en/computer_vision/path_planning_interface.html to reflect this addition?

Specifically we might need to rename https://docs.px4.io/master/en/computer_vision/path_planning_interface.html#trajectory-interface to "Trajectory Waypoint Interface" and put a peer heading "Trajectory Bezier Interface".

First question that pops into my mind is what happens if PX4 receives streams of both types. Also when should you use one or the other etc.

[jkflying]

@hamishwillee will do once this is closer to merging.

At the moment, if there is a point from the 'old' interface, it uses that instead of the bezier curve data. Bezier curve is if you have some kind of motion planner which is aware of vehicle dynamics, then it allows you to get smoother flight performance, with simultaneously less bandwidth on the serial link. The 'old' interface is slightly easier to understand/use, and already has support of Avoidance/MAVROS. However it was never fully implemented to allow following multiple setpoints, which effectively the new bezier curve implementation does.

[hamishwillee]

@jkflying Thanks very much. Let me know if you need help when you're ready to doc.

FWIW So what I think you're saying that you use either the waypoint OR the bezier interface (ie if you send a waypoint message it would supersede the last bezier message (and visa versa)).

I understand the bezier provides you smoother paths with less data, possibly covering multiple waypoints, and that the waypoint interface only covers one waypoint at a time currently.

[jkflying]

The other way I thought of for excluding the library doesn't work, so it will have to be something like this for now.

Details: I thought about putting all the calls to the library inside of an if which had a static false in the builds I wanted to exclude. But there are still other dependencies, eg parameter updates and uOrb subscriptions inside, so the linker doesn't exclude it. Using a dummy class seems to be the way forward, even if not ideal.

[hamishwillee]

@jkflying So docs? :-)

Will need update to https://docs.px4.io/master/en/computer_vision/path_planning_interface.html

Probably need update to https://docs.px4.io/master/en/computer_vision/obstacle_avoidance.html#mission-progression

[jkflying]

PR on the user guide added: PX4/PX4-user_guide#680 . It's a bit rough - sorry, I'm in a rush here 😅 I don't think there's much more that can be added without a working planner on the other side capable of sending the Bezier curves as well.