Years Asking Humans and Google, Finally Google Gemini Answered

[cyclicalobsessive]

For years and years, my ROS robots have displayed an innocuous exception when I terminated a node with ctrl-c or killed all my robot processes.

For years I have searched Google for a solution. I posted about the issue on robotics.stackexchange and discourse.ros.org and many other places. Last year I logged issues against the ROS tutorials in the May 2025 ROS 2 Kilted Test Party about this. No one could tell me how to fix it - ever.

More than a year ago, @jimrh joined the “vibe coding” rage and reported using a large language model to write useful code. I stayed away from trying it, mostly due to distraction by other hobbies, but last week gave in and successfully used Google Gemini to write a new ROS 2 node.

It was a very basic node that would have taken me about 30 minutes to refresh my brain from existing nodes and then create the new node. Telling Gemini what I wanted produced suggested code for the new node that did not work at first, but I knew how to fix the problem and added the required lines to make the Python3 node run.

BUT! the Gemini created node had the same “cntr-c exception” issue that I have put up with for years. I decided to ask Gemini for a solution to the error traceback. The first modification to the code suggested by Gemini did not fix the problem, so I provided the traceback again to Gemini and asked for a new suggestion. At that point I had spent more time having Gemini write the code than it would have taken me to produce it, but my code would have had the same cntrl-c exception issue.

Voila! The Gemini large language model agent has produced a solution to an issue that has vexed me for more years than I can remember.

[cyclicalobsessive]

Week Later - Google Gemini Has Fried My Brain

I sic’d Google Gemini on my ROS Nav2 issues:

• planning going too close to walls and bar stools causing goal failures
• “Out of Map Bounds” errors after tile-rug transitions

Gemini would recommend something, and when I would tell it “that didn’t work”, it responds “right, you are using ROS Jazzy which works differently, try this next idea”, or I would point out it first told me one thing and then told me the opposite, and it would tell me "that is very astute. Lets focus on the other problem.

To solve over-stressing the CPU, it recommended ROS composition. After spending a day learning what that means and changing things all over my system, navigation seg faulted everytime. So it started trying to fix the seg faults. I noticed a weird error that indicated half of Nav2 was using the parameters I supplied, and half was ignoring my params and telling me to fix the conflicts.

After going many rounds with Gemini or several days morning to night, telling me “try this so we can verify such and such”, and me feeding it what the new error messages were, and then it trying to fix the new errors, and getting deeper and deeper into the mud, it suddenly reports that someone submitted an issue about this “Navigation not using given parameters in Composition”.

(Oh and I went a few rounds with robotics.stackexchange.com folks that helped me understand a few things, but got me no closer to solving any of my composition problems.)

Finally, Gemini decides “Since WaLI has operated reliably for over 9000 hours, you should stick with the non-composition launch of nav2”

Right - and that success is right on the edge - if I so much as ask WaLI what his battery level is while he is navigating, navigation blows up. I should stick with the “successful” way.

Gemini will quickly go down a rabbit hole, (or twenty ant piles at once), if you don’t keep reminding it to stay focused on the big picture issue you came for help with.

Uggh. Google Gemini has fried my brain in one week. I can’t imagine what I would do if my boss was telling me “Use AI so you can get this done quicker”.