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 preprocessor.cc:62] 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.)
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
But I didn’t test what happens if one or more of the optional items are missing.