When ROS makes sense for the GoPiGo3

Beyond the question “Why ROS for the GoPiGo3?”, is the recognition that the GoPiGo3 can serve as a learning platform for the most basic school subjects that every student must know, and for subjects that no one student can know everything.

So “When does ROS make sense for the GoPiGo3?” - When the subject to learn is ROS, or requires ROS, and the minimalist concept of the GoPiGo3 can support the subject to be learned.

To address “Why do it?” in my specific case:

  • To learn the specifics of using ROS2 and programming for it
  • To find out if a single Pi4 can run:
    • ROS2 middleware layer,
    • ROS2 GoPiGo3 robot node,
    • ROS2 LIDAR, IMU, Camera nodes,
    • Basic ROS mobile robot packages (localization, mapping, navigation w/obstacle avoidance)
    • ROS2 Behavior Tree robot control
  • Refresh my 25 year old C++ programming knowledge

It might be of interest to note that an equivalent TurtleBot4 solution only differs in that the TurtleBot4 Pi4 does not have to run the ROS2 GoPiGo3 robot node or the IMU node.

Preliminary tests of my Python based ROS2 GoPiGo3 robot node running on the Pi4 appeared to consume about 7% of the processing load, with the expectation that coding in C++ will reduce this to 1%.

Preliminary tests of “my code” Python based GoPiGo3 IMU node running on the Pi4 appeared to consume almost 30% of the processor, and did not provide the sub-degree precision heading data expected.

Another hope is that switching to a community coded IMU node will lower the processing load and allow a configuration that will achieve the desired heading accuracy.