is there a 'normal' range used for geometry_msgs::Twist values?

answered 2016-11-19 12:36:14 -0600

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2016-11-19 12:37:00 -0600

Is there a standard / normal range used for the X, Y, & Z values of the linear and angular members of the Twist message?

tl;dr: I would say "no", as geometry_msgs/Twist interfaces are not supposed to work like that (they have different semantics).

Longer: Twist messages encode a linear and angular velocity relative to some reference frame. As everything in ROS that deals with 'real-world things', they are expected to follow REP-103, meaning: m/s for linear velocities and rad/s for angular velocities. For geometry_msgs/Twist, that is all expressed in the receiver's local frame. For geometry_msgs/TwistStamped, the header field contains a target frame specification.

So a standard range wouldn't make much sense, at this semantic level.

Saturation at this level does make sense, and would be something basic I would include in all Twist-compatible drivers.

I plan to support scaling but would like the default behavior to follow normal conventions and reduce the effort for users of my node.

Not sure this is what you mean, but nodes like teleop_twist_joy support configurable scaling of output velocities (see the scale_linear and scale_angular parameters. These nodes are responsible for scaling input values (coming from joysticks fi) to the acceptable range of linear and angular velocities for a particular driver/platform, then output those. The contract between the Twist publisher and the subscriber is then such that the publisher is responsible for publishing appropriate commands.

PS: the ros_controllers packages include a diff_drive_controller that you may use for inspiration / something to compare your implementation against. It too implements a geometry_msgs/Twist interface.

edit flag offensive delete link

Comments

thanks.

My confusion is mostly being a noob. The various turtlesim tutorials were not explicit (or I missed the details) about what was happening and it appeared the example was using the vector3 as a generic speed value rather than as a true velocity.

suforeman ( 2016-11-19 13:07:14 -0600 )edit

I was further confused when I had previously read the diff_drive_controller. When it said "The controller works with a velocity twist from which it extracts the x component of the linear velocity and the z component of the angular velocity." I missed the latter reference to "units of measure".

suforeman ( 2016-11-19 13:09:05 -0600 )edit

Unless otherwise stated, a good assumption to make is that everything that accepts Vectors, Twists, etc will always use SI units. In fact: if you find something that does not conform to this, you should regard it a problem, as it would violate the (implicit) contract.

gvdhoorn ( 2016-11-19 13:30:38 -0600 )edit

The controller works with a velocity twist from which it extracts the x component of the linear velocity and the z component of the angular velocity

This just means that diff_drive_controller will only consider linear velocities along X, and angular velocities along Z axes. It ignores the rest.

gvdhoorn ( 2016-11-19 13:31:18 -0600 )edit

Btw: if you have the chance, try and make your controller ros_control compatible. As soon as you have a hardware_interface implemented for your hw, you can re-use all of the rest of the infrastructure and controllers. Something like diff_drive_controller saves you a lot of work.

gvdhoorn ( 2016-11-19 13:32:50 -0600 )edit

long long term, it may be possible to make the code ros_control compliant. I have only been coding ROS for 5 days and this node is for controlling basic analog RC servos using PWM. The target audience is high school students building small project robots for education and competition.

suforeman ( 2016-11-19 13:57:29 -0600 )edit

Ok. Some reference material for the future: Dave's ros_control_boilerplate, a Dynamixel hardware_interface example: resibots/dynamixel_control_hw.

gvdhoorn ( 2016-11-20 00:58:50 -0600 )edit

Btw: if you feel this question has been answered, could I ask you to mark it as such by ticking the checkbox to the left of the answer? That will clearly show the question as answered when looking at the question listing.

Thanks.

gvdhoorn ( 2016-11-20 01:00:55 -0600 )edit

see more comments

is there a 'normal' range used for geometry_msgs::Twist values?

1 Answer

Comments

Question Tools

Stats

Related questions

is there a 'normal' range used for geometry_msgs::Twist values? edit

1 Answer

Comments

Question Tools

Stats

Related questions

is there a 'normal' range used for geometry_msgs::Twist values?