# What general assumptions (if any) does Nav2d make about Twist rate and robot behavior?

Hi, I'm using nav2d together with google cartographer in order to do SLAM + autonomous navigation. I see that by default (correct me if I'm wrong) nav2d produces Twist messages at a rate of several messages per second.

This appears to me to be a very high rate, so I'm guessing this assumes the robot will execute whatever is indicated by the Twist message for a very small amount of time (smaller than the rate at which Twist messages arrive) and then come to a stop. In this way, if the robot receives 10 Twist messages in one second telling it to move let's say x=1.0, then it would move along x at speed 1 for 1 second (by effectively having moved 10 clicks of 100 ms each).

Is my understanding correct? The reason I ask is that a cannot grasp how to process this great amount of Twist messages unless the robot executes them faster than they arrive. Maybe related to that, I've seen that a general approach for autonomous robots is for them to be at a full stop by default, as a security measure (so in case communication is lost or something else happens, the robot would immediately stop), I don't know if this notion comes into play here too.

Thanks!

edit retag close merge delete

Sort by » oldest newest most voted

tl;dr: geometry_msgs/Twist encodes velocity, not position. There is no quantum of motion (ie: no particular distance is expected per Twist) and any "safety" included by the controller/driver (ie: command timeout) is nice, but not part of the semantics of geometry_msgs/Twist.

Navigation stacks typically use Twist messages to provide setpoints to lower-level controllers that will make the robot attain the velocities encoded in them. These setpoints are generated as part of the position control feedback loop closed by nav_msgs/Odom (or TF) and which produces velocity commands.

The entity running the position controller (fi a local planner, or something else) would be responsible for sending appropriate velocity setpoints to make the robot reach the desired location (or pose).

Almost all local planners in the nav stack (and nav2d is similar afaik) implement something like a velocity-based feedback control loop to control base platform position (ie: 2D (2.5) or 3D pose of the robot in some reference frame).

geometry_msgs/Twist does not encode something like a "unit of movement", but velocities. Both linear and angular.

The nav stack uses this message to continuously provide setpoints to the entity that is supposed to make your robot move based on those setpoints. So there is no quantum of distance that it expects as behaviour. The local planners will try to drive the base platform towards the pose they have been given (by a global planner or something else) by computing appropriate geometry_msgs/Twist messages which are then published.

nav_msgs/Odom (or TF) is used to close the loop (ie: to provide information on where the robot actually is, compared to where it needs to go).

What general assumptions (if any) does Nav2d make about Twist rate and robot behavior?

I would say that the assumption is for a consumer of Twist messages to exist and for something (not necessarily that same consumer directly, but it would be a typical setup) to cause a corresponding motion of the base platform (ie: if the planner / controller requests a linear velocity of 1m/s to be attained along the X-axis, that is actually what happens).

Implicitly there is probably also the assumption of low latency between the publisher and subscriber, and a reasonably accurate 'execution' of these velocity commands (if this is not true, you'll generally observe unstable behaviour (ie: robot oscillating, not reaching its goal position, etc)).

I see that by default (correct me if I'm wrong) nav2d produces Twist messages at a rate of several messages per second. This appears to me to be a very high rate [..]

for a(n) (on-line) control system "several times a second" is actually not very high at all. It all depends on the dynamics of the robot: small and/or lightweight robots tend to be able to "move fast", so they can better track incoming setpoints, larger and/or heavy robots (with lots of inertia) tend to need some time to catch up with a velocity setpoint, so they will not ...

more

Thanks for your thorough answer @gvdhoorn! I think I need to check how my firmware is interpreting velocity commands, and also what you said about Twist encoding setpoints and not having to wait the velocity to actually reach it.

( 2020-01-06 15:34:38 -0500 )edit