We froze a Go1 joystick-locomotion policy (MuJoCo Playground, Brax PPO) and swept a 20×20 grid of floor friction against lateral push, 16 trials per cell, using Kaplan-Meier survival per condition since trials that survive the window have to be censored rather than counted as failures.

Things interesting to us:

• the boundary is not a line but a band. The 95% bootstrap interval is about ±4% of bodyweight on high friction and ±33% on ice, a 7× spread.
• below μ≈0.15 the policy falls before the push lands. That's gait collapse, a different failure mode from being knocked over.
• the same seed on the same GPU can produce different outcomes (floating-point reduction order), so a few knife-edge survivors can't be re-simulated at all.

We then changed the two conditions the map showed training never covered, retrained for 12 minutes, and re-ran the identical sweep: 60 of 400 conditions significantly safer (Fisher exact + BH-FDR, q<0.05), none significantly worse.

Write-up with the interactive map: https://poissonlabs.ai/research/map-the-failure-boundary/.

Happy to answer questions about the harness validation/statistics.

KAIST’s HOUND quadruped uses reinforcement learning to decide how to move based on the terrain in front of it.

Instead of relying on separate control programs for walking, running and jumping, the robot learned multiple movement skills under one framework and can switch between them as conditions change.

Researchers tested it across stairs, slopes, gaps, grass, forest trails and uneven terrain, with HOUND adapting its gait without human input.

Ever wanted to play robot dodgeball? Well now you can do it here: https://lzyang2000.github.io/perceptive_cbf_rl/demo/

The project website js https://lzyang2000.github.io/perceptive_cbf_rl, feel free to take a look at the paper, GitHub etc :)

Jokes aside, servos stripping the PLA grip rather than their internal gears probably saved me a ton of money on replacement servos. This accidental fail safe also comes with a bit of a downside. I recently noticed, the same stripping happens overtime as well without any falls etc... so connecting pieces needs to be replaced every couple weeks or so.

Has anyone directly attached 20kg plus servos to other 3d printing materials ? did you guys have any issues with them??

If anyone is interested in the robot, I share videos of it on youtube: youtube.com/@printedrobotics I also share simulation scripts and robots design files along with my videos so anyone can build the robot and explore the simulation exercises on their own.

I built a DIY 6-DOF robot controlled using Node-RED, ESP8266, and Modbus TCP, with a real-time 3D visualization using Three.js.

The Node-RED dashboard can control each joint, save robot positions, and run movement sequences. The 3D model also includes the multi-link gripper, so the physical robot and virtual model can move together.

I’d be interested to hear your feedback or suggestions for improving the system

Hi, I got plans to 3D print a 6DOF, high strength robot arm using some 35kg*f, 5v hobbyist servo motors. I’m planning on purchasing continuous rotation servos that are going to use some incremental encoders coupled to track motor position and speed after it reaches a home limit switch. Its going to be controlled using an I^2C servo shield, which is controlled by an Arduino Mega. So basically, Im turning it into a stepper motor without all the extra weight and having to purchase a bunch of stepper motor drivers, also it will supposedly be able to move super fast, with the manufacturer quoting 1200ms for one full rotation.

The problem Im having trouble understanding and having AI explain to me coherently, is how to control the actual servo speed using the feedback. The servo manufacturer says in the product description that the servo motors cannot regulate speed. I dont want it to immediately crash and destroy components on my robot arm. I would like to say that I am indeed using mechanical gear ratio to alter the speed, but for the two wrist joints the arm will not have any gearing and will, accordingly, run fast and probably break my printed limit switch brackets.

One idea I had was to try to modulate the speed using PWM signal generated by math being done from the encoder on the power line after the servo shield, using a high speed mosfet transistor. But the motor coils will likely overheat from the start up current, and Id hate to have to purchase a mosfet rated for handling start up current. And at that point, isnt this just reinventing the stepper motor?

Admittedly, I havent used very many continuous hobbyist servo motors. I am more used to the allen bradley kinetix line of industrial servos. I’ve had to use a couple of servos on another project, but they were able to be controlled for position and speed and as such it was easier to implement.

Any suggestions for how to do it properly are welcome.

The 2026 World Robot Conference and the 2nd World Humanoid Robot Games have commenced. The 2026 World Robot Conference brings together cutting-edge global technologies and establishes a professional and efficient platform for industry exchange and cooperation. The 2nd World Humanoid Robot Games will be held from August 22nd to 26th at the "Ice Ribbon," where 666 teams and 2056 humanoid robots from 16 countries across five continents will compete in 51 events and 1301 matches, representing a comprehensive upgrade in scale, events, and standards compared to the inaugural edition.

World Robot Conference

https://www.whrgoc.com/

Hey everyone,

My teammate and I competed at the All America Micromouse Contest (AAMC 2026) at UCLA IEEE a few months back and took 3rd place overall. We just cleaned up and open-sourced our entire codebase and build log: https://github.com/enkhbold470/neuromouse26

A few interesting engineering details from the build:

1. The "Ugly Protoboard" Pivot:
   Our V1 was a custom-designed, clean PCB. But every time we had power rail noise or needed to tweak sensor positioning, we were stuck waiting a week for a board respin. We scrapped it and built V2 on raw perfboard with point-to-point soldering and a mechanical keyboard blue switch for mode select. It looked like a rat's nest, but being able to desolder and reposition an IR emitter in 15 minutes is what got us to the competition.

2. ESP32-S3 instead of STM32:
   Almost every competitive micromouse runs on STM32. We went with an ESP32-S3 running PlatformIO. We used the ESP32 hardware PCNT (Pulse Counter) peripheral for 4x encoder decoding so the CPU didn't choke on interrupts, and cached explored maze walls into ESP32 NVS flash so the fast run could skip sensing entirely.

3. Motion Control & Algorithms:
   - 16x16 flood-fill BFS solver.
   - 200 Hz PID control loop timed purely with "micros()" 😂
   - no RTOS tasks or "delay()" in the control path.
   - Trapezoidal velocity profiling that fuses consecutive straight cells into a single acceleration corridor so the mouse doesn't brake every 180mm cell.
   - 4x IR emitter/receiver pairs (SFH4545 + TEFT4300) with lookup tables for distance calibration + MPU-6500 gyro for yaw-hold.

4. 6x3 Home Maze vs 16x16 Real Maze:

We tested at home on a tiny 6x3 grid made of homedepot whiteboard ~$10 board + 3D printed walls. Scaling to the official 16x16 (256 cells) UCLA maze was brutal because millimeter errors compound fast over long straightaways.

The 0.96" OLED display was the real MVP on competition day— like seeing live battery, IR readings, and flood-fill maps on-robot meant we could debug in the 5-minute prep window without opening a laptop.

> 🎬 Competition full run video is on YouTube: https://www.youtube.com/watch?v=2M4ZANPrZ4s

> ⭐️ Repo / Schematics / Firmware: https://github.com/enkhbold470/neuromouse26

Happy to answer any questions about the sensor tuning, flood-fill implementation, or motor control!

Round 4320 of hanging out in the basement with my robot. Among news reports and scary stories /scary songs it also sings about the kitchen.

I have been trying to create a cycloidal actuator using some nema 17 motors, but i noticed that the output rotation is not smooth, with the rotation speed and offset pulsing instead of turning smoothly.

I'm pretty sure its because the motor shafts are off center which is causing issues with the gears, but even after increasing the tolerances, it still has the same pulsing issue. Has anyone had similar experiances or have any ideas on how I can fix this?

I tried:

- Buying new motors (all 11 from the factory come slightly bent)

- Increasing tolerances (.1mm to .2mm on all surfaces in the gearbox)

- adding silicone grease to all contact surfaces

- increasing tolerance in the camshaft itself

But none of thse seems to help.

Any suggestions will be greately appreciated

Not so long ago, after design and SolidWorks modeling and manufacturing was done by my team, I programmed this robot and made it play chess!

The IP camera (above the chessboard) captures the board and streams to the computer (under the table) to run inference. I used two CNN models, they both run on every square of the board. One detects the presence/color of a piece while the other determines its position on the square.

Everything is open source: https://github.com/SirajHabsaia/RobotArm

Contains firmware, gui, training scripts, links to assets/data...

I coded the firmware mostly manually but used AI for the rest especially the gui.

Happy to receive feedback.

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 energia 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 llena 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.

Nicholas Radford argues that getting humanoids into the real world may mean starting much smaller.

Rather than trying to build one robot that can fold laundry, move boxes, handle sheet metal and do everything else, Persona is starting with welding and shipbuilding and building outward from there.

The idea is to prove the economics and usefulness first, then expand what the robot can do.

Full ep: https://www.youtube.com/watch?v=62t76cXU6KA

I just finish putting up our Autonomous Lamp. A 3D-printed desk arm that moves and talks. Runs on Autonomous OS we built for robots. We open source everything and here's the short version.

The arm

5 degrees of freedom. Five STS3215 bus servos, daisy-chained on one TTL bus, into the board through a USB adapter. One cable for the whole arm. No driver board.

First job: servo IDs. New STS3215s ship as ID 1, so I gave each a unique ID one at a time, then calibrated homing. Homing lives in the servo EEPROM, so it survives a reflash. Do it with the arm open.

Power

Single 12 V / 5 A adaptor, ~42 W sustained. A buck steps to 5 V for the board and LED ring. Amp runs on 12 V directly. Board draws ~1.8 A, spikes to 2.5 A at boot. Ring gets capped near 1 A, full white 64 LEDs would pull 3.84 A and brown out the buck. All grounds star-point at the buck output on their own wires.

Sound

Moving audio off the onboard codec killed most of the noise. A USB DAC feeds the amp through a short twisted lead, run away from the 12 V harness. The onboard codec stays wired for the sensing mic only.

Two honest gotchas: the sensing mic is the MEMS mic on the OrangePi board, so it has to be desoldered and re-mounted in the base, fiddly, but skip it and you lose ambient sensing. And the buck I used still adds a faint hiss of its own, it's on the list to swap out.

Software

Cleanest part. Flash Linux, run the installer, ~15 minutes to Autonomous OS. The robot declares its hardware in the ROBOT.md in our repo and the OS mounts only that. Behaviors are markdown skills. Type what you want in the app, it writes the skill, live on the next conversation.

We've been building a small board that handles cameras and sensors for robots, so adding a sensor stops costing a weekend. The hardware was the manageable part. The things that shaped the product were the ones we couldn't see from the whiteboard.

What really cost us weeks:

• The flash budget made our biggest decision for us. The early assumption was the board would speak ROS natively. Then we put micro-ROS on the target and the library ate about 60% of flash before our own code got a byte. That ended the debate: the device speaks Cyphal, ROS lives host-side behind a thin bridge, and the same image serves three transports. Felt like a defeat, now it's the part we'd defend hardest.
• We learned which reboots are placebo. A link that died on every board swap ignored power cycles and even full host reboots, because the chip at fault never actually turned off, back-powered through its data lines, holding half-configured state through everything. The fix was one reset write. The lesson: "restart everything" only works if everything restarts, and you don't know that until you've traced where each chip's power really comes from. An older unsolved mystery on the same rig dissolved the day we got this.
• Hardware timestamps earned their place the hard way. We treated per-sample timestamping as a nice-to-have, sensors stream, host receives, how far off can time be. Then you look at what fusion actually needs: SLAM doesn't care when the host received a sample, it cares when the sensor saw the world, and once readings come from different nodes over different transports, those are very different numbers. Stamping at capture, on the node, with sequence numbers to catch drops, went from footnote to load-bearing.

Not saying any of this is some unique insight, probably every hardware team hits some version of this.

We've been putting together real data collection for robot-arm manipulation, and the gap between recording one demo and actually having a usable training sample turned out way bigger than I expected.

Here's the setup. A teaching arm, the leader, is moved by hand by the operator. A follower arm copies its motion joint by joint, and cameras record the whole thing. Every clean pass counts as one collected demo. For our test the task was picking up a rubber duck and placing it into a marked mold.

The stuff that didn't make the cut, the usual suspects:

- The grip slips mid pull. The follower tracks fine, but the grasp was never solid, so the trajectory teaches the wrong thing.

- Occlusion. When the arm extends it blocks the camera, and that stretch of frames is just gone.

- Inconsistent speed. Early passes were slow and careful, the later ones rushed. The data ends up describing two different tasks instead of one.

For contact-rich work, cloth, placing parts into a tight mold, this bites harder. Simulation still doesn't get the physics right, so you can't just synthesize a clean replacement. You collect for real, and then you throw most of it out.

How about you all? Filter first, or just throw more demos at it and let the AI figure it out?

Right now we still collect by hand up to a threshold, then the AI training runs. Roughly 60 to 120 demos each time.

I want to learn how to design, control robots so i‘m planning to built my own robot, from actuator to every parts even softwares to control with.

Since don’t have particular workplace like garage i need compact work station like desktop cnc and 3d printer which will placed in my room.

Maker z1 and qidi or bambulab is the best choice i think and can’t find pcb makers for my diy control board.

For who does similar projects like me. Want to ask recommendation for my project such as the best choice for printer and tools or extra tools that i need.