The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
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.
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.
| | 2 | No.2 Revision |
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.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.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
