search

ros / common_msgs

Commonly used messages in ROS. Includes messages for actions (actionlib_msgs), diagnostics (diagnostic_msgs), geometric primitives (geometry_msgs), robot navigation (nav_msgs), and common sensors (sensor_msgs), such as laser range finders, cameras, point clouds.
http://wiki.ros.org/common_msgs
177 stars 191 forks source link

add Jerk message to the geometry_msgs #137

Open hakuturu583 opened 5 years ago

hakuturu583 commented 5 years ago

I want to describe jerk in geometry_msgs. However, there is an acceleration message, but there are no jerk message. So, I want to add message for jerk.

tfoote commented 5 years ago

This would be something that could use a standardized message to capture. It would likely be the same datastructure as the Twist but with different semantic meaning. Could you make a proposal and show it in use in practice? Before we promote it into a common message it's preferred to have actual demonstrated use cases. For example the Twist has a challenge that there ambiguity between reference point and frame vs the observational frame and the body frame.

This has caused things like transformTwist implementations to be removed due to ambiguity. These should be considered and resolved in this proposed message and likely an evolution of Twist can take up the same changes.

More info:

gavanderhoorn commented 4 years ago

I don't have a solution for the problems described with Twist, but I would like to second the proposal to add a Jerk message to geometry_msgs.

This came up in a discussion around a new message (set) for Cartesian trajectories in a ROSIN FTP and it'd be really nice if we could avoid introducing a custom message for this.

As you write @tfoote: it'd essentially be a copy of Twist but with changed semantics.

Showing usage is difficult, as in our research it doesn't seem many ROS (ros_) control interfaces consider jerk, which is something we're trying to address.

@fmauch @jonbinney

fmauch commented 4 years ago

Uh, that notification slipped through my mails...

As @gavanderhoorn wrote we are currently working on a Cartesian trajectory interface proposal where jerk definitions in waypoints came up in a discussion.

As this is a pure interface definition where controllers could be built upon, this doesn't provide a real world use case, but a "potential" use case which IMHO does make sense to tackle.