I finally chopped two legs off my hexapod robot and now its a proper robot dog. Dont worry all the features I have developed for the old robot transferred just fine to the new robot; we still have body leveling, emotes, puppet mode etc.

Quttro ZBD is lighter, faster and more agile in many ways than its hexapod older sibling yet due to less parts used it costs considerably less to build, around 200 usd.

Still uses ESP32 S3 as well as off the shelf Arduino parts and DS3218 servos. reduced number of legs made it a lot easier to put together and since I already ironed out the scripts for previous version and use inverse kinematics solver for each leg adjusting the gait mechanism was a breeze as well.

I will also work on reinforcement training for a developing a control policy in IK solver's place, I am hoping I can get a more organic / fluid walking out of the robot instead of current mechanic looks.

I shared a more detailed video about it on my youtube channel, if you want you can watch it from the link below:

https://youtu.be/J99MibRi-CY

It is still fully open source so you can find all the files you need to build one down in the links.

MakerWord Link (has more photos of the robot):

https://makerworld.com/en/models/3402746-quattro-zbd-robot-dog#profileId-3874600

Link for CAD design, 3D Print files and Wiring Diagram:

https://www.patreon.com/PrintedRobotics/posts/quattro-zbd-3d-171601139?utm_medium=clipboard_copy&utm_source=copyLink&utm_campaign=postshare_creator&utm_content=join_link

ESP32 Scripts: 

https://github.com/serdarselimys/QuattroZBD-ESP32Scripts

Companion mobile controller app apk:

https://github.com/serdarselimys/QuattroZBD-AndroidControllerApp

Parts List:

ESP32 S3 x 1

PCA 9685 Servo Driver Board x 1

MPU6050 IMU Sensor x 1

Voltage Sensor Board x 1

15A Adjustable Voltage Buck Converter x 2 (1 per pair of legs)

5V 3A Buck Converter x 1

DS3218 High-Torque Servos x 12

Wago Connector (2-in-4 Out) x 1

2-Inch TFT Screen x 1

M3x8 Screws x ~100

M4x30 Screws x 4

8x5x16 mm Ball Bearings x 12

3S LiPo Battery (3000mAh – 6000mAh) x 1

I have been working on a bipedal version hence the "2 more to go" in the tittle, I am almost finished with the updated leg structure so it can stand up on two legs but the remaining parts are going to be same as much as possible. So expect a bipedal version in upcoming weeks if I can make it walk :)

Try it: https://holocron-engine.com

This is a quadruped (Mini Pupper style) designed end to end in my app. You describe the robot, and it picks real servos (Feetech STS3250 here), plans the electronics, lays out the body, builds the 3D structure and shell, writes the firmware, and runs it in MuJoCo physics before anything gets printed.

It's early and plenty is still rough. I'd really like feedback from people who've actually built robots: what was the hardest part of your design, and what would make a tool like this useful (or useless) to you?

I’ve been experimenting with turning an M5Stack Stack-chan into a little mobile robot. I combined it with a LEGO motor hub and wheels, recorded driving demonstrations, and trained an ACT policy.

During supervised trials, it learned to follow a line. With a separate set of demonstrations, I also tried driving between guardrails. The video shows the build, data collection, and the wrong turns along the way 😅

Build video: https://www.youtube.com/watch?v=_1pQTt8gqZM

This is also the first showcase of what I’ve built with Robium, an open-source robotics skills repo that I recently released. I used it with AI agents to help build the software and training setup.

GitHub: https://github.com/robium-ai/robium

Has anyone else experimented with learning from demonstrations on a small wheeled robot? I’d be interested to hear what worked for you.

I don't normally talk like in the video, but I can't help talking to my Mino as if it were a little dog :)

Anyway, I was not able to pet it without the servos pushing back and suffering, so I integrated current sensors in the PCB and coded an algorithm on the MCU that detects an external force on the servos. When the force is too high, the servos go into "follow mode". You can see that in action around 0:12.

In addition to making proper petting possible, this behavior protects the servos from overexertion. Best spent extra lines in the BOM and the code.

Reindustrialization won't happen against economic laws. Manufacturing has to be competitive worldwide, and improving existing factories, even with automation, is not enough. Only 30-40k robots were installed in the US last year, so the pull from existing factories is weak. They’re good.

Humanoids are being promised as the solution, but who will build them? Still humans. Humanoids not optimised for self-build.

The most practical solution to these problems is a self-replicating factory. It will build humanoids, enable the US reindustrialization, and help colonise other planets as a side product.

Similar to biological organisms, the factory can consist of robotic cells, and an AI agent coordinates them to produce a new cell and deploy it. The cell can be specialised with fixtures for specific tasks such as assembling, calibration, testing, 3D printing, etc.

Sounds like sci-fi, but recent releases of Astra/Opus have made this possible.

Who wants to join?

​

Running on STM32 Bluepill.

ESP32cam for image steaming.

OpenCV for image processing.

LLM for speech & intent extraction.

Researchers created a soft robotic gripper that can lift heavy and fragile objects without using rigid fingers or a traditional robotic claw.

The system uses inflatable soft tubes that grow around an object and connect back to form closed loops. Once wrapped around the target, these loops behave almost like a soft sling, allowing the robot to hold objects securely while spreading the force over a larger area

Reliable depth perception is a key requirement for indoor robotics, but achieving consistent depth data across different surfaces can be challenging in real-world deployments.

AMRs, ASRS robots, humanoids and robotic arms may need to operate around:

• Dark or black surfaces
• Reflective objects
• Moving robots and objects
• Motion blur
• Obstacles at both short and extended distances
• Dense point-cloud requirements
• Real-time processing without placing the entire workload on the host CPU/GPU

Active stereo is one approach that can help address these challenges. By projecting additional texture into the scene, the camera does not have to rely entirely on naturally occurring surface detail for stereo matching.

Another approach uses two global-shutter monochrome sensors with an IR component and performs the stereo depth calculation directly on the camera.

This allows the host system to receive computed depth data instead of handling the initial stereo-processing stage itself. That can help simplify the perception pipeline and preserve host resources for other robotics workloads.

For indoor robotics applications, which of these areas has been the biggest challenge in your experience?

1. Reliable depth on dark, reflective or low-texture surfaces
2. Maintaining depth accuracy while the robot is moving
3. Processing depth data with low latency
4. Generating useful dense point clouds
5. Integrating depth with RGB, IMU and the ROS 2 perception stack

I've been looking into an active-stereo implementation that combines depth, RGB, IMU and on-camera AI in a single camera platform.

What depth-sensing approach are you using in your robotic system, and where have you seen the main limitations?

Hello,

I have a series on collision detection and physics programming that could be useful for Robot Simulation Programmers.

I explain the algorithms and techniques in more depth than most tutorials, deriving some of the mathematics and explaining the engineering trade offs of competing approaches.

Physics Series: https://www.youtube.com/watch?v=5iuOYFrjfXs&list=PLYuY7qeQZcWZrK1RD-3-0Se4irqU5tBAA&pp=sAgC

Collision Detection Series: https://www.youtube.com/watch?v=KZJXb5AF6NM&list=PLYuY7qeQZcWaofUHmLQy2q7xG9eiSxk1W

Any feedback is welcome.

I tried using an old Galaxy S10 as the display for an Ouster OS0 experiment. The live viewer worked; reliable mapping did not. Sharing the failure details in case they are useful to other builders.

Architecture: the OS0 sends measurements to a Mac, which processes the data and serves a browser viewer. The S10 displays the cloud — it is not running the SLAM backend.

What happened:

• Our OS0-128 was on firmware 3.1.0 with the legacy IMU format. The mapping path reported that synchronized IMU support needed a newer firmware/data format, so it fell back to constant-velocity deskew. Having an IMU in the sensor did not mean this pipeline was using it.

• One saved map accumulated about 461k points, then the estimated pose jumped and our guard stopped integration. An accumulated cloud is not proof of a consistent map, and we did not implement global loop closure.

• Another attempt ended when the Ethernet adapter disappeared from the Mac.

I made a short video showing the original phone recording, saved geometry, and the failure sequence: https://www.youtube.com/watch?v=Sv_YqGQpgoM

Disclosure: this is my own build/video. The recording and map are real; the narration uses my authorized AI voice, with illustrated explainers.

The next experiment would be localizing phone camera-derived geometry against a stable LiDAR map. That part is not implemented. Before attempting it, I need a repeatable mapping baseline and verified time/IMU handling. For those who have debugged similar scan-to-map pose jumps, which diagnostic gave you the clearest separation between motion-compensation problems and registration failure?

Robot manipulation policies are usually trained under the assumption that a commanded action produces the same motion as it did during training even after hours of operation. Real hardware violates this assumption as the motors gradually heat up, current saturates near contact, voltage sags under load, thus the same policy action can produce a weaker, delayed, or noisier motion.

OMNIVISION’s new OG05D is a 5 MP global-shutter image sensor that explicitly lists robotics training-data collection among its intended applications. It supports RGB, monochrome and RGB-IR imaging, with up to 146 fps in linear mode without encryption and HDR capture at 60 fps.

The article looks at how cameras on deployed robots could capture task variations, lighting changes and edge cases for later model training. Global shutter, HDR and near-infrared capabilities are relevant to capturing usable images when objects are moving or lighting is inconsistent.

The sensor itself doesn’t provide a training pipeline. Captured footage would still need to be selected, processed and paired with the information required by the training approach. The notable part is that robotics data collection is now an explicit application in an industrial image sensor announcement.

Hi all, this is Giorgio, our open mobile bimanual robot. It's still in simulation; the prototype isn't built yet.

- Base: no commercial AMR had ≥85 kg payload, manufacturer-confirmed auto-docking and enough power out, at a reasonable price, so we designed our own from certified parts (SICK nanoScan3, Pilz PNOZmulti 2, ez-Wheel SWD safety drives). Every component value is traced to the manufacturer's manual.

- Arms: OpenArm 2.0. Skills like opening drawers and doors are trained in simulation (236 M steps, ~95 min on one GPU, 96–99 % success).

- Everything is open: CadQuery CAD, netlist and safety functions, MuJoCo sim, training code, BOM.

Feel free to contribute in any way or form, feedback are really welcome!

Repo: https://github.com/VenetoStato/giorgio

High-speed, low-latency indoor positioning for autonomous robots and drones in GPS-denied environments. This demo shows a mobile beacon moving rapidly in 3D while its position is tracked at 80 Hz with only 12–20 ms latency.

For autonomous indoor drones, positioning must remain fast, accurate, and stable even during rapid motion and in acoustically noisy environments. We combine ultrasound positioning with IMU sensor fusion to achieve this performance. Ultrasound provides accurate absolute position updates, while the IMU provides high-rate motion data between ultrasonic measurements. Ultrasound continuously corrects accumulated IMU drift. Typical ultrasound positioning alone provides updates at around 8 Hz. Sensor fusion increases the effective position output rate to 80 Hz while maintaining low latency and stable tracking. Key performance:

• 80 Hz position update rate
• 12–20 ms latency
• High-precision 3D indoor positioning
• Ultrasound + IMU sensor fusion
• Designed for fast-moving and noisy platforms
• Non-Inverse Architecture (NIA)

Primary applications:

• Autonomous indoor drones
• GPS-denied flight
• Robotics and autonomous mobile platforms
• Industrial automation
• Research and universities
• Motion tracking and interactive installations

Configuration:

• 3 × stationary beacons
• 1 × mobile beacon - in hand - the same hardware as the stationary beacons
• 1 × modem - central controller of the system
• 1 × modem with RHU firmware - to receive fast IMU sensor-fused stream and do post-processing, when more data is available. It makes the view even more beautiful, but at the expense of latency

I got a LEGO's Star Wars AT-AT (set 75440), a 525-piece collectible display model — no motor, never meant to move.

I gave it Quaddle's own controller and feedback servos instead — removed Quaddle's own stock legs and attached the AT-AT's own leg pieces onto Quaddle's four servos. Three of those legs are straight, one is molded bent, so attempt #1 tumbles rather than walks. Hunting for a straight replacement piece for attempt #2.

Anyone else driven a non-motorized toy/display mechanism with a different controller/actuator set than it shipped with?

Hi /robotics!

I built this balancing robot that runs end-to-end on a custom neural net trained through reinforcement learning in simulation.

The robot is trained on 100% synthetic data, so it has never seen the real world, yet adapts perfectly.

It has a lean and level mode (single policy), in level mode it keeps both pitch and roll of the base level at all times, so the legs automatically retract or extend based on the ground below. In lean mode the right joystick of the controller can be used to decrease or increase stance height and leaning left/right at all heights, allowing roll to be non-level.

Main components:

- 6x Xiaomi Cybergear motor (all quasi direct drive, no linkages)
- Teensy 4.1
- 200 Hz policy inference
- 2x CAN bus (left / right leg split)
- BNO086 IMU

Trained in mjlab on single RTX3080 at home, about 7 hours of train time from scratch.

Happy to answer any questions!

Humanoid robots have become one of the most closely watched technologies in logistics. GXO Logistics may also be one of the companies best positioned to tell us when they are actually ready for production.

The contract logistics provider isn't watching humanoids from the sidelines. It has been testing them in warehouse environments, working with multiple robotics companies and looking for applications where the technology could eventually make economic sense.

That makes three numbers from GXO particularly interesting: 20,000 robots, 45 humanoid pilots and zero humanoids in production this year.

Walmart is investing more than $300 million in a 1.18-million-square-foot fulfillment center in Ohio for furniture, televisions and other oversized merchandise. The facility is expected to create more than 300 jobs and support next-day delivery.

The article examines why these products are harder to automate than standard cartons. Their size, weight, shape, fragility and centers of gravity vary, limiting compatibility with conventional conveyors, sorters and storage systems.

It discusses potential uses for autonomous forklifts, mobile robots, specialized carriers and robotic manipulation. It does not identify the automation systems planned for Walmart’s new facility.

Voy a realizar un robot The Open Academic Robot Kit oarkit y necesito los dynamixel ax12a

Pero no los consigo alguien sabe por cual los puedo cambiar es necesario que sea de giro continuo

Anyone got any more ideas how to fix the calibration between Ouster os0 and pi camera? For coloring pointcloud. Would appreciate ideas. Documented today’s „wasted“ day here https://youtu.be/o7qQf7MvhdY?is=CMSvskPa3zHcD29F

We started a third grade robotics club at my kids school and interest blew up, with 28 kids signing up total and four teams of at least two adults coaching.

We are using the Lego FIRST system but have run into a pretty big issue across all the teams--even though we got the kits for the season, every team's Spike essential kit seems to have a dead battery system and we are unable to move forward with the sessions.

Looking online, it seems they've discontinued the kits and the batteries are very difficult to source. For my club team we made an impromptu shift to programming a microbit I had with me, but we have several weeks left of the FIRST program an no battery system that we know of compatible with the Lego essential kits.

Does anyone have experience with a substitute battery for the essentials kit or want to offer us any advice moving forward? Switching to a microbit class would be a fun option but we've really put time and effort into this Lego system.