Progress continues:
- added odometry reset batch file to demonstrate publish to ros2_gopigo3_node service listener from command line (Update: 10/28/22)
- Headless networking config of image looks promising - “v3 Basic ROS2 GoPiGo3” up for testing
- "v4 Dev:
- Running robot_state and joint_state publishers from URDF file as part of ros2_gopigo3_node package (GoPiGo3 takes its wheels when moving in the visualized “world” by rviz2 tool)
- Building maps, saving maps, converting pgm maps to jpg format for convenience
- Full Up Steady State Statistics:
- CPU: ~25% Temp: 60degC (no where near throttling)
- Memory: 600MB used of 1.8GB (no swap used)
- Disk Used: 6GB of 30GB - seems to suggest 8GB minimum, 16GB recommended
Immediate Goals:
- add features to teleop_gopigo3_key node:
- “Pose Estimation From GoPiGo3” /odom topic subscription (x,y, heading)
- map three keys to publish Servo center, left 45, right 45
- add ultrasonic ranger reading subscriber to display current reading
- add distance sensor reading subscriber to display distance sensor reading
- add imu subscriber to display IMU heading reading and room temperature
- add odometry reset key (reset x,y,heading to 0) (/odom/reset srv client)
Gaping Hole In Features
- PiCam image topic publisher
WIBNIs:
-
add scan subscriber to teleop_gopigo3_key to display forward, backward, left, right distances
-
nav2 example with LIDAR (demonstrate localization? and obstacle avoidance)
- drive forward 1 meter
- turn 180
- drive forward 1 meter
- turn 180
-
Odom fusion of encoders with IMU for more accurate turns
-
Make ros2_gopigo3_node a “LifeCycle node”
-
Pass URDF file name as a launch parameter
-
Add IMU reset service to /imu_sensor node
-
Understand why ROS2 IMU heading is drifting quickly (~1deg / minute)
but Euler Heading from “readIMU” command does not drift.
Frames Published By Robot State and Joint Nodes
The RQT Graph of nodes/publishers/subscribers
The wheels don’t get left behind now! (Robot State and Robot Joint Publishers at work)
Visualization shows GoPiGo3 estimated:
- map
- localization in map
- ultrasonic ranger reading is approximately where the robot thinks wall exists confirms URDF info matches the robot physical measurement.
- odometry error building up - robot started aligned with the white grid, so map walls should also be aligned with the grid, but odometry heading or localization heading errors or both are causing the robot to think the wall is no longer aligned with the grid, (but it was).