Robots validated with URML, and the evidence.

Pixhawk-class flight controller running ArduCopter, through the URML ArduPilot runtime

Not claimed. No conformance report with this runtime's own adapter is recorded yet; the limits below say why.

• Hardware run 2026-08-29 by URML maintainers

  A Pixhawk-class board running ArduCopter 4.6.3, on USB, propellers off. The read-only probe identified the board (ArduPilot, quadrotor, MAVLink system id 10, disarmed). urml execute --adapter ardupilot ran the bench-battery program to SUCCESS: a battery read over MAVLink and a report back to the autopilot's log. The bench-hop flight program passed the validator, and the autopilot's own pre-arm checks refused to arm (compass not calibrated, GPS bad fix, battery low voltage failsafe). URML reported that reason and stopped; the vehicle stayed disarmed.

  docs/demos/sentence-to-pixhawk.md ↗docs/launch/claims-audit.md ↗reference/ardupilot-runtime/tests/integration/test_arducopter_bench.py ↗commit f6cba8f ↗
• Simulation run 2026-08-29 by URML maintainers

  ArduCopter SITL built from the Copter-4.6.3 tag, in WSL2 on the maintainer's machine. Three of three passed in one uninterrupted run: the drone/flight_only_positive conformance fixture, the site-photogrammetry example (take-off to 100 m, five stations with a photo at each, return, land) and the parcel-delivery example (gripper and winch through set_output). The run surfaced one defect, fixed the same day: ArduCopter 4.6 rejects the MAVLink winch deliver and retract actions, so the adapter uses relative-length control. On 2026-08-30 the programs Gemini 2.5 Pro emitted through the LLM bridge for the two flight-test sentences flew unchanged on the same SITL.

  docs/launch/claims-audit.md ↗docs/demos/sentence-to-pixhawk.md ↗reference/ardupilot-runtime/tests/integration/test_arducopter_sitl_e2e.py ↗commit 221ddfe ↗

6 verdicts, replayed on every check with urml-validator 0.4.0: 2 accepted, 4 refused. Records ↗

Produced for this listing on 2026-09-27 with the urml_validator.evidence API, by validating against the listed manifest the two committed programs for it (bench-battery and bench-hop, both accepted) and four refusal cases (a take-off to 150 m, a 15 m/s leg, a photo with no camera, a flight to an undeclared place), with the compliance policy pass off and the bundled FAA Part 107 rulebook on. Every record carries the Remote ID warning, because no deployment rulebook declares a Remote ID method. The records show the gate's verdicts on this manifest; they are not flight logs.

• ·Propellers were off on the bench. No free flight is claimed, and the two flight-test runbooks have not been flown on hardware.
• ·No hardware run happens in CI. The bench run repeats only with the board attached (URML_ARDUPILOT_BENCH).
• ·The SITL run was local, on the maintainer's machine. The ardupilot-sitl-e2e CI job has not been run.
• ·The bench and SITL runs used the runtime as committed on 2026-08-29, when its package version was 0.1.0. Since then the adapter gained one optional capture argument (RFC-0699) and the version moved to 0.4.0; neither the board nor SITL has been run again.
• ·No conformance self-report. The adapter needs pymavlink and a live MAVLink autopilot (SITL or a board), so the suite cannot run it without one, and a transport faked for the suite would show nothing about the autopilot.
• ·The validation records were judged with the compliance policy pass off. The manifest declares no provenance, and this listing makes no compliance statement.
• ·PX4 is a different runtime (urml-px4-runtime) and is not covered by this entry.

GoPiGo3 educational robot, through the URML GoPiGo3 example adapter

Not claimed. No conformance report with this runtime's own adapter is recorded yet; the limits below say why.

• Hardware run 2026-06-25 by @slowrunner, an independent user, on their own GoPiGo3

  On @slowrunner's GoPiGo3 (Lyrical-Dave, with a Raspberry Pi), the example's two built-in programs ran through the real easygopigo3 library: the robot turned 90 degrees and drove under a chair. The run came from typing -h, because the example as it then stood drove the robot; the same day the maintainers made a bare run a dry run, with --execute to drive. Later that day @slowrunner ran the whole loop from a sentence: "Announce 'Driving forward 10 centimeters' and then execute the action", translated by qwen3.5:9b served through Ollama (a first request timed out; the retry was accepted after 0 revisions). The validated program ran with --execute, 2 steps, success, and the robot moved 10 cm. Speech was not heard in either run.

  discussion #542 ↗discussion #523 ↗urml.dev/blog/field-notes-first-robot-runs-urml ↗commit 58ac44c ↗
• Hardware run 2026-07-07 by @slowrunner

  On the same robot, turns and arcs ran clockwise where URML specifies counterclockwise as positive (Issues #591 and #598, opened 2026-07-04 and 2026-07-06). The fix @slowrunner contributed negates the angle and the arc at the easygopigo3 call; with --execute the robot then turned and orbited counterclockwise. It was merged on 2026-08-05, URML's first merged external code contribution.

  issue #591 ↗issue #598 ↗PR #602 ↗commit a93fe58 ↗CHANGELOG.md ↗

6 verdicts, replayed on every check with urml-validator 0.4.0: 2 accepted, 4 refused. Records ↗

Produced for this listing on 2026-09-27 with the urml_validator.evidence API, by validating against the listed manifest the example's two built-in programs (announce then drive 1 m, and the short patrol; both accepted) and four refusal cases (a 3 m drive in one move, picking up a cup, a take-off, a trip to an undeclared kitchen), with the compliance policy pass off. The two accepted programs carry a warning that the manifest declares no text-to-speech engine. The records show the gate's verdicts on this manifest; they are not logs from the robot.

• ·The hardware runs are @slowrunner's, on their own robot, as reported in @slowrunner's public threads. The maintainers have not reproduced them on a GoPiGo3.
• ·The URML maintainers compiled this entry from those public reports; @slowrunner did not submit it.
• ·The committed examples/gopigo3/gopigo3-report.txt is a dry run against a fake backend. It moves nothing and shows no hardware behavior.
• ·The adapter is an example in examples/gopigo3, not a packaged runtime. It carries the version of the URML packages it runs on (0.4.0 today); the June runs used the example as it stood on 2026-06-25, on URML 0.2.0.
• ·The example has changed since the last recorded hardware run (2026-07-07). The frame fix was reworked on 2026-07-23, and since 2026-09-07 a wait step holds the robot on the real clock under --execute. Those versions have no recorded hardware run.
• ·No conformance self-report. The adapter drives the wheels through easygopigo3 on the robot, so the suite cannot run it anywhere else without a fake backend, and a fake backend would show nothing about the robot. The suite also has no fixture for the drive and turn primitives this robot moves with.
• ·The gate does not compare a drive speed with the manifest's 0.3 m/s max_velocity; docs/safety/envelope-coverage.md leaves base velocity limits to the consuming node (RFC-0518). The example adapter passes no speed to easygopigo3, so the robot moves at the library's default speed.
• ·The validation records were judged with the compliance policy pass off. The manifest declares no provenance, and this listing makes no compliance statement.

PX4 autopilot in software-in-the-loop simulation (SIH quadrotor), through the URML PX4 runtime

Not claimed. No conformance report with this runtime's own adapter is recorded yet; the limits below say why.

• Simulation run 2026-09-27 by URML maintainers

  PX4 v1.17.0 SITL (the SIH quadrotor, headless) in WSL2 on the maintainer's machine. The drone/flight_only_positive conformance program (take-off to 30 m, a waypoint 15 m north, return to launch, land) ran through the validator, the conformance runner and PX4Adapter over MAVLink. PX4's own log records "Armed by external command", "Takeoff detected", "Returning to launch", "Landing detected" and "Disarmed by landing". A listen-only witness on PX4's ground-station link measured a maximum relative altitude of 31.79 m and a closest approach of 0.92 m to the waypoint, and saw the vehicle end on the ground, disarmed. Four runs on the final adapter code all passed. The same day's runs found and fixed three adapter defects: PX4 moves home when it arms, DO_REPOSITION needs its change-mode flag, and the old take-off sent a 0,0 position.

  reference/px4-runtime/tests/integration/sitl-runs/2026-09-27-px4-v1.17.0-sih.md ↗reference/px4-runtime/tests/integration/test_px4_sitl_e2e.py ↗docs/launch/claims-audit.md ↗commit 9ff518c ↗commit 9530a2f ↗

6 verdicts, replayed on every check with urml-validator 0.4.0: 2 accepted, 4 refused. Records ↗

Produced for this listing on 2026-09-27 with the urml_validator.evidence API, by validating against the listed manifest and the default drone envelope the program flown in SITL (flight_only) and the hover conformance program, both accepted, and four refusal cases (a take-off to 150 m, a 25 m/s leg, a flight to an undeclared place, a grasp on a vehicle with no gripper), with the compliance policy pass off and the bundled FAA Part 107 rulebook on. Every record carries the Remote ID warning, because no deployment rulebook declares a Remote ID method. The records show the gate's verdicts on this manifest; they are not flight logs.

• ·Simulation only. No PX4 hardware has flown a URML program.
• ·The run was local, in WSL2 on the maintainer's machine. The px4-sitl-e2e CI job has not run, and it still boots jMAVSim rather than SIH.
• ·One conformance program (drone/flight_only_positive) was flown end to end. The rest of the drone profile has not run against PX4Adapter, so there is no compatibility claim.
• ·Before 2026-09-27 the PX4 gate test passed on command acknowledgements alone and the vehicle never armed; that earlier green does not count. The adapter now waits for telemetry to confirm each step (commit 9ff518c), and this run is the first real flight.
• ·Perception, manipulation and docking are not available on a bare PX4 autopilot; the adapter returns a documented not-supported result for them. run_scan and wait_for(emergency_stop) still report without real telemetry and are not covered by this listing.
• ·The validation records were judged with the compliance policy pass off. This listing makes no compliance statement.