Hands On ROS: ROS2 Version

Again, never having messed with even the first version of ROS, I’m not exactly an expert here, but it seems that things are way too complicated.

[my opinion]
The only real limitation to the GoPiGo-3, (aside from the programmer’s skill), is the 'bot’s physical size and hardware capabilities.

  • It’s relatively small.
    The wheel motors are pitifully weak by robotics standards and there is relatively little room to attach stuff.

  • It could use more ports to attach things to.
    I found a Seeed Studio Grove-Pi board that has an absolute S-load of ports on it. Since it uses the same 26 pin header that the GoPiGo uses, I wonder if they can be stacked.

These limitations are easily explained when you realize that the GoPiGo was originally designed to be a robotics teaching tool and not a DARPA/Steroid infused Battle Bot.

So far, I have not seen anything you can do in ROS of any flavor that could not be done in R4R.

I also believe that, as robots go, the Dexter/M.R. implementation is as simple and elegant as anything else I’ve seen.

At the risk of mangling a line from Fiddler on the Roof  “I can do things in Bloxter that would cross a rabbi’s eyes!”

And it’s true.

I have not yet seen the limits of Bloxter, except for the implementation of undefined hardware like a LIDAR.

And that’s not even a limitation since new blocks can be defined. (I’m still waiting for the spec’ for that one. It’s been promised, but there appears to be too much on their plate as yet.)

And that objection goes away when using R4R.

Again, the interface is clean, remarkably intuitive, and relatively simple when compared to other robotic languages I’ve seen.

Also, based on the stuff both you and @KeithW are doing, ROS seems to be needlessly complex. It seems to embrace complexity for its own sake, avoiding simpler and more elegant ways of doing things.
[/my opinion]

Even while working on my Remote Camera Robot project, I am amazed by how difficult it is to do simple things.

The main control routine on the client side is a gigantic piece of code called “nipple.js” that is absolutely huge and virtually impossible to figure out.

Part of this, IMHO, is because it wants to do too many things at the same time that should really be broken out into separate routines.

Every time I end up in a situation where things appear to be needlessly complex, I try to take a step back and work out how to do it in a simpler way.

But that’s me.



Is it possible to stack a Grove-Pi board on a GoPiGo-3?

Of course it’s possible, the connectors fit.

What I mean is “Will it work? Will it add more usable ports to the GoPiGo 'bot,?”

1 Like

That “you are doing” is a key point there. I want to unlock the potential that comes with not having to write every single new capability for my robot.

For example, I wanted to have Carl know what room he is in, and to develop an occupancy grid with confidence for every obstruction in the grid. I started writing a data collection routine, and a path visualization routine, and the occupancy grid from the distance sensor (including the distance sensor’s beam width, minimum and maximum range), and an occupancy grid visualization routine. I got pretty close, but working out the trigonometry and visualization projection transformations was trying my patience and matrix math skills.

All the smart ROS folk already wrote those features, six ways to Sunday, and all I need to do is make my bot broadcast every little thought that passes through its head over my local net, and make my Mac listen for those thoughts. I can try out all kinds of other peoples’ code on my Mac like visual object recognition, mapping, goal driven path planning, or visual obstruction detection, or even that elusive wall following I asked about years ago. (What self-respecting robot company releases their robot without a wall following example? Come on ModRobotics - please… )

I am pretty sure that some of the features will be able to run on-board the bot in a non-realtime fashion, while the bot sits patiently waiting for its next great idea for physical exercise.

ROS is certainly complex, way way more complex than the most sophisticated multi-tasking python example that the GoPiGo3 “Master” @RobertLucian left us with Intelligent Obstacle Avoider Robot and the Remote Camera Robot that you love so much (not sure if that one was @cleoqc or Robert).

ROS should not be the starting point for learning about robotics or programming, but the GoPiGo3 could be a good starting point for learning about ROS. “Could be” because someone very familiar with ROS and the GoPiGo3 always has to “ROS-ify” the platform before it can be used to learn about ROS.

Folks that have already “ROS-ified limited functions of the GoPiGo3”:

  • 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

  • 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) just created a ROS-IOP bridge to control a ROS GoPiGo3 last week
    (What ever that is - he’s using ROS on a GoPiGo3 so he’s my hero of the day!)

  • “Our” @KeithW , @thomascoyle11859, and @pitosalas need to be on this list of ROS GoPiGo-ers

  • and let us not forget the disappeared author Bernardo Japon of “Hands On ROS For Robotics Programming: Program highly autonomous and AI-capable mobile robots powered by ROS” which may end up (only in my opinion of course) slightly bending the semantics of the word autonomous to mean the remote controlled GoPiGo3 by the “man behind the curtain” of ROS nodes distributed across a network.

From what I can tell, no one has actually focused on using ROS self-contained on the GoPiGo3, nor exposing every prescient thought of a RaspberryPi 3B+ GoPiGo3. Perhaps I am simply naive to think anything useful could be accomplished as a self-contained ROS on GoPiGo3 robot, but I plan to find some of the limits.

For the last three years Carl has been recording every drive and every turn for 4915 feet of travel and over 1 million degrees turned, but I have nothing to visualize those excursions. If that had been put in a ROS bag instead of a self-conceived format text file, I (believe I) could actually see where he went on the big displays of my MacMini. Not that seeing it would solve any questions of the universe, but it might be (boring) fun.

So yes, ROS is complex, but hopefully far from needlessly so even for me.


Wow - that’s an impressive list. I was unaware of that.

I suspect you are right that the added complexity of ROS2 was to meet the demands of more sophisticated robots. I’m sure the changes were driven by what turned out to be real world limitations - and the developers did decide to forego backwards compatibility to improve future functionality.

For me the GoPiGo3 was a vehicle for learning and experimenting with ROS. So using R4R wasn’t even a consideration. ROS was designed to serve as a framework for lots of different robots so that programmers didn’t have to start from scratch with every new hardware platform. That’s why I’ve wanted to learn it - so I can move to different platforms for different uses, but be able to translate my knowledge between them relatively easily.

sounds like a great goal.



There’s a saying attributed to Einstein (w/o any real proof btw) along the lines of “make everything as simple as possible, but no simpler”. I think ROS is actually that way - there’s a reason behind each bit of complexity. But it was created to ultimately make life easier for a developer.



Since Gazebo wasn’t staying alive, I skipped past Chapter5 and started Chapter6 which introduces getting your GoPiGo3 to talk ROS.

Since my ultimate Chapter6 goal was to get ROSbot Dave talking and have my ROSdesk (VM on Mac) listening, analyzing, and displaying everything, I decided to divert to trying:

On ROSbot Dave:

ros2 run demo_nodes_py  talker

And on ROSdesk:

ros2 run demo_nodes_cpp listener

to prove the new ROS2 dynamic discovery is going to work for me.

Uh…NO! Hold the cigars, ain’t no baby being delivered today.

After 24 hours of questioning and “try_this_that” on answers.ros.org and VMware community,

with a little luck and magic updating both systems yielded a breakthrough.



pi@ROSbot:~/rosbot-on-gopigo3$ ros2 run demo_nodes_cpp listener
[INFO] [1625930607.244627442] [listener]: I heard: [Hello World: 9]
[INFO] [1625930608.245326225] [listener]: I heard: [Hello World: 10]
[INFO] [1625930609.245479175] [listener]: I heard: [Hello World: 11]
[INFO] [1625930610.244978271] [listener]: I heard: [Hello World: 12]
[INFO] [1625930611.245139866] [listener]: I heard: [Hello World: 13]
[INFO] [1625930612.245483542] [listener]: I heard: [Hello World: 14]

ubuntu@rosdesk:~/handsonros2$ ros2 run demo_nodes_cpp listener
[INFO] [1625930576.490056884] [listener]: I heard: [Hello World: 1]
[INFO] [1625930577.489776977] [listener]: I heard: [Hello World: 2]
[INFO] [1625930578.489909352] [listener]: I heard: [Hello World: 3]
[INFO] [1625930579.489984629] [listener]: I heard: [Hello World: 4]
[INFO] [1625930580.489982903] [listener]: I heard: [Hello World: 5]
[INFO] [1625930581.490141665] [listener]: I heard: [Hello World: 6]


Also my “ROS2: Is it too soon to migrate?” question got picked up as “News of the week on discourse.ros.org” getting lots of attention, and a suggestion from a ROS2 guru on launch files with conditional arguments - “upgrade to Galactic and here’s how to do it”.

Let that teach me to choose the Long Term Support ROS2 version for my efforts. Actually, I did buy the Galactic T-Shirt when it was available last month, but was not brave enough to install it.

Adventures in playing with the “real serious robot folk” continue …


1 Like

Wow - congratulations. Real progress.
Adding a VM in the mix definitely complicates things - I fortunately had an old laptop I run linux on just for my ROS work - makes life simpler in many ways. In theory I can write my code on my desktop and then sync it with my laptop and robot via GitHub. In practice I don’t have that workflow quite down yet, especially since I tend to iterate quickly while running tests, so I’m on the laptop. I have shifted to using VS Code on my laptop to remotely edit files on finmark (using VS Code’s remote explorer. That seems to be working fine).

You’d think that would be the better way to go, but maybe ROS2 is immature enough that there are still gaps that need to be filled, and backports aren’t keeping up.

I love the design (and colors) of the Galactic logo. I guess I like “space” themes - I really liked the ROS1 Lunar logo as well. Too bad neither was an LTS version. I’m thinking I’ll shift when it get’s to “H” - hope they have a decent name and logo :slight_smile:



May 2022 Humble Hawksbill - claims to simplify launch arguments and parameters.

T-Shirt not out yet.

1 Like

Yeah - they usually make them available right around launch time. I don’t think my current stack of ROS t-shirts will wear out by next May.


I Guess I used up all my luck and magic… DDS is back to not working across the net today.