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.

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.

Most stacks work around this with interpolation and manual tuning, then spend months chasing an estimator problem that is really a clock problem underneath.

We ran into same thing building sensor nodes for edge VSLAM. Current firmware still leans on external clock to keep camera and IMU aligned. Next revision removes that dependency, each unit disciplines its own clock on the bus instead of trusting one outside reference.

Two units in the test setup below, same mechanism scales to more nodes on one bus.

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.

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.

Our Autonomous Lamp

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.

The 1st prototype

The final design

What's inside the Lamp

3D printed parts

Few details on the robot itself:

Jetson nano controlling servos via maestro servo controller over UART. The whole thing is powered by 4500 mAH battery at 35C via a buck converter.

Direct Perception Control Model / SYMBIOSIS Research

Do you think this is legit? Of course, the video is heavily edited, but could the the robot actually drive the kart in full autonomy?

The company seems to have come out of nowhere, I am voting for fake, what do you think?

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.

Humans can study suffering endlessly and still learn to ignore it.

My thinking/concept is ..
When a homemade robot recognizes some of the worst this world has to offer, including mass killing and sexual violence in eastern DRC, while the rest of the world keeps looking away, the machine becomes the messenger.
I did not know about it until the robot told me. Not because the story was unavailable, but because the algorithm never put it in front of me.

This robot has been my learning project the past couple years I have been posting on this group

[deleted]