🤖 Robotics

From Eren Chen on 𝕏: https://x.com/ErenChenAI/status/2067833855017353691

Hey r/robotics, Wanted to share my latest budget mobile robot build. The goal was to keep it under $250, so instead of buying an expensive LiDAR setup or dedicated depth cameras, I rigged up 4 cheap smartphones to stream video data. I’m running the streams through Depth Anything v3 (DA3) to estimate the depth maps, and honestly, for a "poor man's LiDAR," it’s going incredibly strong. The issue I'm running into: Since DA3 outputs relative/monocular depth maps, I’m struggling with absolute scale calibration. Right now, the robot thinks walls are further away than they actually are. It knows where the obstacles are, but the metric distance is skewed because DA3 doesn't have real-world depth data. I want to fix this by adding a hardware sensor to act as a "ground truth" anchor to correct and scale the DA3 depth data in real-time. Has anyone here tried using a ToF (Time-of-Flight) sensor or an Ultrasonic sensor to handle this kind of depth correction? Would a single-point distance reading be enough to dynamically scale the relative map, or is there a better way to do it? If anyone is curious about the hardware or wants to check out the setup, I put the specs and documentation here and the chassis CAD files here. Looking forward to hearing your thoughts on how to fix the depth scaling!

I've been experimenting with converting ordinary third-person videos into humanoid motion data. This demo includes several motion categories: • Acting • Sports • Combat • Dance The motivation is not animation alone. Recent humanoid robotics work increasingly relies on large-scale motion datasets and motion priors to improve movement quality, robustness, and generalization. Projects such as NVIDIA KIMODO also show the value of scaling high-quality motion data for downstream humanoid motion generation and control. This made me wonder whether ordinary videos could become a low-cost source of motion data for humanoid systems. There is already a massive amount of human motion available in online videos. If useful motion can be extracted reliably, it may help expand humanoid motion datasets beyond traditional mocap pipelines. For this experiment, I focused on: • Foot contact stability • Reduced foot sliding • Natural balance and movement dynamics • Consistency across different motion styles The long-term idea is: Video → Motion Data → Motion Models → Humanoid Control For anyone interested in testing their own clips, I made a public demo available here: huggingface demo I'd love to hear thoughts from people working on humanoid robotics, motion generation, imitation learning, or robot locomotion.

If you not familiar with the library, its basically a Rust implementation of behavior trees which are a great way to build deterministic AI — they're widely used for things like robotics, game NPCs and any agent that needs predictable, debuggable decision-making. We just introduced python bindings and a live view of the behavior tree. Also, we have added tons of new examples to get you going. For more, see: github: https://github.com/sollimann/bonsai pypi: https://pypi.org/project/bonsai-bt/

Disclosure: I work with a commercial robotics data collection team. This is not a sales post. I've been comparing different human-demonstration formats for robot manipulation, and I'm curious which configuration researchers find most useful for initial testing. The main options seem to be: • Egocentric video only • Egocentric + two wrist cameras • Task and step labels • Country and collection metadata Egocentric-only data is easier to scale, but hands often block the object. Wrist views improve grasp visibility, although synchronization and motion blur create extra problems. We're considering releasing a small free public evaluation sample from the US, UK and Australia. It would require no signup, email or contact details. Which format would be most useful for testing an existing manipulation or imitation-learning pipeline? Also, what minimum information should be included: camera calibration, FPS, task labels, timestamps, licensing documentation or failure examples? I can share the public sample in a follow-up only if the moderators confirm that it is appropriate.

Everything works fine, just for these maze of cables, I have run out of ideas, how do I actually get rid of the mess? I am using 2 16 channel servo drivers. all 18 (plus 2 for camera) are connected to those 2. I am using a buck converter on top and a 4200 MAH battery. The raspberry pi relays all info to my laptop and it control the motion additionally i also need space to put an imu sensor over it. Help !!

It seems that everyone around is building robots these days. Overcoming my laziness, I decided to also build my own small robodog, and I'm sharing the result of this project, which took me quite a bit of trials and errors during long evenings. All parts were designed from scratch. Everything that is plastic was 3D printed. Everything that isn't plastic was sourced from generic stores - there are no custom CNC orders here. The main SBC is a Radxa Zero 3W running Ubuntu 24.04 with ROS 2 Jazzy. The servos are powered by a Sunflower PCA9685 driver board. There are two separate power rails: 5V for the Radxa and 6-7V for the servos. The trotting gait is shown in the video. I'm currently using an inverse kinematics algorithm, but my long-term plans include Tensor Lite and trained neural networks for skills. The project is still ongoing - I have so many things to try and learn. But it is solid enough as a good foundation for future iterations.