Interesting issue arose with Humble Dave’s safetyShutdown program now that he is a 24/7 bot. Previously, I programmed the safetyShutdown to flash the “WiFi LED” orange when the battery voltage dropped below 10 volts and to actually perform a full safety shutdown at 9.75v. This worked well for the “charge, then run till battery drained” use case of “ROSbot Dave”.
Now Humble Dave will be getting back on his dock when the light starts flashing, and the light should stop flashing when the battery is again sufficiently above 10volts. BUT, I didn’t program the safetyShutdown for that usecase, so once the light was flashing, charging would not turn the blinking caution light off!
New safetyShutdown appears to be working now:
2023-11-09 20:06|[logMaintenance.py.main]** Another Test of last leg LED **
2023-11-09 20:09|[logMaintenance.py.main]** safetyShutdown: voltage warning blinker activated **
2023-11-09 20:42|[logMaintenance.py.main]** safetyShutdown: voltage warning blinker deactivated **
2023-11-09 21:17|[logMaintenance.py.main]** Another Test of last leg LED **
2023-11-09 21:28|[logMaintenance.py.main]** safetyShutdown: voltage warning blinker activated **
2023-11-09 21:40|[logMaintenance.py.main]** safetyShutdown: voltage warning blinker deactivated **
Drove around the room four times with HumbleDave running SLAM - and the produced map looks better than I remembered. Actually surprising since his odometry thinks he is at x: 2.4 meters, y: -1.3 meters when he is back at 0,0.
Ok, now I am impressed by ROS 2 Simultaneous Localization and Mapping (SLAM)!
2023-11-11 09:49|[logMaintenance.py.main]** Starting ROS2 GoPiGo3 on dock 12.4v reported **
2023-11-11 09:51|[logMaintenance.py.main]** Off dock 11.5v using 500MB, load 1.05 reported **
2023-11-11 10:06|[logMaintenance.py.main]** Around the room and Back on dock: Odom: 0.3,-1,39deg Pose: 0.056,0.009,2deg reported 11.3v before docking 12.4v docked **
Test: HumbleDave went around the room once, then backed onto his dock:
“Dead Reckoning” with GoPiGo3 encoders only claims x,y: 0.3, -1 heading: 39 deg
(300mm in front and 1m to left of dock, with heading error of approximately 39 degrees)
SLAM from LIDAR and GoPiGo3 encoders claims 0.056,0.009 heading 2deg (56mm in front and 9mm to left of dock, with heading error approximately 2 degrees)
While much better than dead reckoning, “ROS 2 navigation with SLAM” is not going to be able to put Humble Dave back on the dock without assistance.
/pose topic is only published at 2Hz
Noting: The iRobot Create 3 uses an IR beacon, encoders, and optical flow sensor for final docking
Noting: Carl’s assistance:
castor wheel guide with 90mm wide entry extending 200mm in front of dock
(shout out to @jimrh for the suggestion - 4142 dockings ago)
Aruco marker / OpenCV tracking available (but not integrated)
Now, what seems like many “robot lifetimes” ago ROSbot Dave did a “1k run” which actually was Dave listening to my wireless game pad commands - go forward, turn right, turn left, and stop.
ROSbot Dave ran the entire 1k on the sidewalk dreaming of the day he would return to do the same run autonomously. I was not dreaming; I was imagining the difficulty to create a control structure where Dave could navigate using lane recognition but I could “assist” with joystick commands for safety of Dave as well as the dogs and bicycles that Dave would not be able to recognize and navigate around.
This morning I learned that the ROS community already built exactly this function as a ROS package called Twist-mux. I can feel ROSbot Dave’s dream becoming a reality.
Oh boy, installed Nav2, started robot dave, launched navigation, launched rviz2, clicked on “2D Goal” button, dragged a point in front of Dave, and he raced off his dock to the point. Yo, this is cool!