[Q&A] GoPiGo3 Prompting and Manifest Validation For "Orbit 180 degrees with a 5 cm radius"

[slowrunner]

What are you trying to do?

Trying to find a prompt that will generate valid URML that will result in run_gopigo3.py (using gopigo3_adapter.py) executing easygopigo3.orbit(degrees, radius_cm)

Profile

other (say which below)

Exact command and inputs

Input Prompt:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ more user_prompt.t5.txt 
Drive 180 degrees around an arc with radius 0.05 meters, then drive around an arc of radius 10 centimeters for a sweep angle of 180 degrees, then orbit 180 degrees with 5 cm radius. 

The remote Ollama server is running qwen3.5:9b with 32k context with NVIDIA RTX 4070 12GB GPU

Using urml validate to sent to remote LLM:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./gopigo3_t5_remote.sh
TEST: 5
For instructions:
"Drive 180 degrees around an arc with radius 0.05 meters, then drive around an arc of radius 10 centimeters for a sweep angle of 180 degrees, then orbit 180 degrees with 5 cm radius. \n"
performing urml translate to remote Ollama server
with qwen3.5:9b
Mon Jun 29 10:39:29 AM EDT 2026
...

What happened

Profile: Educational

1) A successful translate did not result in easygopigo3.orbit(180,5)

2) A failed translate reported "Translation accepted after 1 revision(s); profile(s)=educational and wrote to the --out <filename>
(did not write to the --save-rejected <filename>)

3) The urml translate succeeds or fails in 40-50 seconds now!!!

The "successful" urml generated:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ more remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
profile: educational
behavior:
  type: sequence
  on_error: abort_and_report
  steps:
  - drive:
      distance: 0.157
      arc: -90
  - turn:
      angle: -45
  - drive:
      distance: 0.314
  - turn:
      angle: -45
  - drive:
      distance: 0.628
      arc: -90
  - turn:
      angle: 45
  - wait:
      duration: 1

The failure urml generated:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ more remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
profile:
- educational
behavior:
  type: sequence
  on_error: abort_and_report
  steps:
  - report:
      status: failure
      facts:
        reason: DriveArgs does not support a radius parameter - only arc angle (degrees
          swept over distance). The user requests specific radii (5cm, 10cm) which
          are undeclared capabilities. A `drive` primitive sweeps an arc based on
          angle+distance combination rather than explicit radius specification per
          the manifest schema.
  - turn:
      angle: -90

Running the successful urml the GoPiGo3 runtime suggests would result in:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./run_gopigo3.py -f remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
[gopigo3 example] gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
[gopigo3 example] backend: fake (dry run, no movement)
URML on a basic GoPiGo3 - running remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml (Discussion #523).
gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
robot: gopigo3_basic   drive_type: differential   max drive: 2.0 m

[VALID] program file: remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml
   executed 7 steps, success=True
   wheel + speech calls, in order:
     drive_by     -> easygopigo3.orbit(-90.0, 15.7)
     turn_by      -> easygopigo3.turn_degrees(-45.0)
     drive_by     -> easygopigo3.drive_cm(31.4)
     turn_by      -> easygopigo3.turn_degrees(-45.0)
     drive_by     -> easygopigo3.orbit(-90.0, 62.8)
     turn_by      -> easygopigo3.turn_degrees(45.0)
     wait_passively

Dry run: validated and planned, not actuated. Pass --execute (without -m) to drive the robot.

Is there a prompt that will populate the orbit correctly?

### Validator / CLI version

urml-validator 0.2.0

[slowrunner]

Oh I'm not focusing enough - sorry - I got "A"s in all my math classes (58 years ago) and still can't use "Pi" unless its "Raspberry".

ISSUE: radius output to robot is 2x the requested radius in the NLU prompt

I did a merge of your "orbit fix" into my "TTS and Wait fix" gopigo3_adapter.py, and also tested against only your "orbit fix" version gopigo3_adapter.py and both acted the same.

I checked running with the URML repo gopigo3.manifest.yaml and my.gopigo3.manifest.yaml (only tts_engine_class diff).

Input to LLM:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./gopigo3_t5_remote.sh 
TEST: 5
For instructions:
"Drive 180 degrees around an arc with radius 0.05 meters, then drive around an arc of radius 10 centimeters for a sweep angle of 180 degrees, then orbit 180 degrees with 5 cm radius. \n"
performing urml translate to remote Ollama server
with qwen3.5:9b
Fri Jul  3 06:41:27 PM EDT 2026
wrote remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml
Translation accepted after 0 revision(s); profile(s)=educational
Done
Fri Jul  3 06:41:46 PM EDT 2026

URML Output of LLM:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ more remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
profile: educational
behavior:
  type: sequence
  on_error: abort_and_report
  steps:
  - drive:
      distance: -0.314
      arc: -180
  - drive:
      distance: 0.629
      arc: 180
  - drive:
      distance: 0.314
      arc: -180

Executing it (with any combination of the repo files or my modified files):

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./run_gopigo3.py -f remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
[gopigo3 example] gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
[gopigo3 example] backend: fake (dry run, no movement)
URML on a basic GoPiGo3 - running remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml (Discussion #523).
gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
robot: gopigo3_basic   drive_type: differential   max drive: 2.0 m

[VALID] program file: remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml
   executed 3 steps, success=True
   wheel + speech calls, in order:
     drive_by     -> easygopigo3.orbit(-180.0, 10.0)
     drive_by     -> easygopigo3.orbit(180.0, 20.0)
     drive_by     -> easygopigo3.orbit(-180.0, 10.0)

Dry run: validated and planned, not actuated. Pass --execute (without -m) to drive the robot.

Summary:

• Great progress with the system prompt to LLM generating good URML for a phrase targeting orbits.
• Good progress getting radius to the orbit in the runtime
• ISSUE: The radii are 2x the requested values.

Here is Lyrical Dave executing the URML:

https://youtu.be/Cpw7N6mznMo

The computation for distance inside the easygopigo3.orbit() is:

drive_distance = math.pi * abs(radius) * abs(degrees) / 180 # / 180 is shorter than radius * 2 / 360

so that seems to match what the LLM is putting out.

[slowrunner]

Super!

To the LLM (qwen3.5:9b):

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./gopigo3_t5_remote.sh 
TEST: 5
For instructions:
"Drive 180 degrees around an arc with radius 0.05 meters, then drive around an arc of radius 10 centimeters for a sweep angle of 180 degrees, then orbit 180 degrees with 5 cm radius. \n"
performing urml translate to remote Ollama server
with qwen3.5:9b
Sat Jul  4 12:48:46 PM EDT 2026
wrote remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml
Translation accepted after 0 revision(s); profile(s)=educational
Done
Sat Jul  4 12:49:02 PM EDT 2026

Which returned URML exactly as needed:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ more remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
profile: educational
behavior:
  type: sequence
  on_error: abort_and_report
  steps:
  - drive:
      radius: 0.05
      arc: 180
  - drive:
      radius: 0.1
      arc: 180
  - drive:
      radius: 0.05
      arc: 180

Which almost correctly simulates using the GoPiGo3 runtime:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./run_gopigo3.py -f remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml 
[gopigo3 example] gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
[gopigo3 example] backend: fake (dry run, no movement)
URML on a basic GoPiGo3 - running remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml (Discussion #523).
gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
robot: gopigo3_basic   drive_type: differential   max drive: 2.0 m

[VALID] program file: remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml
   executed 3 steps, success=True
   wheel + speech calls, in order:
     drive_by     -> easygopigo3.orbit(180.0, 5.0)
     drive_by     -> easygopigo3.orbit(180.0, 10.0)
     drive_by     -> easygopigo3.orbit(180.0, 5.0)

Dry run: validated and planned, not actuated. Pass --execute (without -m) to drive the robot.

And almost runs as expected:

(gopigo3) ubuntu@U26LDave:~/LyricalDave/systests/urml/mygopigo3$ ./run_gopigo3.py -f remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml --execute
[gopigo3 example] gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
[gopigo3 example] --execute: this WILL move a connected GoPiGo3. Clear space around the robot.
[gopigo3 example] backend: real (executing on hardware)
URML on a basic GoPiGo3 - running remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml (Discussion #523).
gopigo3 example, running on urml-validator 0.2.0, urml-ros2-runtime 0.2.0
robot: gopigo3_basic   drive_type: differential   max drive: 2.0 m

[VALID] program file: remote.qwen3.5_9b.gopigo3_t5.program.urml.yaml
   executed 3 steps, success=True
   wheel + speech calls, in order:
     drive_by     -> easygopigo3.orbit(180.0, 5.0)
     drive_by     -> easygopigo3.orbit(180.0, 10.0)
     drive_by     -> easygopigo3.orbit(180.0, 5.0)

Dave made three clockwise rotations of 180 degrees with the correct radii - alas the easygopigo3.orbit() does not follow the Forward-Left-Up convention of ROS and URML:

        :param int degrees: Degrees to steer. **360** for full rotation. Negative for left turn.

I have forked the URML repo and taking a stab at getting the speak and wait_passively primitives working - almost ready to submit a PR for review. I'm going to split the "slimey" issue I filed against the GoPiGo3 runtime, and will add a third issue to correct the drive-arc degrees sign specific to the GoPiGo3 API.