Everything (including RealSense SDK) is now running on GPU. Switched out QWEN for BLIP-CUDA and AI is now describing its surroundings including depth at 75-100ms per inference! That's 10-12 VLM scene inferences per second! Source code in comments... 🎸⭐️

Hello everyone,

I'm happy to share Zig, a two-leg, two-wheel self-balancing animatronic robot, inspired by Disney's BD-X.

Unlike a fully-legged BD-X, Zig rides on a two-wheel balancing base. That's a deliberate choice: wheels need far fewer motors than articulated legs, which makes the robot cheaper, lighter, and much simpler to control. A real walking legged robot is a whole project on its own. My focus here is the "animal" side — I want Zig to actually feel alive, not just to move.

It's a fully homemade design. I wanted something small and compact: lower cost, easier to transport, and more practical overall. Keeping it small was a real constraint, since this version has no custom PCB yet, so managing space was a big part of the challenge. The robot is around 23 cm tall and weighs 1.172 kg.

Inside:

- 9 motors — 2 legs, 2 wheels, 3 neck, 2 antennas
- 1 Raspberry Pi 5 (orchestrator)
- 2x RP2350 (Xiao RP2350 + Raspberry Pi Pico 2)
- 1 Arduino Nano Every
- A camera and a distance sensor in each eye
- Speakers, microphones, touch sensors, and LEDs

The architecture is one orchestrator (the Pi 5) with a slave controller per subsystem: torso, legs/balance, and head. Right now I'm building the backbone — getting each part working reliably before I start layering in the "life" (expressive behavior, lighting eyes, and more).

I control it through a Python interface running on a Legion Go, over WiFi.

Over the next few weeks I'll publish full documentation and update it regularly. It's not open source for now — that needs more time to do properly — but the docs will explain my design choices and the overall system.

Happy to answer any questions!

(English isn't my first language — I used AI to help correct the text.)

In this tutorial I am installing a portable battery on my MechSoul. (A MechSoul is to a robot what a CyberDeck is to a computer) A robot you build, personalize and customize yourself. In this tutorial I am powering my MechSoul with a portable charger I bought online, because it's quicker and safer than designing a custom battery solution as I explain in the video. So instead of designing a PCB I head to my 3D printer to build a battery mount.

If you want to follow along with to the code and 3D files you can check out the project GitHub

saw this video from WRC 2026, and the way this robot moves is so similar to a human’s movements! It’s probably teleoperated or programmed, but the movements are so realistic, like a real human

I ran a test over 20 trials to see how good the repeatable precision of my robot shoulder joint. I achieved an average repeatability of 0.22mm of precision.

It uses a capstan drive with low creep rope in-order to get low backlash and high precision.

I used a carbon fiber rods as the base and the rest is 3D printed. Built for under $200.

Chef Robotics CEO Rajat Bhageria thinks funding runway could become one of the biggest factors in determining which humanoid companies make it.

He points to autonomous vehicles, where companies spent years and enormous amounts of capital developing technology before reaching meaningful deployment. Waymo had Google behind it. Boston Dynamics has had Google and Hyundai. Tesla can fund Optimus from a much larger business.

That leaves companies like Figure and Apptronik facing a much tougher capital challenge as the technology and market mature.

Bhageria compares it to what happened with Cruise. Strong technology and engineering weren't enough once GM decided to pull back.

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

I’ve been working on something called RSim for a while now.

The idea is to make robot programming and motion generation a bit easier, especially for people building their own robots.

For this test, I used AI to generate a walking motion for a quadruped and then visualized the resulting joint movements in RSim.

The project is still pretty early, but I’ve also started doing my first sim2real tests. I can already send generated motion to real hardware and get the robot to move, but the motion transfer isn’t accurate enough yet, so I’m not showing that part for now. I’m currently working on things like joint mapping, calibration and getting the motion transfer more accurate.

One thing I want to clarify about RSim:

I’m not trying to build another MuJoCo, Gazebo or Isaac Sim.

Those are physics-based simulators and are built for things like dynamics, physics interaction, reinforcement learning, etc.

RSim is much closer to a kinematic robot programming and development tool, more in the direction of RoboDK. The main idea is to make it easier to create robot motions with AI, work with kinematics, map those motions to hardware, and eventually get them running on a real robot.

The workflow I’m aiming for is roughly:

CAD -> AI motion generation -> kinematics -> safety checks -> hardware mapping -> real robot

This is still very much a work in progress, but I wanted to share one of the first public looks at it.

I’d really like to hear what people working on robotics think.

I have been evaluating robotics training institutes in India, and it's really a challenging task, as institutes differ in a variety of ways, and it's important to understand these differences before enrolling with any institute.

As a student, parent, or robotics beginner, here are some factors that I would consider for selecting a robotics training institute in India:

Start With the Curriculum

Never enroll in a course just by the name "Robotics course."

Understanding the syllabus is really important, as it defines the purpose of the course.

A good robotics course for a beginner should include:

Introduction to Robotics

Robotics, electronics, and circuits

Sensors and Motors

Microcontrollers

Robotics programming,

Automation

IoT and Robotics

AI and Robotics

The course structure should be relevant to the student's current skill level. For example, courses designed for engineering students may seem too complex for school-going children.

Practical Training

This is one of the most important criteria for me to evaluate a robotics course.

Robotics is a skill-oriented subject, and students need sufficient practical exposure.

A good course will allow students to experiment with various components and write programs to develop robotics projects.

Students can design line follower robots, robotic cars, and many more projects and learn about the underlying concepts through these interesting projects.

Check the Technical Skills of the Instructor

The technical expertise of the trainer conducting the course is also an important criterion.

The trainer must have a good command over the subject and should be able to explain each concept in a manner understandable to the student.

A good robotics course for kids should not seem like another boring school lecture.

Lab Facilities

It is essential to understand the lab infrastructure and resources that will be available with the students for practical training.

Based on the course type, robotics labs require robotics kits, sensors, motors, microcontroller boards like Arduino, electronic components, computers, and software for programming and simulation.

Ask about the number of practical hours allocated to each student.

Ask to See Past Student Projects

I would ask the institute to share the collection of projects developed by students who have completed the course.

This way I could understand the course's strengths and weaknesses.

I will also ask whether students are allowed to customize the projects or not.

Do Not Make the Certificate Your Primary Criterion

A certificate of completion may seem tempting, but a certificate alone cannot determine the quality of training received at a robotics institute.

I would consider the course content, practical training, projects, and trainers' support as more reliable indicators of the course's quality.

A student can share a snapshot of their created projects and explain the concepts and skills learned through the course.

Compare Course Fees Carefully

The fees structure of different institutes varies significantly.

Therefore, it becomes important to compare the features of different courses.

Compare the course duration, number of classes, lab equipment, projects, material provided, trainer support, and assessments.

A lower fee course might not always be the best value for money and higher fees do not necessarily mean a better course.

Hi, I have been developing two experimental recurrent architectures, PLUG and ILRM, designed to give GRU-like models a more direct route to older inputs.

Synthetic robotics-style tests suggest they may be useful for things like:

occluded navigation;

localisation during sensor dropout;

remembering payload/tool state;

delayed fault precursors;

long-term human-intent tracking.

The results are still preliminary and synthetic, and GRUs remain better on some continuously changing dynamics tasks.

I’ve uploaded the architecture papers and current robotics screening results can be found on my posted link.

I’d really appreciate feedback on suitable real robotics benchmarks or failure cases to test next.

I’ve been working on SoftSync FlexHand V1, a soft adaptive robotic hand that uses mechanical compliance to grasp objects of different shapes and sizes without constantly retuning the motion.

Last week, I brought it to CCTV’s Youth Innovation+ as part of the HKSTP Incubation Programme, and ended up finishing 1st in Episode 2.

It was a nice milestone seeing something that started from prototypes and bench testing actually working on stage in front of a live audience.

Still plenty to improve. Happy to answer questions about the mechanism, actuation, grasping behavior, or what we’re working on next.

Hey all, I wanted to share what we’ve been building since it’s directly relevant to a lot of what gets discussed here.

Dirac Robotics takes single-camera video of a real object or site and reconstructs it into a physics-accurate simulation, mass, inertia, friction, and joint behavior resolved alongside the geometry, not just visual accuracy. Output is USD, ready for Isaac Sim. Works across rigid, articulated, and deformable objects.

There’s a public interactive asset pack if you want to poke at it directly rather than take a claim at face value, worth two minutes if you’re curious what “physics-accurate” actually looks like in practice.

Happy to answer questions on how the pipeline works, and genuinely interested in hearing how people here currently handle this problem, whether that ends up being a useful conversation for us or not.

Assuming capable mobile robots eventually become common inside homes, should their final safety layer be independent of the robot itself? We already do something similar with other systems. Appliances have their own safety features, but the house still has breakers, smoke detectors, gas detectors, water leak sensors and shutoff valves. Those protections don't depend entirely on the appliance that may be causing the problem.

I have Home Assistant running locally on a Raspberry Pi, and it can already monitor and control devices from different manufacturers. With the right switches and sensors, it can cut power, shut off water or trigger an alarm. So I am not suggesting some completely new invention. I am wondering whether this type of local control eventually becomes standardized for robots. Maybe every home robot would be required to connect to an independent system controlled by the homeowner, with a common protocol that lets the house disconnect its network access, stop its movement or place it into a safe mode. It shouldn't matter which company made the robot, and the manufacturer shouldn't be able to bypass that local control.

Of course, immediately cutting power to a mobile robot could create another danger. It might be carrying a person, hot food or something heavy. So perhaps the robot would need a small set of mandatory local emergency procedures: place whatever it is carrying in a predefined safe location, lower itself into a stable position, disable normal operation and sound an alarm. Those instructions would need to work without cloud access, while a separate physical control could still disable the motors if the robot failed to respond. This wouldn't mean the robot is expected to be unsafe, just that safety-critical systems normally have more than one layer. Could something like this realistically work across robots from different manufacturers, and should the control system belong to the robot or to the house?

3-axis test successful. Planning to use it to make a 6-axis desktop robotic arm...See if we can implement remote operation or simulation.

Working on a project that needs a decent number of simulation assets and I’m realizing there’s no obvious “right way” to do this.

Curious how people here actually do it in practice, build everything by hand in Blender/CAD, use some existing asset library and hope it’s close enough, or something else entirely? Especially curious how people handle getting physics right (mass, friction) and not just the visual geometry.

The setup: Secondhand UFactory xArm 7. A size-4 round watercolor brush in a 3D-printed compliant side mount (leans roughly 16° from the paper). A cheap 24-well tray for paint, two water wells and a sponge for cleaning, 300×300 mm paper held down by magnets. Overhead camera with a ChArUco solve for the paper plane; brush-tip height from a touchscreen contact station. Motion is planned and executed by an AI coding agent driving Python stack (path planning, FK preflight against the current tool, safety gates, logging).

Operating a brush is tricky. It's is a soft, tilted, wet tuft, and the mark depends on shaft tilt, rotation about the shaft, depth, and how much pigment and water is loaded. None of that is observable from the controller.

This particular run had 16 paint pickups, 96 palette circles (six per load), 8,437 waypoints, about 32 m of arm travel for 28.8 cm of painted line, 31 minutes wall-clock.

Estamos muy cerca de comenzar las pruebas de balanceo. Mucho tiempo invertido pero seguimos adelante. Somos Corporación Robot

Hi everyone,
I’m French and I’m currently building an early-stage hardtech project called DISPELDA.

I’m working solo at the moment and I’m exploring a
problem around autonomous systems operating when GNSS becomes unreliable, degraded, jammed or completely unavailable.

The long-term idea is to develop embedded hardware/software that can help autonomous platforms remain more resilient in those environments.

But before going too far into building, I want to understand whether I’m focusing on a problem that European drone and robotics companies actually struggle with in practice.
So I’d really like to hear from people working on UAVs, UGVs, robotics, autonomy, navigation, testing or system integration — especially in Europe.
A few things I’m trying to understand:

How important is GNSS loss/jamming/spoofing in your actual work?
Is this something you regularly design for, or still a relatively niche requirement?
What do you currently rely on when GNSS becomes unavailable: INS, VIO, optical flow, LiDAR, terrain matching, external infrastructure, something else?
What is the hardest part: navigation itself, sensor fusion, testing, validation, integration, cost, SWaP, reliability?

How do you test these situations today?
Are existing solutions good enough, or are there still major gaps?
For European companies specifically, does dependence on non-European navigation hardware/software matter when choosing a solution?
I’m not looking to sell anything here.

At this stage I’m trying to understand where the real engineering pain is before deciding exactly what DISPELDA should become.
If you work in this area, even a short answer about what actually causes problems in the real world would be extremely useful.
Thanks.

Hi everyone,

I’m debugging a navigation issue with a 4-wheel skid-steer robot using ROS 2 Nav2.

Setup

ROS 2 Nav2

Global planner: Theta*

Local controller: MPPI

Kinematics: Skid steering / differential drive

Compute: NVIDIA Jetson AGX Thor

Global path is currently being generated continuously(using 3d map)

Robot receives cmd_vel linear and angular velocity commands

Low-level motor control is handled through an STM32

Problem

The robot is not properly aligning its heading/yaw with the direction of the global path before moving.

For example, if the robot initially needs to turn toward the global path, I would expect something roughly like:

Robot → rotate/steer toward path heading → move along path

Instead, I am seeing:

Robot → drives almost straight → gets away from the desired path → suddenly rotates/turns → continues toward goal

Because the robot initially moves straight, the continuously updated Theta* global path also keeps generating a new shortest path from the robot's latest pose to the goal. This makes the overall motion look like a sequence of straight movements followed by sudden heading corrections rather than smoothly following the intended global path.

Interestingly, when there are obstacles in front of the robot, MPPI slows the robot down significantly and seems to perform the required yaw/turning motion much better. The issue is much more noticeable in relatively open space.

I also tried reducing the robot's speed, but at the initial pose it still does not properly turn toward the global path heading before translating.

What I have already verified

The hardware/low-level steering seems to be working correctly.

When controlling the robot manually using the transmitter, the skid-steer motion and turning work properly.

I also tested rotation using cmd_vel. When commanding approximately a 90° rotation, the robot reaches about 88.9°, so the robot is physically capable of executing the requested yaw motion reasonably accurately.

Because of this, I currently suspect the issue is more related to Nav2/MPPI configuration, path tracking, yaw handling, or possibly the interaction between continuous global replanning and MPPI rather than the STM32/motor-control side.

I have also tried the Rotation Shim Controller, but it did not solve the issue.

Questions

Why is MPPI not aligning the robot yaw with the global path before moving forward?

Which MPPI parameters or critics should I check for better yaw/path alignment?

Should I keep the global path fixed and replan only when needed?

What is the recommended way to handle initial heading alignment for a skid-steer robot using MPPI?

Any suggestions on MPPI configuration, TF/odometry checks, or other debugging steps would be appreciated.

Robot dot com, formerly Kiwibot, is developing a new four-legged delivery robot called R-dog.

Each leg has a wheel, and the robot is designed to handle terrain that smaller sidewalk delivery bots struggle with, including stairs. The company says the first deployments are planned for college campuses in 2027.

They also announced a partnership with FieldAI to use its world models for autonomy and navigation.

CEO Felipe Chavez Cortes said the company considered humanoids for this kind of work, but doesn’t think they’re ready yet for outdoor delivery environments.

Hello Guys,

I’m the creator of Calibra which is an open-source project for robotics dataset quality and intelligent data curation.

Calibra aims to identify higher-quality training data and reduce GPU training costs by up to 70%.

We’re currently looking for collaborations with robotics teams and researchers.If interested, dm me.