Switch from nav_msgs/Path to trajectory_msgs/JointTrajectory

[zal-jlange]

This PR changes to published message from nav_msgs/Path to trajectory_msgs/JointTrajectory.
Using the trajectory_msgs/JointTrajectory message, not only the calculated positions, but also the velocities, accelerations, as well as jerks can be published.
However, the jerks are published as effort.

Moreover, using trajectory_msgs/JointTrajectory, we are no longer limited to three axis.
Further work could then move the initial and waypoint subscribers from nav_msgs/Odometry messages to sensor_msgs/JointState and fully eliminate the limit for three axis.

[gavanderhoorn]

Could perhaps be nice to consider cartesian_control_msgs?

CartesianTrajectoryPoint does have a jerk field.

[zal-jlange]

The problem with cartesian_control_msgs/CartesianTrajectory and the included cartesian_control_msgs/CartesianTrajectoryPoint is, that they only support three components.
This will make it harder later on to re-design the node to accept any number of joints.

We could, however, design our own message, based on trajectory_msgs/JointTrajectoryPoint and simply rename effort to jerk.
But this could create other problems, as it wouldn't be a "standard", easy-to-install message and might make it harder for others to adopt TopiCo.

I think the best way forward (at least for now) is to use trajectory_msgs/JointTrajectory and make it clear, for example in the README.md, that we misuse the effort field for the jerk.

[gavanderhoorn]

The problem with cartesian_control_msgs/CartesianTrajectory and the included cartesian_control_msgs/CartesianTrajectoryPoint is, that they only support three components.

I wouldn't call that a problem really: it's a message intended for communication of Cartesian trajectories.

Afaik, TopiCo can be used for Cartesian trajectories as well. It would seem appropriate to offer a correctly typed interface for such uses, and CartesianTrajectory seems like it would improve on nav_msgs/Path.

The proposed changes seem to remove the Cartesian interface that's currently there and "downgrade" it to a joint-space interface (which is what use of JointTrajectory implies). In the end it's all a vector of numbers of course, but perhaps adding a JointTrajectory interface instead of removing the Cartesian one would be a nicer addition.

Alternatively: remove the typed interface alltogether and use a Float64MultiArray. Horrible semantics, but it does seem to fit: a vector of vectors.

[zal-jlange]

Well sounds like we should design a new message all together.
Maybe something like:

topico_msgs/Trajectory:

std_msgs/Header header
topico_msgs/TrajectoryPoint[] points

and corresponding topico_msgs/TrajectoryPoint:

float64[] positions
float64[] velocities
float64[] accelerations
float64[] jerks
duration time_from_start

That way we can conserve one of TopiCos awesome features, namely:

Trajectories for an arbitrary number of axes are generated simultaneously

[MariusBeul]

Thank you for the contributions!
I opted against a custom message since it can not be easily visualized in RVIZ. Nevertheless I personally use two custom messages to represent a trajectory:

Trajectory.msg:

Header header
TrajectoryAxis[] Axis

TrajectoryAxis.msg:

float64 P_init
float64 V_init
float64 A_init
float64[16] t
float64[16] J

The start time of the trajectory is encoded in the header while the arrays t and J represent durations of constant jerk starting from P_init, V_init and A_init. This representation exploits that trajectories are composed of up to 16 segments with constant jerk and is very lightweight. From this representation, position, velocity, and acceleration timeseries with arbitrary resolution can be easily derived. It also does not limit the maximum number of axes...