Discussion - SLAM on our robot with slam_toolbox (Making a Mobile Robot Pt 15)

Blog post coming soon

This is the discussion topic for the video and blog post linked above. Please keep all replies relevant to the content, otherwise create a new topic.

@JoshNewans
I followed the tutorial, but when i launch slam_toolbox i get this error
[async_slam_toolbox_node-1] [INFO] [1673563529.479054377] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 468.995 for reason 'Unknown'

also, in rviz2 cannot see the laser scan (unless I change Fixed Frame to “laser_frame”)

Hmm I seem to get errors like this from time to time. Sometimes they are random and sometimes they are my fault.

A few things to check are:

  • Frames named correctly in all the spots (urdf, node parameters, etc)
  • use_sim_time set everywhere when in sim, and not when not
  • Look at rqt_tf_tree to see what the tree looks like

But sometimes it just seems to get a bit stuck and I’m not sure why either.

Is this in sim or with the real robot? I find that sim seems to be less reliable (which is not what you’d expect! I think it’s to do with the timing stuff)

It was no problems… suddenly…

after executed…
ros2 launch articubot_one launch_sim.launch.py world:=./src/articubot_one/worlds/obstacles.world

[spawner.py-9] [INFO] [1680227432.822214097] [spawner_joint_broad]: Waiting for /controller_manager services
[ERROR] [gzserver-5]: process has died [pid 18890, exit code 255, cmd ‘gzserver ./src/articubot_one/worlds/obstacles.world -s libgazebo_ros_init.so -s libgazebo_ros_factory.so -s libgazebo_ros_force_system.so --ros-args --params-file /home/dev-pc/dev_ws/install/articubot_one/share/articubot_one/config/gazebo_params.yaml’].
[spawn_entity.py-7] [INFO] [1680227433.467994900] [spawn_entity]: Spawn Entity started
[spawn_entity.py-7] [INFO] [1680227433.468544716] [spawn_entity]: Loading entity published on topic robot_description
[spawn_entity.py-7] [INFO] [1680227433.470990243] [spawn_entity]: Waiting for entity xml on robot_description
[spawn_entity.py-7] [INFO] [1680227433.483558301] [spawn_entity]: Waiting for service /spawn_entity, timeout = 30
[spawn_entity.py-7] [INFO] [1680227433.484208043] [spawn_entity]: Waiting for service /spawn_entity
[spawn_entity.py-7] [INFO] [1680227433.489482207] [spawn_entity]: Calling service /spawn_entity
[spawner.py-8] [INFO] [1680227434.788296516] [spawner_diff_cont]: Waiting for /controller_manager services
[spawner.py-9] [INFO] [1680227434.839907202] [spawner_joint_broad]: Waiting for /controller_manager services
[spawner.py-8] [INFO] [1680227436.812233477] [spawner_diff_cont]: Waiting for /controller_manager services
[spawner.py-9] [INFO] [1680227436.860948410] [spawner_joint_broad]: Waiting for /controller_manager services
[spawner.py-8] [INFO] [1680227438.834333587] [spawner_diff_cont]: Waiting for /controller_manager services
[spawner.py-9] [INFO] [1680227438.880169906] [spawner_joint_broad]: Waiting for /controller_manager services
[spawner.py-8] [INFO] [1680227440.856811897] [spawner_diff_cont]: Waiting for /controller_manager services
[spawner.py-9] [INFO] [1680227440.898786976] [spawner_joint_broad]: Waiting for /controller_manager services
[spawner.py-8] [ERROR] [1680227442.877832799] [spawner_diff_cont]: Controller manager not available
[ERROR] [spawner.py-8]: process has died [pid 18934, exit code 1, cmd ‘/opt/ros/foxy/lib/controller_manager/spawner.py diff_cont --ros-args’].
[spawner.py-9] [ERROR] [1680227442.919181096] [spawner_joint_broad]: Controller manager not available
[ERROR] [spawner.py-9]: process has died [pid 18938, exit code 1, cmd ‘/opt/ros/foxy/lib/controller_manager/spawner.py joint_broad --ros-args’].

and then
rviz2 -d src/articubot_one/config/main.rviz

Warning: Invalid frame ID “odom” passed to canTransform argument target_frame - frame does not exist
at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.14/src/buffer_core.cpp
Warning: Invalid frame ID “odom” passed to canTransform argument target_frame - frame does not exist
at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.14/src/buffer_core.cpp
Warning: Invalid frame ID “odom” passed to canTransform argument target_frame - frame does not exist
at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.14/src/buffer_core.cpp

I am not sure this is ok and would like to ask Josh.
I am in Melbourne CBD near Victoria Market.
I am following Josh’s great video alone.
very lonely…
I would like to find friends and making the robot together in Melbourne…
Anyone following Josh’s great video or interested in making any kind robot, please let me know.
john.js.nam@gmail.com

Fixed…
Gazebo issues

killall gzserver

kilall gzclient

Hey John, yeah as you figured out it looks like Gazebo crashed for some reason, and sometimes it leaves processes running that you have to kill manually…very annoying.

Re your other message, thanks for asking. I’ve gone ahead and created a new category called Meetups and you are very welcome to create a post there, but since the community is currently fairly small I’m not sure how much luck you will have finding someone nearby. But I encourage you to create a post anyway!

You might also want to try the official ROS Discourse and Discord, however my experience has been that the Australian community is quite small - something I would like to help improve eventually but I haven’t got time to focus on that at the moment.

P.S. For some reason your account did not have permissions to create new topics but I have now fixed that :slight_smile:

Hi, Many thanks for the tutorials very clear, it helped me alot starting understanding ROS2.
unfortently i keep getting a error once after i changed RViz to work with map or odom i get (very often) the follow error:
“[rviz2-4] [ERROR] [1681401743.264000589] [rviz2]: Lookup would require extrapolation into the future. Requested time 1681401743.323050 but the latest data is at time 1681401743.259460, when looking up transform from frame [laser_frame] to frame [map]”
And the lidar data apprear in rviz time to time.
However when i change to base link the data arrive with good freuency.
i think the tf for laser to odom not run on the same rate, but i can not control on the laser data
Please any idea, i did not find hint in Google

Hey, I’ve been battling this for a while. downloaded your code from GitHub and keep getting this error after navigation is up. Works perfectly in simulation but in irl won’t work

[planner_server-2] [INFO] [1682009322.212167775] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past. Requested time 0.200000 but the earliest data is at time 1682009321.772360, when looking up transform from frame [base_link] to frame [map]
[planner_server-2] [INFO] [1682009322.712264144] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past. Requested time 0.200000 but the earliest data is at time 1682009321.772360, when looking up transform from frame [base_link] to frame [map]
[planner_server-2] [INFO] [1682009322.875770766] [global_costmap.global_costmap]: StaticLayer: Resizing costmap to 95 X 80 at 0.050000 m/pix
[planner_server-2] [INFO] [1682009323.212146288] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past. Requested time 0.200000 but the earliest data is at time 1682009321.772360, when looking up transform from frame [base_link] to frame [map]
[planner_server-2] [INFO] [1682009323.712307436] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past. Requested time 0.200000 but the earliest data is at time 1682009321.772360, when looking up transform from frame [base_link] to frame [map]
[planner_server-2] [INFO] [1682009324.212233059] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past. Requested time 0.200000 but the earliest data is at time 1682009321.772360, when looking up transform from frame [base_link] to frame [map]

It just constantly spits this out until I Ctl+C

I can generate a map and drive it around via remote no problem

Hmm I’m not sure sorry. But yeah I’d suggest that something is up with the tf rate. One thing to check (though this shouldn’t make a difference) if you’re running different nodes on different computers is to make sure the clocks are perfectly in sync (both have NTP enabled).
Did you ever get it to work?

I assume this is the same as your problem from the other thread and were able to resolve it? :slight_smile:

Yes, it was. do you want me to remove it?

many thanks for replay.
yes i fix the issue, i changed the publish rate in rplidar file, from 1ms to 100ms and now all good. the change should be hardcode in the file

1 Like

Josh, I have had great success with your tutorials above all others. I’ve been building this robot for a customer and bit off more than I can chew. :slight_smile:
It all seems to be working but when I try localization on the real robot it keeps getting stuck because the timestamp on the laser frame is earlier than all other data in the cache. It’s only like 0.05 NS it’s all on the same machine …Pi… I thought it was the rplidar_ros package so I wrote my own publisher for the laser and it still gives same message. All I can do now is beat my head in the door. Do you have any suggestions? I know it will be something simple and stupid but I’m at a complete stop at the moment.
And yes. use_sim_time is set to false

I tried changing rate to 100 ms but it did not work. Still out of sync. I even tried my own laser publisher but no difference. Any suggestions?

Hi josh one question I build my own Roboter with you tutorials in the end it will be a diy cleaner hehe!
Everything is working perfect just when I launch slam and navigation the map it creates doesn’t fit with the LiDAR and when I give him a goal it’s just crashes into something pls can u help me!

I’m using Ubuntu 22.04 and ros humble. And for the robot with a raspberry pi4 B

Hmm, I think I’ll need a bit more information to help you with that one.

If the map isn’t right then we’ll need to solve that one first.

Are you using slam_toolbox like in the videos? When you say it doesn’t fit, is the map coming out all messy? Or wrong in some other way?

Im launching in my workspace „ros2 launch articubot_one online_async_launch.py “

than adding map on rviz2 and the map appears perfect matching the LiDAR, but when I drive around the mapping is working for some seconds and then loses it and doesn’t match with the LiDAR and the map becomes a mess.