[Solved] GoPiGo3 ROS Is 8 Years old - Why Am I Seeing An Odometry issue?

GoPiGo
1

Open source software is wonderful… unless you are the only person in the whole world running some ill behaving code.

I just discovered an issue where driving my ros2_gopigo3_node back to the {0,0} origin point can emit bogus negative value odometry estimates.

I didn’t create this node, I ported it from ROS (1) code that noone is using and no authors remain. Since there are no extant GoPiGo3 ROS robots to compare to, I have to wonder if I introduced this issue or it has been hiding in plain sight for eight years. Wishing I wasn’t so alone in this adventure. Math has never been my strong suit, and who actually knows what a quaternion looks like?

GoPiGo3 ROS History

  • Floris Van Bruegal wrote a very basic rosgopigo in 2016

  • Surfertas (HongKong) wrote a “state predicter” ros-gopigo later in 2016

  • Christian Rauch created and updated a ros-gopigo in 2016, 2017, 2018, 2019, and 2020

  • Richard Wang created an intro to ROS course using the GoPiGo3 in 2016

  • TIS/nmatsui/tech-sketch created a MQTT ROS node to control a ROS GoPiGo3 node in 2017/2018 (FIWARE Orion context broker)

  • taityo/iot-magi mated the YDLIDAR X4 to the GoPiGo3 (with full instructions and videos) in 2018

  • Thomas Lehmann (Post-Doctoral Fellow) was using ROS with the GoPiGo3 in 2018

  • Mattias Nacimento (Rio De Janeiro) implemented a line following ROS GoPiGo3 in 2019

  • Peng Xu used X-Box controller to drive his ROS GoPiGo3 in 2019

  • “tripincloud”(Undergrad Sorbonne U.) built a ROS GoPiGo3 in 2020

  • Albert Alvarez (Barcelona) developed a team course for “Learning ROS with GoPiGo” in 2020

  • Bernardo R. Japon: “Hands On ROS For Robotics Programming: Program highly autonomous and AI-capable mobile robots powered by ROS”, Packt Publishing, 2020

  • ManuelPuig and enrip19 built a WALL FOLLOWING JupyterLab for ROS GoPiGo3 in 2021

  • MGubbi created a web page ROS bot controller for a ROS GoPiGo in 2021

  • Jean Vanhay (Belgium) created a ROS-IOP bridge to control a ROS GoPiGo3 2021

  • ROS2-GoPiGo3 “v4 Image” Slowrunner 2022

  • ROS Noetic Image for use with Hands On ROS book Nov 2023

  • ROS2-GoPiGo3 “v5 Image” Slowrunner Dec 2023

Past Users:

Current Users:

2 Likes
2

Once I get Charline qualified, I’m planning to give it a try.  Be prepared!  (for all the noob questions)

2 Likes
3

Because I Reset The Encoders For Testing And Forgot I Did IT

So the ROS 2 GoPiGo3 node odometry is working as designed and the design may be sufficient.

The negative odometry Issue is Resolved

2 Likes
4

What does this mean and why did it produce the artifact you noticed?

1 Like
5

Dave has a non-ROS Python test_docking program that docks Dave when the battery gets low, and undocks when the charging current gets low.

In order to make this docking and undocking very reliable, I wrote a “drive_cm_with_bias(distance,bias)” Python function.

To make it easy to test, I reset the encoders to 0 before driving with bias, then after driving the encoders should differ from each other by the bias, and should be roughly equal to distance/pi*wheeldia*360. No subtracting the initial encoder value from the final value - just read the encoders and is the number what I expect for 17cm plus/minus the bias.

The function works just the same without resetting the encoders, but easier to see if it worked when starting with encoders at 0.

The odometer program is a ROS node that is watching the /odom topic published by the ROS GoPiGo3 node, which is converting encoder value changes into a new /odom {x,y} position (and speed) estimate.

So the docking test program was resetting the encoders to 0, then getting off the dock - encoders end up at values around {283, 300} and the odometer says position is now {0.168,0} (17cm forward). All good.

Then the darn docking test program resets the encoders and backs 17.4 cm onto the dock. The odometer correctly says Dave moved backward 17 cm but now the position estimate is {-0.174,0}.

To try and understand what was going on and seeing the negative position estimate, I would force a call to the ROS GoPiGo3 service to reset the pose (position+heading) to {0,0,0,1} dang quaternions! {x:0, y:0, z:0, heading:0} when Dave was charging on the dock. Then everything would appear to be good when Dave got off the dock, and again went crazy when Dave got back on the dock.

Through all this I discovered that my GoPiGo3 node was using the raw gopigo3.reset_motor_encoder() function which exposed the fictional speed and power issue, where my drive_cm_with_bias() was using the easygopigo3.reset_encoders() function which sets the power to 0 with only the fictional speed issue. Thus I could improve both the GoPiGo3 node and the odometer program.

Oh I’m tired just thinking about this “fixing the platform” adventure. When can I just tell Dave to go to the kitchen and expect him to get there in one piece?

2 Likes