roslaunch diffbot_navigation diffbot_hw.launch

[questrov]

SLAM seems to be working OK, drive around the office and make a map, nice! Next issue on the learning curve, Navigation:-/

Saved map as described Navigating and Mapping on the real ROBOT with,

rosrun map_server map_saver -f office

ROS puts the new map in catkin_ws root. I can click on the map in files, it open in a viewer and see the new map. I then perform the next step which is,

roslaunch diffbot_navigation diffbot_hw.launch

but it opens the office map in ~/diffbot_navigation/maps. So, replace both office.pgm and office.yaml files with the new ones and it opens the new map. First tried an argument pointing to the new map but didn't work, for example,

roslaunch diffbot_navigation diffbot_navigation.launch map:=/home/ubuntu/catkin_ws/office

actually opens one of the other maps in ~/diffbot_navigation/maps. So, need to figure out the args where to save and where to load...

Ignoring that for the moment, launching roslaunch diffbot_navigation diffbot_hw.launch with either the new or old office pgm and yaml warnings and info come up as:

process[map_server-1]: started with pid [123320]
process[amcl-2]: started with pid [123321]
process[move_base-3]: started with pid [123322]
process[rviz-4]: started with pid [123327]
[ WARN] [1642883018.302478166]: Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: canTransform: target_frame map does not exist.. canTransform returned after 0.100572 timeout was 0.1.
[ WARN] [1642883018.839862476]: global_costmap: Pre-Hydro parameter "static_map" unused since "plugins" is provided
[ WARN] [1642883018.840372407]: global_costmap: Pre-Hydro parameter "map_type" unused since "plugins" is provided
[ INFO] [1642883018.841561831]: global_costmap: Using plugin "static_layer"
[ INFO] [1642883018.850270297]: Requesting the map...
[ INFO] [1642883019.155940267]: Resizing costmap to 1984 X 1984 at 0.010000 m/pix
[ INFO] [1642883019.253567834]: Received a 1984 X 1984 map at 0.010000 m/pix
[ INFO] [1642883019.256368206]: global_costmap: Using plugin "obstacle_layer"
[ INFO] [1642883019.262157560]:     Subscribed to Topics: scan
[ INFO] [1642883019.338268445]: global_costmap: Using plugin "inflation_layer"
[ WARN] [1642883019.384759352]: local_costmap: Pre-Hydro parameter "static_map" unused since "plugins" is provided
[ WARN] [1642883019.385274552]: local_costmap: Pre-Hydro parameter "map_type" unused since "plugins" is provided
[ INFO] [1642883019.386273669]: local_costmap: Using plugin "obstacle_layer"
[ INFO] [1642883019.393691098]:     Subscribed to Topics: scan
[ INFO] [1642883019.415209406]: local_costmap: Using plugin "inflation_layer"
[ INFO] [1642883019.504735855]: Created local_planner dwa_local_planner/DWAPlannerROS
[ INFO] [1642883019.507297938]: Sim period is set to 0.10
[ INFO] [1642883019.653442481]: Recovery behavior will clear layer 'obstacles'
[ INFO] [1642883019.658738220]: Recovery behavior will clear layer 'obstacles'
[ INFO] [1642883019.740624421]: odom received!
[ WARN] [1642883054.669520336]: Map update loop missed its desired rate of 10.0000Hz... the loop actually took 0.1058 seconds
[ WARN] [1642883055.286653252]: Map update loop missed its desired rate of 10.0000Hz... the loop actually took 0.1230 seconds
[ WARN] [1642883055.567498211]: Map update loop missed its desired rate of 10.0000Hz... the loop actually took 0.1038 seconds
[ WARN] [1642883071.273946530]: Map update loop missed its desired rate of 10.0000Hz... the loop actually took 0.1102 seconds`

If I do nothing after awhile get the warning,

[ WARN] [1642883451.171877288]: Map update loop missed its desired rate of 10.0000Hz... the loop actually took 0.1082 seconds

When I try 2D Nav Goal with either old or new office .pgm and .yaml we get the following errors reapeatedly:

[ERROR] [1642883546.619612964]: Global Frame: odom Plan Frame size 120: map

[ WARN] [1642883546.619658102]: Could not transform the global plan to the frame of the controller
[ERROR] [1642883546.619702350]: Could not get local plan
[ INFO] [1642883546.719496702]: Got new plan
[ERROR] [1642883546.819454740]: Extrapolation Error: Lookup would require extrapolation -0.073074413s into the future.  Requested time 1642883546.743963242 but the latest data is at time 1642883546.670888901, when looking up transform from frame [odom] to frame [map]

So close, literally the last ROS CLI in DiffBot README.md!!!

[fjp]

The parameter for the map file is map_file (not map). You should also distinguish between simulation and the real robot setup. For simulation you should also provide the appropriate value for the world_name argument (matching simulated world to your mapped map).

For navigation on the real robot you just need to provide the map_file:=/absolute/path/to/your/map.yaml argument to diffbot_hw.launch. For example:

roslaunch diffbot_navigation diffbot_hw.launch map_file:=/home/fjp/git/ros_ws/map/map.yaml

Also make sure that you have a more or less accurate map of your environment (obtained from the SLAM algorithm). Otherwise you won't be able to localize correctly. This is the first step I always do after RViz launches with the map file. One of my first videos shows the navigation process after you saved your map. I hope it might be helpful.

[ WARN] [1642883451.171877288]: Map update loop missed its desired rate of 10.0000Hz... the loop actually took 0.1082 seconds

I didn't encounter this issue so far (at least I didn't notice). If it doesn't happen too frequently I wouldn't bother, otherwise you might have to tune some parameters or get a faster hardware. According to this answer you should lower the resolution of your map. For this you should adapt gmapping node. Specifically the detla parameter. For diffbot it is here in the diffbot_slam package.

Please let me know if the errors keep happening after you saved a clean map of your environment. There might be some other issue, e.g., updated ROS packages, maybe network issues (slow data transfer), etc.

So close, literally the last ROS CLI in DiffBot README.md!!!

As you noticed, there shouldn't be much missing until you can navigate your robot autonomously to a goal location :-)

[questrov]

Actually it’s pretty much the same kinematically as it was before as the left and right motors are wired in parallel or “skid steer” mode. I believe the Clearpath Robotics Husky and Jackal listed on the diff_drive_controller page are similar setup. The only change was remove the castor and install the 2 motors, the controller is the same and drives both left/right motors in parallel on each side as if they were one.

It actually gets better odometerey in skid steer mode as it doesn’t have to drag the castor so there is no wheel slip especially if you use teleport twist keyboard for control as it turns the one set of wheels forward and the other backward for a turn opposed to rqt robot steering which turns only one set of wheels and drags the other. Check out this video for a better explanation.

In any case the errors are the same before/after the mod as I tested it at least 6 times in a small rectangular area surrounded by cardboard to make an ‘easy’ map. I also made the area smaller but still rectangular and only drove the robot forward/backward to make a map. The navigation errors as listed above are instant when a simple forward only 2d Nav is selected in rviz so something is not quite right…

[fjp]

You are correct, I forgot that the diff_drive_controller can handle four (actuated) wheels as well. Sorry for this confusion. You specify it with the skid_steer config, basically providing all the names of your four wheels:

left_wheel: ['front_left_wheel', 'rear_left_wheel']
right_wheel: ['front_right_wheel', 'rear_right_wheel']

And yes I agree, in case you don't have all of them actuated (still only two) you are good to go with the diff_drive_controller. One more thing I would like to point out, in case you haven't done it already, is to model your robot correctly in URDF. Otherwise the transforms might be a bit off. Also please note the wheel radius and wheel base distances in the diff_drive_controller configuration yaml file.

However, I now also think the issue isn't related to what I pointed out previously and it shouldn't matter if you haven't modeled your robot precisely. After some researching for this error it can either be something of the following:

• Time sync problems on workstation and RPi
• Slow CPU
• Parameter settings (e.g. laser scan frequency, amcl transform_tolerance, ...)
• ...

My guess is that the parameter settings were tuned for a quite powerful hardware. I am pretty sure, commit 9e15559 introduced the issue you are experiencing. In this commit I tuned amcl for simulation but didn't test thoroughly on the real hardware afterwards. I would suggest adapting these values (especially transform_tolerance from 0.1 back to 0.5) until you get rid of the error. If I find time I will try to change these too and find a good mix between simulation and hardware. Would be interesting if changing these values can solve your issues. And thanks for reporting your results so far!

Here is the link to amcl parameters and what transform_tolerance is doing:

~transform_tolerance (double, default: 0.1 seconds)
Time with which to post-date the transform that is published, to indicate that this transform is valid into the future.

[questrov]

Perfect @fjp thanks for the pointers, no pun intended! It does seems like parameter settings just wasn’t sure where to start tweaking, now I have a clue:-/ Have been doing some light reading too, oh so much to learn! Nice having the hardware to play with along the way and thanks again for the continued support.

[questrov]

That did the trick!

transform_tolerance from 0.1 back to 0.5

Still some yellow warnings but no more red errors:-) Perfect in straight line, OK in an arc 2D Nav Goal but it's still a bit confused doing a turn and eventually aborts.

Need to update the parameters as you suggest in particular skid steer, needs to pivot (turn one wheel set forward, the other backward) opposed to drag (one wheel set only forward) update URDF, wheel radius, distance, etc.

My hardware is not optimal either, an old NUC for the workstation and Pi4 is only 2GB although it's on it's own Wi-Fi AP the local network router is busy with lots of devices and working pretty hard. Need to get the laptop out and update it's ROS on a dedicated LAN and see what happens...

Is there a way to manually abort the 2d Nav Goal without ctl-C the navigation node? Poked around a bit but have not figured it out yet; would be nice while tweaking/tuning...

Thanks again for the support, think we're basically there finally or at least another major milestone on the learning curve! Also need to go back thru the pertinent ROS tutorials (there are so many!) and and details on your site, they are at least starting to make sense now:-/

[fjp]

Glad to hear this helped to reduce the errors. What are the warnings you are still receiving? And is there an error/warning before the plan to a goal is aborted?

Need to update the parameters as you suggest in particular skid steer, needs to pivot (turn one wheel set forward, the other backward) opposed to drag (one wheel set only forward) update URDF, wheel radius, distance, etc.

Just a hint, in case you don't already know: for the URDF you will have to adapt the yaml files in remo_description or diffbot_description (depending which model you specify when running the launch files). You can use the ROS VSCode plugin to directly view changes you make on the URDF inside VSCode. The feature is called "Preview URDF and Xacro files." which you can access from VSCodes command palette and make sure you have built and sourced your ROS workspace. You can view a gif of this process in the mobile_robot_description package from @pxalcantara.

And like I mentioned you need to update the control config in diffbot_control package. At least the wheel radius and wheel base distance:

https://github.com/ros-mobile-robots/diffbot/blob/noetic-devel/diffbot_control/config/diffbot_control.yaml#L33-L34

I guess you also have to adapt the left and right wheel parameters as shown in diff_drive_controller page as well as it is done for husky.

Is there a way to manually abort the 2d Nav Goal without ctl-C the navigation node? Poked around a bit but have not figured it out yet; would be nice while tweaking/tuning...

According to this answer you can try sending an empty goal. And I would also like to point out http://wiki.ros.org/move_base_flex, which isn't currently implemented for diffbot but it would enhance move_base and is highly flexible and backwards-compatible replacement for move_base. You can find more infos about it here: https://uos.github.io/mbf_docs/

Thanks again for the support, think we're basically there finally or at least another major milestone on the learning curve! Also need to go back thru the pertinent ROS tutorials (there are so many!) and and details on your site, they are at least starting to make sense now:-/

You are welcome! Thank you for testing everything and reporting your progress. This helps a lot to improve this project and provide hints for everyone who is interested on how to get ROS running on a mobile robot.