High speed (~2+m/s) demo

[SteveMacenski]

I don't have personal experience working with higher speed robots, most of the things I've worked on are operating in human filled spaces where kids and other people jump in front of robots for fun.

It would be great to analyze the stack and determine if its capable of running at higher speeds (2m/s or more), and if not, what are the technologies that need to change to support it. I think the first thing to look at would be the controllers and see if DWB or TEB is suitable for higher speeds, or seeing if other techniques we should consider. I think that is the weakest link for this type of demo. Maybe @DLu can shine some light if DWB is suitable for those speeds in his experience.

Further, looking at the parameters for perception required (costmap size, update rates, etc). The planner should probably be fine as is, maybe replanning a little faster.

I imagine for this to be functionally safe, we need a lidar-based safety controller to limit speed before collisions, but for now, assume that its in an environment without people (or people that are trained not to do stupid things like jumping in front of robots at full speed). This is something that is vendor specific to meet relevant safety standards so lets just assume that this is BYO for the demo and we can consider this when we have something functionally working otherwise.

[DLu]

My bots don't go that fast, but my naive assumption is that the limit is the speed of computation. If you can go 2m/s with a big enough computer, I believe DWB should work.

[SteveMacenski]

Got it, thanks for the note that helps. Weird things start to happen at higher speeds, but I don't think that DWB relies on a strong enough model of robot dynamics to actually be effected by it. Also while 2 m/s is "fast" relative to indoor, the issues I'm thinking of are mostly applicable at car speeds so maybe even 2 m/s is sufficiently slow to be fine.

Any relative scale of maximum speeds you know of DWB being used at? (0.5 m/s, 1 m/s, 1.5 m/s)

[mikeferguson]

I can say from experience, I've had robots running ROS1 navigation with DWA go 2.0 m/s without too much work. You do typically need to retune some things (usually sim_time has to get longer, which skews a bunch of other parameters). The real trick is tuning the controller so that it supports BOTH 2.0m/s and slower speeds that are inevitably needed.

[SteveMacenski]

Awesome, that's really helpful insight. Well, the way I designed the servers also helps with that problem quite a bit; you can have a high speed and a low speed DWB controller plugin to use in the behavior tree. We allow for multiple planner or controller plugins to be loaded in the servers at any time and called as required.

Knowing that now, I can more easily put together a demo. The goal here was just to show it could do it and fix any issues involved in getting there (which I thought I'd run into). Maybe its actually just a given and I didn't know this just trivially works.

[soldierofhell]

We did a project with vehicle of size compared to large SUV with double Ackermann steering with TEB / SBPL Lattice combo in ROS1. Worked like a charm :)

[SteveMacenski]

I think the big action item is to just put together a demo of this in ROS2. I don't think any development is required

[harderthan]

We did a project with vehicle of size compared to large SUV with double Ackermann steering with TEB / SBPL Lattice combo in ROS1. Worked like a charm :)

Hello, @soldierofhell .
I'm interested in your project. Could you share more information to showing up?
I'm looking for some reference about robot projects included high speed controller and ROS.

[soldierofhell]

Hi @harderthan, unfortunatelly I can't say much of technical details cause it's proprietary project. But you can sense about the size of the platform from footage and materials publictly available like https://www.milmag.eu/news/view?news_id=4611. If you google, you'll find probably also some videos, but they may not be from autonomous driving

[SteveMacenski]

@harderthan the aim of this project is to show navigation2 working with a robot traveling at high speeds using our algorithms. Then write up a page for the website around configuring your robot to do that (whatever parameters need to be updated to enable it; max speeds, update rates, etc). If any issues show up, communicating those so we can work to resolve them.

[wt160]

Hi, I wonder whether such configuration page is available as of now. Currently, in simulation, for DWB controller, when I set the max_vel_x to be 2m/s, the output from DWB will always below the limit for a lot (0.6m/s). I wonder whether there are any params that need to be tuned. Thanks!

[synaptic]

I, too, am seeing limits around 0.6-0.7 m/s when I set max_vel_x to 1.5. (Note that the controller is selecting lower cmd_vel.linear.x values but allows cmd_vel.angular.z to reach the full value of the max_vel_theta.) @wt160 Check that you are using the right launch argument for the parameter file, which the person in this issue had. I verified I am using the right argument since inside the trajectory iterator it is evaluating speeds all the way up to 1.5 m/s. The source of the issue seems to be coming from the critics which are giving higher speeds larger scores than lower speeds. For example critic GoalDist scores twist.x of 0.552632 at 1.0 (raw), whereas twist.x of 1.50 at 31.0. Both had the same twist.theta at 0.0. This doesn't make logical sense since the goal is still quite a ways off from the current machine pose, and the robot heading is pointed towards it. A higher velocity should put the last evaluated pose closer to the goal, not further.

@SteveMacenski Do you have any suggestions for how to troubleshoot this? Bear in mind that in my setup I am not using SLAM as discussed in this ROS discourse post.

[synaptic]

@wt160 I found the source of my trouble. My cloned copy of navigation2 predated the fix made in #2185. Therefore shorten_transformed_plan was hard-coded to true, even when I set it to false in nav_params.yaml as documented here. By setting it to false, I was able to see higher speeds.

[SteveMacenski]

That is probably due to an inappropriately sized local costmap for those speeds - but yes that could solve the issue. Remember to set the X speed and the controller XY speeds as well as the costmap having the sim time / costmap size to make that happen

That param is used in main, are you refering to it not working in foxy? https://github.com/ros-planning/navigation2/blob/30b405c58e6d53ba8c96381416bc4679d35a1483/nav2_dwb_controller/dwb_core/src/dwb_local_planner.cpp#L490

[synaptic]

Yes, I increased the size of my local costmap accordingly (I think 13x13 meters). But since I was using an older version of foxy-devel branch, it did not have that fix you linked to (made in #2188). My bad, as I should have thought to pull the changes / improvements that have been made since I cloned in early February.

[SteveMacenski]

To be released in coming weeks