[Builders & Makers] RE: GoPiGo3 RFC from a GoPiGo3 enthusiast

[slowrunner]

Which are you?

Evaluating, not building yet

Substrate or product

GoPiGo3

What do you want to discuss?

GoPiGo3-RFC:

Two real questions:

• (1) is an English-to-validated-intent front door useful for a beginner robot like the GoPiGo3?
• (2) Does the GoPiGo3's capability set map cleanly onto a URML capability manifest?

Who Am I: I am a GoPiGo3 robot enthusiast that runs two 24/7/375 GoPiGo3 robots - Carl "alive" since 2018, and Lyrical-Dave, "alive" since 2020, Dave has been reincarnated with each new ROS and now ROS 2 Lyrical Luth release.

To answer your questions from my POV:
1: No - the GoPiGo3 user base and market are not learning at the level of NLU-to-action. The robot is primarily used to teach very basic concepts with a Blockly type graphical programming language or Python.

2: No - the GoPiGo3 does not have capabilities that map onto the URML capability manifest.

[idoco2003]

Thank you, this is exactly the kind of grounded feedback I was hoping for, and you've convinced me. You're right on both counts: the GoPiGo3's audience is learning the basics through Blockly and Python, not natural-language-to-action, and its capability set isn't what a URML manifest is built to describe. An English-intent layer would be solving a problem this robot's users don't have.

I appreciate you taking the time to lay it out from real experience with Carl and Dave, that is far more useful than a polite maybe. I'll mark GoPiGo3 as not a fit.

[CleoQc]

GoPiGo3 could totally be a fit. It has to evolve, like we all did with LLMs. Let's talk.

[slowrunner]

Continuing the "Discussion of URML for the GoPiGo3" (from my POV as a user, not a maintainer):

https://forum.dexterindustries.com/t/discuss-a-standardized-robot-language-for-gopigo3/10858/4?u=cyclicalobsessive

Looking to understand "What would be the benefits to the GoPiGo3 user given the simplicity and limitations of the GoPiGo3 platform?"

[idoco2003]

Fair question, and I'd rather answer it straight than talk anyone into anything.

For the GoPiGo3 as it ships today, you're right about the limits. Dead-reckoning means named-location navigation drifts, there's no fixed frame to anchor a manifest's declared_locations to, and chasing a compliance mark would be exactly the non-useful complexity you describe. I wouldn't ask a GoPiGo3 user to build any of that.

The one benefit I'd stand behind is pedagogical, and it's additive to Blockly/Python, not a replacement: the "watch it refuse, and say why" loop. A student types a plain-English instruction, sees it become a typed, explicit plan, and, when they ask for something the robot can't do or that isn't safe, sees it stop and explain in plain language before anything moves, rather than failing silently. That "the robot tells you why it said no" moment is the part that maps to a classroom, and it's the angle Cleo raised.

On the frame point: the precedent we use for a dead-reckoning classroom buggy is the LEGO SPIKE driving base, a local floor/mat frame with waypoints as offsets in meters rather than a global localized frame. It's approximate by nature, fine for a mat exercise and not for precision. So the GoPiGo3 is describable the same way, with the honest caveat that the payoff is the teaching loop, not navigation accuracy.

So it's not a compliance story, and not a replacement for how kids already program the robot. It's a thin English front door whose payoff is a beginner seeing their intent checked and explained before the wheels turn. If that's not worth the surface area for your users, that's a completely legitimate answer, and I appreciate you pressure-testing it from real experience with Carl and Dave.

[slowrunner]

"watch it refuse, and say why" loop. A student types a plain-English instruction, sees it become a typed, explicit plan, and, when they ask for something the robot can't do or that isn't safe, sees it stop and explain in plain language before anything moves, rather than failing silently. That "the robot tells you why it said no" moment is the part that maps to a classroom, and it's the angle Cleo raised.

Indeed that is progressive. I used to program rule-based , blackboard centered products that benefited from an explanation facility during development and during production. Today's software systems are seriously complex, with asynchronous parallel processing that rarely offer explanation beyond multi-log analysis.

BUT, there is something deeper that is happening in Human-Machine interfaces, in software development, with some of the students I am encountering on Reddit, Mastodon, and discourse.openrobotics, and my wife - nearly everyone is relying on asking for answers. Fewer and fewer products come with manuals because fewer and fewer people are reading them.

How do folks learn what are the core functions of their devices (and robots)?

• A few use "targeted exploration" - searching for how to do something they hope the device can do, and being exposed to some non-target functionality during the search.
• Most use "ask a friend" (whose knowledge and reliability is not assured), or "ask on social media" (correct answers not assured),
• Some will learn how to ask a web search engine, and learn how to discern/navigate the myriad of possible answer sources,
• Some will search YouTube or other video sites - again social media sources of questionable reliability
• A few will have formal software and hardware experience to "understand the mind of the device"

Where am I going with this? I wish kids would read, learn to plan multiple steps, and think about error recovery before they build.

Putting a LLM of questionable reliability between a student and a system of unseen gates through which the student is expected to investigate through accidental correct and explained incorrect prompts, to make a physical blackbox perform tasks that the student must imagine the robot to be capable of - just seems inefficient, encourages "asking", and avoids reading.

Perhaps with educational collateral around the system, there is reading and methodical instruction. I just keep seeing more and more kids trying "We have a month to make our robot do amazing things. We haven't any background. Please help us.", or "I love robots and open-source, (but know nothing and have done nothing). Where can I contribute?". My favorite lately: "How do I learn ROS?". Excuse-me did you try reading, perhaps install it, go through the tutorials and actually try to understand what every line of software does?

I see lots of people "vibe-coding" with no understanding of principles of design, principles of test, principles of quality/reliability/robustness. More and more neophytes are learning how to prompt LLMs to create AI slop with no understanding of anything.

I used to design speech grammars which performed more than just the syntactic checking, they included semantic intent resolution. The secret to making good NLU models was embedded grammars. The farther into the LLM the URML can be embedded, the more likely a "user" will have success with the robot, but I doubt the system will educate the user on any of the principles of design, engineering, or business.

This all makes me sound like a curmudgeon. I really love computers and robots. No, I am obsessed with computers and robots. I know nothing about effective teaching or business so my opinions are probably worthless here. Sorry - guess I'm just venting.

[idoco2003]

That shift you're describing, from reading manuals to asking, is exactly why the "ask, and watch it explain when it refuses" loop feels worth building. The explanation isn't a debugging log after the fact, it's the answer to "what can this thing actually do, and why won't it do that," surfaced at the moment you ask. Appreciate you thinking out loud here; it's a useful frame.

[slowrunner]

Going to close this "early, uninformed opinion" and continue with specific discussions