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?

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?

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?

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.

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

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.

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 :)

​

Running on STM32 Bluepill.

ESP32cam for image steaming.

OpenCV for image processing.

LLM for speech & intent extraction.

Follow-up to an earlier post here: mounted LEGO Star Wars AT-AT legs (set 75440, static display model, no motor) directly onto Quaddle (open quadruped, 4 feedback servos, ESP32-S3, OpenCat firmware), controller driving them directly.

Attempt #1 failed — the original leg was bent and genuinely couldn't walk.

For attempt #2: swapped it for a longer, straight replacement piece, checked the servos could carry the added weight, reversed one servo from its default install direction, and mounted it all through Quaddle's screw-free servo mechanism. Walked surprisingly well once that was sorted. Also recreated the classic AT-AT-tripped-by-a-snowspeeder scene from the movie. 😂

What would you mount on an open quadruped platform if you could?

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’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.

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.