Gemm

The problem

A refinery has rounds that someone walks again and again: go to each piece of equipment, read a pressure gauge, write it down, sometimes turn a valve. It isn't complicated work. It's work that has to happen at any hour, in places where just being there is the risk.

Gemm wants a robot to walk that round, with a person always in control from somewhere safe. We started with inspection rounds and gauge reading.

How we got here

It started in March 2026 as our final-year ICT research project at ORT. The first robot wasn't a humanoid: it was a Unitree Go2 robot dog. And it came with a catch: our model can't be programmed. It has no SDK; the only way to drive it is Unitree's official app.

So we made the robot believe it was talking to its app: we built our own system that communicates with it just like the official app does. The first thing we did with that was drive it from a laptop keyboard.

Then we took it to Gemm Blocks, a Scratch-like block editor: you build the program and the robot runs it. I added 13 new actions and fixed how speed is controlled. We showed it at a hackathon and ended up teaching a class at ITBA with the Go2.

Meanwhile we went to talk to the industry. The original idea was a humanoid turning valves during a gas leak. After meeting YPF and Pan American Energy it changed: the value was in walking, measuring and warning before something happens, with a person stepping in remotely when needed. I wrote about it in a note.

When the G1 arrived —1.30 m, 29 motors, hands— the round stopped being something to talk about and became something a robot could actually attempt.

What I built

1. Virtual reality teleoperation

An operator puts on a VR headset, moves their arms and hands, and the G1 reproduces them in real time. Everything runs inside the robot itself, with no computer next to it.

We started from the base Unitree provides. What took me months was making it work every time, not just in a demo:

• —Not depending on the venue's wifi. The robot runs its own network, so it works the same in the lab, at an event or in a plant.
• —Letting the operator see well. Video reaches the headset in high definition and smoothly, without loading the robot.
• —Not freezing. I found and fixed the failures that froze the video or left the robot without a connection.
• —Being easy to use. It starts with one button, there are a few seconds to put the headset on, and another button stops it and brings the arms back home.

2. The robot panel

A web page that runs on the robot and opens from any phone nearby. It shows the battery, the state of the motors and the live camera, and lets you talk through the robot and listen through it.

• —Spanish voice, offline.
• —Remote control from a phone, designed so the robot stops by itself if the connection drops. I haven't tested it with the robot walking yet.
• —Alerts for battery and motor temperature, on screen and by voice.
• —Stuck-teleop warning: it detects when the robot stops following the operator. I'm calibrating it with real sessions.

3. Manipulation with the Dex5-1 hands

A module so the robot can grab objects without breaking them, adjusting the force to the material, with 137 tests. It's finished; it still has to be tested on the robot, which doesn't have those hands installed yet.

What went wrong

This is the part that taught me the most, so I'm leaving it in plain sight:

• —The robot lost its connection every five minutes. I spent weeks looking in the wrong place. How I found it.
• —The Parque de la Innovación demo failed right before going on stage. Both causes showed up in the days after. The full note.
• —The LiDAR sent no data. The manufacturer's software didn't recognize our sensor model; when I managed to talk to it directly, the sensor itself reported a hardware fault. It went to repair.
• —The left hand doesn't respond. It's a physical fault; I diagnosed it as far as software can go.
• —Turning the waist with your head: six live tests and it never moved. I dropped it.

Where it stands

• VR teleoperation of arms and hands●Validated
• Robot panel●Validated
• Live 3D and 2D mapping (Eitan)●Validated
• Gauge reading◐Prototype
• Point A to B navigation○Simulation
• Inspection rounds and valves·Next

I use the same states as gemm.ar: something is validated only if we saw it work on the robot.

The team

There are four of us: Eitan Feldman (systems and AI: the data bridge, mapping and the dashboard), Martín Durán (UX/UI design), Matías Tenenbaum (research) and me. With the support of Darío Mischener, head of the ICT track at ORT, who got us the robots and the lab.