@KeithW your experience and thoughts?
I was reading about robot_localization which said I needed to read about AMCL which led me to a “nav stack “ tutorial called linobot. In that tutorial it mentions needing to tune the bot controller PID constants to ensure cmd_vel commands result in accurate bot speeds.
As far as I can tell, the GoPiGo3 red board does not allow changing PID values or setting acceleration constants. Have you seen any indication that the hardware PID control is causing localization problems?
I did include effective DPS measurement in my wheel diameter drive test, and don’t recall seeing great disparity between the commanded speed and the effective speed. The Set DPS of the wheel base rotate test is wheel DPS, not the rotation DPS, which did not allow comparing the effective rotation DPS output with the commanded wheel DPS, so I have no idea how accurate rotational velocity commands are in the GoPiGo3 node.
Localization seems to be predicting the bot’s orientation and location from the cmd_vel topic, and then matching the filtered odom (and optionally IMU, map, and beacons, and GPS) to that expectation. When the computed localization differs greatly from the expectation, the docs state the output will “jump” non-continuously.
It seemed like you were concerned that the LIDAR might be the cause of localization jumps. I was suspecting network lags or actual update frequency differences between odom and scan updates was displaying a few scans before updating the pose from new odometer topics. It seems like the localization algorithms have a million configurable parameters and a few of them talk about enabling or ignoring lags of x time, and how much divergence to allow before “jumping”.
Looking at the complexity of configuring odom-IMU fusion makes me think I will continue to create a “safe IMU” but then follow the HoROS path that ignores the IMU and not worry about how accurate any results are. Then I can reconfigure to include the robot_localization node and see how much improvement the fused data produces.
(My “Before ROS” experiment actually had the encoders only localization come out slightly better than the encoders+IMU localization, but I didn’t do any extended kalman filtering of the data streams either)
)