For a ROS2 offboard computer looking control the autopilot, there are a variety of methods.
From a high level, it could be waypoint-based, feeding waypoints and letting the autopilot figure out how to get to them.
Other control methods (acceleration, rate) control are lower level, and require more real time behavior offboard. Pending some performance metrics that need to be completed, design the generic API for ROS2 to control ardupilot.
ROS REP-147 exposes a good set of messages, but they don't have any feedback on success of commands, or progress indications.
Since the DDS interface doesn't support services or actions (yet), this ticket can be scoped on the open loop control.
Leonard's talk on guided mode is an excellent primer: https://www.youtube.com/live/4G1sxQ_CVng?feature=share&t=11204
He proposes the ideal method is to control position, velocity, and acceleration at the same time. Since ardupilot has some sense of the vehicle limits with respect to WP_NAV params, and these limits are fixed at runtime on copter usually, they can be sent to the companion computer once (on boot). Later, when dynamics are more variable, such as accounting for drag with respect to velocity, or throttling the climb rate based on battery sag, the dynamics can be shared dynamically. For some more info on how to apply the acceleration limits, see this: ros-navigation/navigation2#2633
Once the companion computer has the vehicle limits, it will need to take its global plan, and smooth it. For a 2D smoother, see here:
https://navigation.ros.org/configuration/packages/configuring-constrained-smoother.html
The companion computer should publish PVA commands as fast as reasonably possible, even 10Hz, with the current requested command (timestamped). There is not currently any look ahead support. Since ArduCopter supports S-Curves, there is currently no need to send an entire trajectory. S-curves attempt to minimize cross track error in 3D.
For a ROS2 offboard computer looking control the autopilot, there are a variety of methods.
From a high level, it could be waypoint-based, feeding waypoints and letting the autopilot figure out how to get to them.
Other control methods (acceleration, rate) control are lower level, and require more real time behavior offboard. Pending some performance metrics that need to be completed, design the generic API for ROS2 to control ardupilot.
ROS REP-147 exposes a good set of messages, but they don't have any feedback on success of commands, or progress indications.
Since the DDS interface doesn't support services or actions (yet), this ticket can be scoped on the open loop control.
Leonard's talk on guided mode is an excellent primer: https://www.youtube.com/live/4G1sxQ_CVng?feature=share&t=11204
He proposes the ideal method is to control position, velocity, and acceleration at the same time. Since ardupilot has some sense of the vehicle limits with respect to WP_NAV params, and these limits are fixed at runtime on copter usually, they can be sent to the companion computer once (on boot). Later, when dynamics are more variable, such as accounting for drag with respect to velocity, or throttling the climb rate based on battery sag, the dynamics can be shared dynamically. For some more info on how to apply the acceleration limits, see this: ros-navigation/navigation2#2633
Once the companion computer has the vehicle limits, it will need to take its global plan, and smooth it. For a 2D smoother, see here:
https://navigation.ros.org/configuration/packages/configuring-constrained-smoother.html
The companion computer should publish PVA commands as fast as reasonably possible, even 10Hz, with the current requested command (timestamped). There is not currently any look ahead support. Since ArduCopter supports S-Curves, there is currently no need to send an entire trajectory. S-curves attempt to minimize cross track error in 3D.