# Independently change angular and linear velocities (cmd_vel)

Hi people!

This is really an easy question for the experts: I am coding some roslisp/cram functions where I would like to change independently the angular and linear velocity of my robot in parallel threads. I first used the usual way of publishing the velocity in roslisp roslisp:advertise "/cmd_vel" "geometry_msgs/Twist" but then I realised that when publishing an angular velocity (roslisp:publish-msg (roslisp:advertise "/cmd_vel" "geometry_msgs/Twist") pub (z angular)) I would reset the linear speed to zero and the converse when publishing a linear speed.

Is there any [easy] way to modify the angular and linear velocity of the robot independently from one another in simultaneous processes?

The only solution I have is any time I want to modify only one component of the velocity is to read the current velocity and publish the values of the changed component together with the values that are not change. That is not ideal as with parallel threads changing simultaneously the same topic I might have problems.

Hey, thanks a lot.

edit retag close merge delete

Sort by » oldest newest most voted

At the end I chose to create a global queue where any velocity command (usually coming from different threads) is stored before being executed. The velocity commands are sequentially executed by dequeuing — the next velocity command is applied only when the previous is checked to be effective. In this way, each velocity commands can independently change rotational or linear velocity by reading the current values of the unchanged velocity component and resending them with the new full velocity command (i.e. rotational+linear).

You may comment about how elegant or efficient this solution is. I am sure it can be bettered, but at the moment, with only two agents, works ok.

Sorry for delayed answer post. I was busy. And thanks @StefanKohlbrecher for nice suggestions.

more

The standard convention for controllers in the ROS ecosystem is to receive a full geometry_msgs/Twist message and use that to generate actuator commands. There is no standard way of selecting only some fields of the message as valid, while others are ignored. Your suggestion of forwarding velocities via messages between threads indeed sounds troublesome, as various race-conditions could result.

I see some viable approaches, for all some changes in the controller receiving the commands are required:

• Use geometry_msgs/Twist, set all values you don´t want to set to NaN. Your controller would check for that and only update it´s internals using only the non-NaN fields. Note that this could results in some disastrous results when sending to a controller that does not honor this "ignore NaN" convention.
• Use separate topics for angular and linear velocities (if you only send linear x, a std_msgs/Float64 would be an obvious choice for example). This requires the addition of a few new subscribers in your controller
• Wrap geomety_msgs/Twist in a new message that contains additional fields that select which fields are valid and should be used

That´s my ideas, maybe others have others to offer? :)

more