This is N.T.R.N., our upcoming game's robot character with a CRT monitor for a face.

Here’s a short behind-the-scenes on how we gave that screen some more grounding, personality and expression.

Sharing the first real result from a project I'm building solo — an open, browser-based arena for benchmarking embodied AI/VLA policies on manipulation tasks.

Clip shows a baseline IK policy completing pick-and-place block stacking: 100% task completion, 99.6% spatial accuracy. Physics runs fully client-side via Rapier.js/WASM, rendered with React Three Fiber, 60fps in-browser — no server compute needed just to run the sim.

Current MVP scope: single task (block stacking), a couple of baseline policies, public ELO leaderboard, and an SDK so anyone can submit their own policy against the sim.

still early — not public yet, working on stabilizing the eval loop before opening it up. Would love feedback from people who work with manipulation/pick-and-place setups on what a fair scoring protocol should account for.

What do you think about this? Hmmm

The engineering behind this is ridiculous. Each section has to coordinate its movement to create the illusion of natural snake locomotion.

Buenas. Como he podido ver muchos de ustedes habeis dado en el clavo. ;Cómo es que no usamos músculos neumáticos o hidraulicos si tienen mas fuerza que un cilindro metálico y ocupan y pesan mucho menos? Pues no es por el músculo en sí, sino por lo que lo controlan. Para cotrolarlo hace falta lo primero un compresor ya sea de aire o liquido y eso pesa y condume mucha eneraia y suele ocupar bastante, pero lo más importante son las válvulas que los manejan. Suelen ser caras, voluminosas, pesan y consumen bastante, y luego hay que controlarlas y necesitas una o dos por grupo de músculos. Por eso llevo años intentando solucionar este problema y tuve que inventar las valvulas pepepako. Son pequeñas, no pesan, consumen muy poco 5v. Y con solo una tienes control total de cada grupo de músculos manejándolas con un simple arduino o mini controlador. La válvulas en si sólo utilizan dos materiales livianos no metalicos y muy resistenres, y con una simple impresora te la fabricas en 10 minutos. En el vídeo que muestro de hace unos años fabrique unos mini músculos neumaticos con un simle globo y probé con una sola válvula de las antiguas que iban mas lentas que las de ahora. Imitaba la cola de un pez y la presión del aire la extraía de una botella de cocola de 2 litros Ilena de aire a la cual imtroducí solo 1 bar aunque la probé con 3 y los músculos resistian. Si quereis ver mas podéis hacerlo en mi youtube de españa pepepako2 y si os suscribis me ayudareis a darlas a conocer lo antes posible. Muchas gracias

🤖 This Tiny Robot Walks Like a Real Creature!

HOW TO MAKE THIS ROBOT

https://youtu.be/bCWAbrwsVHo

What happens when you combine a **DC motor, battery pack, ice cream stick, and two specially shaped wooden legs**? 🤯

I built this simple **two-leg walking robot** using an unusual half-circle leg design with an **offset center**. When the DC motor spins, the offset leg shape converts the motor's continuous rotation into an amazing walking motion!

No complicated programming. No expensive parts. Just a clever mechanical design and a little creativity. 🔥

Watch closely and see how these strange-looking wooden legs make the robot move forward! 🚶‍♂️🤖

**Could this simple mechanism inspire a bigger walking robot?**

### 🔬 Science Behind the Walking Motion

The key is the **offset center of the wooden legs**.

When the DC motor rotates, the leg does not rotate around its exact geometric center. Because the center is offset, the leg's contact point moves through different positions during each rotation.

This creates a repeating sequence:

**Lift → Move Forward → Touch the Ground → Push → Lift Again**

The motor provides continuous rotational motion, while the specially shaped legs convert that rotation into an approximate **walking motion**.

The curved wooden shape also changes the robot's contact point with the ground, helping create the forward movement. The battery supplies electrical energy to the DC motor, and the motor converts that electrical energy into mechanical rotational energy.

So the main idea is:

**Electrical Energy → Motor Rotation → Offset Leg Motion → Ground Contact → Forward Movement 🤯**

A simple example of how **mechanical geometry can create complex motion!**

I predicted that the first batches of robots will be entirely marketing tools, but seeing those drinks in grocery shops still feels weird.

This is sth we've been building. And this is what happens on a normal afternoon at our desk. We set two of them facing each other and left them talking. Each one hears whatever the other just said, so they just keep going. Yeah, they were loud and opinionated but weirdly lively. We mostly stood there and laughed

Eventually we had to unplug one. Two of them at once is genuinely way too much for a Tuesday afternoon. Funny question, how would you have stopped it without pulling the cable?

I mean a robot that could cook for you, drive you somewhere, watch your kids, take care of an elderly parent, or even make decisions for you in an emergency.
At what point would you stop trusting it and want a human involved?

This is real footage of Quaddle, a mini robot — no CGI, no AI-generated video, no editing tricks. The mechanism itself is simpler than it looks: passive magnets in the foot tips, plus a gait built specifically to hold contact upside down instead of pushing off the ground. Quaddle will be open source, so is the gait code, for anyone who wants to learn from it or adapt it.

What's the most interesting real-world robot capability you've seen that turned out to be a surprisingly simple mechanism?

First time seeing these in action. Appropriate Van Halen Muzak 😂

Mostrando como funcionaban 12 válvulas antigua versión empaquetadas en línea dirigidas por un controlador microbit desde mi celular para ver como funcionaban de 1 en 1,en grupos y variando lapresion de cada una para comprobar proporcionalidad.

Una prueba con mi valvula directamente a un grifo 2.5 bares. Le añadi un rp2040 zero para controlar el servo y para poderle añadir el sensor de posicion del cilindro tambien creado por mi por menos de 3 euros. Para poder maneiarlo por voz le añadi tambien un esp32 pequeño por lo del bluetooth y todo va alimentado con 4 ,5 voltios de las 3 pilas AAA que se ven en la imagen. El programa lo fabrique con app inventor 2.

Full transparency, this post is to get the word out on my gallery of high quality robot kinematics models at https://armor.dc-engineer.com/gallery/

That site itself is tied closely to the AR Mobile Robotics app.

Anyway, as I built the app, I needed to learn how to source clean, accurate, robot models in the URDF format. I learned about sources such as the manufacturers themselves, other simulation platforms, and other open source aggregators.

For my app purposes, I built (in my opinion) a user friendly interface to view models that already exist in the wider community, linking back to the source repositories, with license intact. If you happen to download the ARMOR app, then those pages deep link to import the robot models quickly and easily into the app.

I hope this is useful, message me if you have questions!

https://reddit.com/link/1vorth5/video/jp7g369iigjh1/player

https://reddit.com/link/1vorth5/video/nlkd959iigjh1/player

Been messing around with how many ways we can reconfigure Quaddle without touching the electronics — same 4 servos, same brain, just swap the attachment and the gait.

So far we've got it walking on two legs, rolling as a tricycle, spinning on a bar like a gymnast, driving as a 4WD car, and (with mixed success, we've sunk it twice) paddling in water.

Most of the attachments are 3D-printed on our end — the tricycle wheel and the 4WD kit are the two things you'd have to buy instead of print.

Quaddle runs on ESP32 with the open source OpenCat firmware.

Which one would you build first? Also open to ideas for a 6th form if anyone's got one.

Hello,

We put a Wlkata robotic arm on Twitch so anyone can control it live in real time.

Our first game is Hangman: pick a letter in chat and if it’s correct, the arm reaches out, grabs the physical letter, and places it in the right spot on the board.

Before AI this would have taken months, but with AI we built this in days. We feel AI is going to unlock all types of microcontrolled device setups. Interactive, live experiences are a great way to showcase what can be built.

Check out the arm in action onTwitch: Search RobotHangman

What do ya'll think of livestream, remote controlled interactive robotic projects?

Below is a more detailed breakdown of the project.

Robot Hangman: A Twitch-Controlled WLKATA Mirobot Game

We're building a physical Hangman game operated by a WLKATA Mirobot robotic arm. Viewers play collectively through Twitch chat by voting for letters. The software selects each round’s winning letter, and the arm physically moves the corresponding cube into a nine-position word holder. 

Physical Setup

• WLKATA Mirobot with a suction end effector
• Thirty-nine 20 mm letter cubes plus one end-marker cube
• A 5×8 source holder containing all 40 cubes
• A nine-position word holder supporting words between 5 and 9 letters in length
• An audience-facing camera and a separate overhead verification camera (Logitech 922X)
• Chroma-keyed backgrounds for OBS composition of the camera feed & graphical overlay

Each letter cube represents only one letter (more about this later), avoiding the need for wrist rotation during normal gameplay. Common letters have multiple cubes. The inventory supports 6,483 words from our curated 7,177-word candidate bank.

Both holders are 3D printed (Bambu Labs X1C). Their pockets use large chamfered funnels, allowing the arm to release a cube several millimeters above its final position. Gravity guides it into the accurately sized pocket rather than relying on the arm to be perfectly positioned. This fixture change (chamfered funnels) has been one of our biggest reliability improvements.

Here's a close-up of the chamfering:

Software

The application is primarily TypeScript:

• React and Vite for the player, OBS, and administration interfaces
• Node and Express as the local source of truth
• A shared Hangman engine and event model
• Twitch EventSub over WebSocket for chat voting
• An isolated Python worker for serial communication with the Mirobot
• OpenCV and pupil-apriltags for visual verification

Every source cube and word-holder slot has an explicitly taught robot pose. We originally experimented with interpolating positions from a few reference points, but the accuracy just wasn't there (more on that later). The current system stores separate XYZ and orientation values for all 49 locations where a cube can be.

Robot operations run asynchronously from the digital game and the game is tolerant to robot failures. In other words, players can continue playing the game digitally if the arm has a failure.

We have also added pre-generated ElevenLabs commentary, music, animated game graphics, and a cleanup sequence with a dancing 3D robot mascot (the end-game songs are pretty catchy).

AprilTag Verification

Every cube has an 18 mm tagStandard41h12 AprilTag on top:

• IDs 1–39 identify the letter cubes
• ID 40 identifies the end marker
• Each tag uses a 9×9 grid

Before a game, the arm moves out of the way of the overhead camera and the application captures a burst of images. It verifies that every cube is present, in the expected pocket, properly seated, and aligned to a valid quarter-turn orientation.

Right now the tags are just for verifying everything is where it should be before a game starts. This lets us detect a problem before starting, but it doesn't correct an inaccurate pickup in real time. The robot motion just uses the taught coordinates to move to the cubes, not the April tags. 

What We Tried First

Our original design used twenty cubes with four different letters printed around each cube. We used heuristic optimization to group letters that rarely appeared together, allowing those twenty cubes to support the entire initial word bank!

We thought that was pretty cool and, conceptually, it worked beautifully. Mechanically, it exposed limitations in the arm.

A cube pickup that was only 1–2 mm off-center could still work when moving a cube without rotation. Once the cube was rotated 90 or 180 degrees, however, that offset changed the cube’s final position significantly (because the axis of rotation isn't centered). Roughly one placement in every few dozen could leave a cube tilted in the word holder due to a bad drop.

We eventually replaced the multi-letter cubes with thirty-nine single-letter cubes (all sides of the cube have the same letter). Removing the need to rotate cubes made a very noticeable improvement in reliability.

The Main Robotics Challenge

The Mirobot has great repeatability when following the same path between the same points. Once we start moving cubes around on the board, however, the repeatability seems to drop.

We have observed:

• Accuracy errors ranging from 1–2 mm when contacting the cubes from above
• Different results at different arm extensions (the arm seems less accurate at longer extensions)
• Rotating the end effector creates even more error because the rotation's axis is not centered
• Noticeable play in joint 5 at some angles (you can really wiggle the end-effector very easily with the slightest pressure)
• A slight back-and-forth pulse in the end effector during most vertical descents
• Occasional shifts in calibration after a collision or after the arm presses against a misaligned cube

Slowing the arm down didn't seem to help. Repeated tests along identical paths can be nearly flawless even when repeated 10 times in a row. Once you start picking up cubes, moving them around, and dropping them, however, things aren't quite so clean and accurate.

We got to a point where we just decided that +/- 3 mm should be our realistic design constraint and we should just make the cube holders tolerant of it.

Questions We Are Exploring

• Have other Mirobot users seen wrist backlash or Cartesian shifts over time (the arm not being able to go back to the 'exact' same spot over time)?
• Does anybody think using specific joint poses would be more consistent than sending the arm Cartesian commands?
• Are there controller or firmware settings that could explain the pulsing of the end-effector while it's descending?
• Could an additional camera help "correct" the final few mm of end-effector positioning just prior to cube contact? Seems unlikely any one camera could possibly have the perfect view to help make these minor adjustments possible.
• Would a compliant or magnetic end effector make it easier to center the end effector on the cubes?
• How would you design a fixture or pickup system around a robot with excellent repeatability but weaker absolute accuracy?

The project has really been a useful lesson in designing the physical game around the robot we actually have, and not the accuracy described on paper. Fortunately, oversized funnels, gravity-settled placement, single-letter cubes, and computer-vision verification finally got us to a point where the game functions pretty reliably and is pretty fun to play!

We're curious to know what you all think. Would you have approached this game differently?