ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

[Nav2] Speed Restriction Support Now Available

Hi all!

I am really glad to announce a new implementation of Costmap Filters which we have all been waiting for: Speed Filter.

Imagine, you are operating in a warehouse with different items laid out on the floor. In one corner you discover the boxes with crystal vases inside. You should become very careful and do everything twice as slow as you could to not spoil someone’s celebration. This is usually an awkward situation but not for you, if you are a robot with Speed Filter onboard.

In a previous post we became familiar with Keepout Zones - a filter implemented in Costmap Filters framework. Speed Filter – is another one. It automatically decreases the maximum allowed speed in speed restricting areas you marked on map. This speed restriction map (aka “filter mask”) – is a usual OccupancyGrid map. Information on it is being encoded as a color lightness. This information is being read and linearly converted into a speed limit value inside the Speed Filter plugin. Once the robot enters the speed limit area, the plugin sends a message to a Controller to change its maximum allowed speed in accordance to the pixel on the map where the robot places.

This is a spatial-dependent feature. Speed-restricting areas might not have a clear shape and even boundaries. You can draw any clear border or gradient shaped area and set any speed restriction value there you can presume!

There are two kinds of speed restriction may be:

  1. Speed limit expressed in a percent from maximum robot speed.
    This is good for single robot systems because of easy set-up (just set a % and go).
  2. Speed limit expressed in absolute values (e.g. in m/s).
    This is suitable for heterogeneous systems with different kinds of robots running simultaneously, each having its own maximum allowed speed.
    ← This type of restriction is waiting for your vote (details are in the next post below in this thread).

Here is a demo video showing how Speed Filter works in a small warehouse:

If you are ready to start using Speed Filters, here are some documentation references that will allow you to step it easily:

Still have questions? Please write to us in the Navigation2 Slack group. There’s a link to our Slack group in the Navigation2 readme.

Also, a Speed Filter detailed tutorial is coming soon!

Thanks to Steve @smac for his thorough review and wise guidance which finally allowed this feature to come out!

And happy speed-limiting,



As was mentioned above, the Speed Filter reads two types of speed restriction:

  1. Expressed in a percent from maximum allowed speed. This is good for single robot systems because of easy set-up (just set a % and go). But not suitable for tuning heterogeneous systems with different kinds of robots running simultaneously, because each robot might have its own maximum speed defined by its construction and vendor.
  2. Expressed in absolute value for all types of robots (e.g. speed limit 15 m/s) is intended to work with such systems.

For the last one we have an issue with absolute velocity encoding it with a filter mask. Let’s look into some background of the question:

In general case the speed of the robot is decomposed into two components - linear and angular velocity.

Apparently, if we are restricting the maximum linear velocity of a robot, we also should restrict its angular velocity as well, in order to keep safety. Robots can be different in type and shape, for example elongated robots or omni-directional drives. Angular speed restriction has a very important meaning for them.

Filter mask can encode only one value per cell.

For the first type of speed restriction expressed in a percent, there are no issues: we are decreasing both maximum linear and rotational components of velocity by the same percent taken from a filter mask.

For the second type of speed restriction (expressed in absolute values), there is a question: which type of maximum velocity should we set in a filter mask (say 15): linear (max 15 m/s), angular (max 15 rad/s) or both?

What do you think about it all?
Is this a big deal to have speed limits in absolute value or is this something we can just pass over? Is this even useful for you guys?

Here I see two possible solutions how to use absolute values in Speed Filter:

Solution #1:

Encode maximum linear velocity in a filter mask. Then restrict maximum angular velocity in the same proportion as it was changed for maximum linear velocity.

For example, a robot has 100 m/s max linear velocity and 20 rad/s max angular velocity allowed by its construction. Robot enters in a speed restriction area having 15 m/s speed restriction. This means, that maximum linear velocity will be restricted by this value, and maximum angular velocity by ( 15m/s / 100m/s ) * 20rad/s = 3rad/s. This will be a restriction of maximum angular velocity for this robot.

This solution is similar to restricting the speed in a percent value approach, but it is suitable for heterogeneous systems, where we have different kinds of robots.

Solution #2:

Despite the first solution being suitable for heterogeneous systems, it detracts from the generality: we might want to set-up by component linear and angular speed restriction for some specific area and does not depend on the robot’s architectural limits. This problem might be solved by running two Speed Filters simultaneously: one tuned for linear velocity restriction, another – for angular. This will resolve the problem, but system setup in this case might be quite heavy to catch without any specific tooling.

Which one do you see is better to have?
You are also welcoming to propose another approach for absolute values here!

Looking forward to your opinions.



This is awesome! We actually have implemented something similar in ROS1.

For us it is important that the same trajectories can be followed. So an absolute reduction in linear velocity should allow for exactly the same curvatures to be followed.

You can image that a maximum linear and maximum angular velocity results in a minimal circle to be traveled at max speed. So the reduction for the angular velocity should be such that this is results in the same minimal circle.

So in short: Solution #1: