URITP (Universal Robot Instruction/Translation Protocol)

One language for every robot.

Comment

Inspiration

The first robot one of us ever programmed was a Universal Robots arm. The tutorial was in URScript. The second was a rover on ROS 2. The third was an Arduino car. Same job every time, drive a square, and three languages later we had 63 lines of code, and not one of them said what 0.25 meant. Metres? Metres per second? You found out when the robot moved.

That is the state of robotics today. Every brand speaks its own private language, so learning one robot teaches you nothing about the next. Real robots cost more than most schools can spend. A mistake on a real robot can hurt someone. And almost every tool is English-only, which shuts out millions of learners.

We wanted the travel adapter for robots: one plug, every socket. Write a program once, in plain words, with real units, have it checked before anything moves, and run it on an arm, a rover, a drone or a simulator. That is URITP, the Universal Robot Instruction and Translation Protocol.

What it does

URITP is a small language that reads like English and only knows how to say robot things: robot car = connect(“lab:rover”) repeat 4 times: drive car.base forward by 0.5m speed 0.4m/s turn car.base by 90deg

Four lines. The same square, written by hand for ROS 2, Arduino and Raspberry Pi, is 63 lines across three languages, about 94% more code.

Six ideas hold it together:

  • Say the goal, not the motion. You say where things should end up; the robot works out how.
  • Check before moving. ElaraCheck, our checker, reads the whole program first. One error anywhere and nothing is sent to any robot.
  • Units are always written. 10cm, never 10. Length, time, speed, angle, force and percent are types, and mixing them is an error on a line number, not a crash on the floor.
  • Safety can't be switched off. Every robot ships a manifest with its speed limits, reach and forbidden zones. A program cannot raise them.
  • Never "close enough". A robot does exactly what was asked or refuses and says why.
  • Open to every maker. Vendors add their own features as clearly labelled extensions without breaking the common rules.

On top of it sits ELARA, a free playground that runs in a browser tab: you type or say what you want, in English, Hindi, Hinglish, Spanish or Arabic, an AI writes the URITP, the checker reviews it, and a 3D robot carries it out, or stops and explains in your language what was wrong.

How we built it

URITP is a real compiler, not a chatbot wrapper. The pipeline is: lexer → parser → ElaraCheck → compiler → runtime → adapters.

  • The lexer treats a number and its unit as one token (QUANTITY ('0.5', 'm')), so units can never be lost by a later stage.
  • A hand-written recursive-descent parser builds the syntax tree; the grammar is small enough to parse by hand and to give friendly messages.
  • ElaraCheck walks the tree with the robots' manifests in hand: unknown parts, missing or wrong units, abilities the robot lacks, speeds over the limit, targets inside no-go zones or out of reach. It collects every error, not just the first.
  • The compiler flattens the tree into a robot-neutral instruction list; the runtime follows it, plans detours round zones with Dijkstra, and re-checks the safety rules before every motion.
  • Adapters turn each instruction into the robot's own language: URScript for UR arms, rosbridge and Nav2 for ROS 2, GPIO for Raspberry Pi, a C++ sketch generator for plain Arduino, and the Arduino Bridge for the UNO Q.

The whole thing is dependency-free Python, which is why the same compiler runs inside the browser through Pyodide: the playground does not have a simplified URITP, it has URITP.

For the AI layer we made one rule and never broke it: the model is an untrusted author. Whatever it writes goes through ElaraCheck like any other program, with at most two chances to fix its errors. A spoken request can never make a robot do anything a carefully written program could not.

A conformance suite of 49 small programs states exactly which instructions a robot must receive, or which errors must be raised, so "supports URITP" means something testable.

Challenges we ran into

  • Units are harder than they look. mm/s must match before mm, min before m, and 10cmx must not become 10cm then x. Getting this right in the lexer, and doing full dimensional analysis in the checker (now > 5cm is "cannot compare Time with Length"), took longer than the parser.
  • "Nothing moves" has to be literally true. It is easy to check a program; it is hard to guarantee no instruction leaks out before the last error is found. We separated checking from running completely: the runtime never sees a program the checker did not pass.
  • A browser has no threads. parallel blocks run branches in threads on a laptop; in Pyodide they run one after another, and the page had to stay honest about it.
  • Hardware you cannot un-move. On the UNO Q, URITP runs on the Linux side and talks to the microcontroller over the Bridge. If the Linux side crashed mid-move, the motors would keep going. So every move carries its own time limit: a move cannot outlive its permission.
  • The demo. No wheels on the day, so four LEDs stand in for them. It turned out to be the clearest demo of all: you can see each instruction land.

Accomplishments that we're proud of

  • One program, four lines, running unchanged on the simulator and on real hardware.
  • A program with seven deliberate mistakes rejected with seven clear messages and the line nothing was sent to any robot.
  • Type 90kg instead of 90deg on stage: refused, nothing moves. That is the whole thesis in one keystroke.
  • A full compiler and checker that fit in a browser tab, with no install and no login.
  • Speech in five languages feeding a checker that treats the AI as untrusted.
  • A written standard with a test suite, not just a demo.

What we learned

  • A small language is a feature. Because URITP can only say robot things, every program can be checked completely before it runs. General-purpose languages cannot promise that.
  • Units are types. Making 0.5m a token instead of a comment changed every stage after it.
  • Fail rather than guess. Every time we were tempted to let the robot do "roughly" what was asked, we found a case where that would be the dangerous choice.
  • A standard is its tests. The conformance suite did more to make the language precise than any amount of documentation.
  • Robotics is a maintenance problem as much as a programming one. With $R$ robots and $T$ tasks you maintain $R \times T$ programs today; with one language you maintain $R + T$ things: for five robots and twenty tasks, 25 instead of 100.

What's next for URITP (Universal Robot Instruction/Translation Protocol)

  • Classrooms and labs first: a lesson pack and teacher dashboard on top of the free playground, so a school can teach robotics without buying a robot.
  • More bodies: drones, robot dogs and humanoids through the same manifests and profiles.
  • Fleets and voice: many robots in one program, spoken instructions on the shop floor.
  • A certification mark: a robot that passes the conformance suite can carry "URITP Certified", the way hardware carries "Wi-Fi Certified".
  • Learning from runs: every run is logged in one format whatever the robot; we have already prototyped a model that predicts, before a program runs, how likely it is to go wrong.
  • The safe robot API for AI: when AI agents start driving robots, they will need a language that is checked before it moves. We think that language is URITP.

Built With

Share this project:

Updates

Submission history