Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Jerk message to the geometry_msgs #137

Open
hakuturu583 opened this issue Nov 26, 2018 · 3 comments
Open

add Jerk message to the geometry_msgs #137

hakuturu583 opened this issue Nov 26, 2018 · 3 comments

Comments

@hakuturu583
Copy link

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
Copy link
Member

tfoote commented Nov 28, 2018

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
Copy link

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
Copy link

fmauch commented May 26, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants