ROS2 SLAM on GoPiGo3 - pretty or pretty bad? Depends



I seem to remember Keith getting to a point where Finmark was SLAMing (Simultaneous Localization and Mapping) with the pretty pictures not looking as pretty as expected/desired.

There are only 25 (or more) parameters to tweak, and ten more tutorials to understand, but already I’m deciding this ROS2 GoPiGo3 knows where he is sufficient to his wishes.


Sunday 10/30/22
 13:38:41 up 31 min,  3 users,  load average: 1.40, 1.46, 1.36
               total        used        free      shared  buff/cache   available
Mem:           1.8Gi       578Mi       785Mi        14Mi       480Mi       1.1Gi
Swap:             0B          0B          0B
GoPiGo3 Battery Voltage: 11.1 volts

I think this says SLAM is using 4 threads but wanted 50 to do a really bang up job:

[async_slam_toolbox_node-1] W1030 13:30:38.062502  1574] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.

Raspberry Pi only has 4 cores to give it.

(I’m not sure of what I’ve programmed the SLAM to do, but I think I saw something about “localized mapping” so it expects the map around it to be probably accurate.)


I’d say pretty good.

I think my issue was all of the missing data - was never quite sure of why that was.


Did you notice that this image looks like a bird?

Maybe Dave wants to go with you when you go out with binoculars and camera. :wink:


did you write a subscriber to gather stats?
Was there a command in ROS (1) like the ROS2:

ros2 topic hz /scan

to check the frequency of the topic as a whole?

Of course if the scan topic has missing data that requires creating a small box to have a reading for all angles, then subscribing and counting how many angles are -1 perhaps.

I should try building a box or circle around the bot and then echo the /scan topic and look for -1 readings. There should be a few for the frame posts that hold the platform Dave sits on, but not very many hopefully.

So many tests that a ROS bot should have to pass, but at this point I’m happy if the camera gets detected when the bot boots - that threw me for a while this morning.

And since everyone’s robot has a different sensor suite, there are all the “what happens if this or that is not present?” tests that should be done on a formal offering of a ROS2 GoPiGo3 image. The first image I’ve put together only supports the basic robot, and optionally one or more of:

  • Grove ultrasonic ranger v2
  • DI distance sensor
  • DI servo
  • DI IMU

But I didn’t test what happens if one or more of the optional items are missing.

1 Like

Yes, I did this back then. I’d have to go back and look at my notes and posts. I just had lots of “0” values (example:

I’ve never been as diligent as you in really tracking down the root cause.