I think robotics is at its most interesting when a machine can do something consistently under real constraints, rather than just perform one impressive demonstration for a video.
A quadruped carrying an actual payload, a small robot mapping its environment with SLAM, or a surgical robot assisting with a precise procedure might look completely different from one another, but they all face the same fundamental challenge: turning an idea that works in theory into a system that behaves reliably in the real world.
That's what I find more impressive than complicated movements or futuristic-looking hardware alone. Can the robot handle small variations in its environment? Does it recover when something unexpected happens? Can it repeat the task without constant human intervention?
I also think it's important to distinguish between a successful prototype and a system ready for practical use. A promising robotics project deserves recognition, but reliability, safety, maintenance, and repeatability matter just as much as the initial demonstration.
The real achievement isn't getting a robot to do something once. It's getting it to do that thing reliably enough that people can depend on it.
I'd love to see more robotics projects showcase long-term reliability and real-world testing alongside their most impressive demonstrations.
Err..., so instead of fixing the turning gait code, I already made Wouf carry some groceries. While the ST-3215-C018 servos cannot move very fast, a 1 kg payload is like half Wouf's weight, so I got pretty excited to see it is able to fumble a few steps while carrying the load :D
Wonder what else for it to carry, though. Perhaps its ST-3215 cousin that also uses 12 servos, like the SO-ARM101 🤔
Lamp's first commit was on 24 March. October has been the busiest month since: 4,092 commits on the main development branch so far, more than double April, the previous high at 1,615. The two busiest weeks ever were the last two.
In the last post I said the hardware stays as it is while we focus on production. That hasn't changed. Everything below is software, plus the work needed to build many lamps instead of one.
1. A way to program it
Someone asked in the last thread whether you can buy the lamp and change it with Claude Code. There's now a documented path for that. docs/develop.md takes about 10 minutes: a fake lamp that runs on your laptop, so you don't need the hardware, Python and JavaScript SDKs, pairing, and lamp-mcp.
Skills moved to format 2. You check a skill, push it, sign it with your own key, and share it. Lamp refuses a package that is unsigned, changed, or renamed.
2. Knowing who said what
Lamp now ties each line to the face and voice that said it and keeps each person's memory separate. If you talk to it before it recognizes you, those lines are attached to you once it does.
It only keeps what you said about yourself. Not its own words, not your questions. "Forget everything" now asks once and runs only on the same person's yes. Forgetting one specific thing went from 9 s to under 400 ms on a 10 MB memory store.
How we trained our Lamp in the office
3. Camera permissions per skill
A skill gets the camera image only after the owner allows that specific skill. Checking whether someone is in the room is a separate, smaller permission that doesn't include the image. Installing a skill by hand in place of a Store skill removes the permission. Onboarding also asks once whether Lamp may notice facial expressions, and stores only a yes.
4. Giving way to a hand
Last time someone asked whether the STS3215s give real position feedback. They do, and Lamp now uses it to tell a push from a fault. If a joint is carried away from its goal, Lamp treats it as a hand, stops what it was doing, and doesn't look around again for 30 s unless asked.
Onboarding has a step for this: hold the base, tilt the head, let go when told. If an arm strains three times, Lamp sits down, rests for 30 minutes, then gets back up.
5. Skills don't touch hardware
· New lamps calibrate their servos at the factory before the first run
· A new Orange Pi image boots straight into setup
· lampOS 0.0.4 and 0.0.5 shipped on 22 Oct, including a fix for a button that could get stuck in a held state
· The Fusion 360 file for the current body is in the repo.
5. Smaller changes
· Speech starts streaming within 400 ms of the first part of an answer
· The evening glow stays at least one level below your own light
· "Tap to talk" is now "Press to talk".
Not Done Yet
Naming two people in the same room, add-ons, and ignoring lines meant for someone else in a busy room are built but off by default until they pass on real lamps. Mood reading is at 39% on our internal tracker, and we don't count it as done.
An autonomous 4-wheel drive explorer robot based on Arduino UNO R4 WiFi, designed to navigate through paths and mazes while detecting surrounding obstacles. The robot performs 180° radar scans via an ultrasonic sensor mounted on a servo motor and transmits real-time telemetry via Wi-Fi to an interactive Web dashboard, which reconstructs the 2D vector map of the surrounding walls.
So I own a macanoid robot that is 4 feet tall, and the company has shut down the servers entirely for the software, and I don't know how to operate it. Anymore, since the app is down and I need help on finding a software that might be able to still program it or move it.
This is a small RL project I've been working on. A simulated Franka Panda learns to pick up a cube and put it on a target pad, using PPO from Stable-Baselines3 in PyBullet.
The main objective of this project was to get an understanding of PyBullet and how the whole workflow of training a robot using reinforcement learning works.
Further updates will be to combine this with a text or voice prompt enabling the user to choose which cube to pick and place at a desired location.
Any further upgrades or inputs are highly appreciated from everyone here!
RSVP HERE. We're visiting NYC and would like to meet the New York ROS developer community.
Join us on Thursday, October 29th, for a ROS Meetup at the Google office on 10th Avenue for an evening of socializing and guest speakers. Food and drinks will be provided.
DoorDash is reportedly in talks to acquire Instacart in a deal valued at approximately $17 billion.
The acquisition could increase the number of orders available for autonomous delivery robots by combining restaurant, grocery and convenience deliveries into a larger network.
One of the main challenges for delivery robots is utilization. Robots that complete only a few deliveries per day may struggle to offset equipment, maintenance and operating costs. Grocery and convenience orders could help increase utilization outside peak restaurant delivery hours.
I’m a robotics software engineer exploring startup problems around deploying and operating commercial mobile robots, particularly cleaning, delivery, security and hospital logistics robots.
I’d like to hear from people who actually deploy, operate or support them.
Could you walk through a recent mission that needed human intervention or didn’t finish as expected?
A few things I’m interested in:
What happened, and how did someone notice?
Who handled it: on-site staff, your engineering team, a dealer or the manufacturer?
Roughly how much human time, travel or rework did it involve? How often does something similar happen?
How did you confirm the original job was eventually completed, including any work finished manually?
What do your existing dashboards, remote support and operating procedures already handle well? What still takes manual coordination?
If initial setup and commissioning are a bigger challenge than ongoing operations, I’d be interested in that experience too.
If interventions are rare or already handled adequately, what makes your deployment work well? That would be equally useful to understand.
Please mention your application, role and approximate fleet size if you’re comfortable. An anonymised example is enough; no customer names or confidential logs needed. Hit me up in my DM guys.
Some of you have been following this project for a while, and today I have something exciting to share!
I've temporarily opened Watti Studio to everyone!
You can now create your own animations directly in your browser, on your computer or phone. Move the virtual robot, add keyframes, adjust the timing, and bring your ideas to life.
And the coolest part? Your animations can be performed by the real, physical Watti!
The system is still under development, so videos from the real robot may arrive with some delay.
I built an SDK that let's you connect any LLM/agent to any SO-101 or bimanual YAM set up! The demo video shows Gemini 3.7 trying to "stack the yellow blocks" (sped up 10x).
The idea is pretty simple: you give the robot a small job, like sorting blocks by color or stacking one on another, then a model can take one step at a time, or an agent can plan smaller tasks and check its work along the way. There’s still a lot to improve, especially for reliability, but I'm pretty happy with it.
Technical specs
Python SDK
Support for SO-101 and bimanual YAM arms
Local MuJoCo simulation if you don’t have a robot
Claude, GPT, Gemini and other frontier models through one API key
A judge scores each subtask and returns timestamps and failure types so you can inspect where a run went wrong
The connector runs locally and enforces motion limits that the model can’t override
The model and the execution method are separate settings, so you can switch models while keeping the same setup, or see whether a little more planning helps with the tiny pile of blocks.
I put the SDK online if anyone wants to give feedback or try it out (for free) themselves!
Just showing off our steering and lego components, we also show the rgb array doing "chase" and turning on the headlight. Sorry I don't have a side by side with the browser driving, but we have other videos of that.
Researchers developed a single control policy that helps Unitree’s G1 climb ladders, crawl, vault obstacles, cross stepping stones, and recover from falls by deciding where to place nine different body parts. One striking detail is that the robot can use its hands, elbows, knees, feet, and even pelvis for support instead of relying only on walking. It achieved 92.5% success across simulated obstacle courses, but how well this flexibility transfers to unpredictable real-world environments remains the bigger test.
Retraining balance every time the manipulation policy changes is one of the quiet costs of humanoid loco-manipulation work. DUET keeps the two controllers separate and composes their commands only at the robot interface — so a new skill no longer invalidates the gait.
Paper, code and the full summary in the first comment.
I had the opportunity to meet up with the team here to learn about this, and it's not only a cute little robot, it's one very impressive development tool 👏
"A tiny biped for reinforcement learning"
I attended NVIDIA GTC Berlin as a guest of NVIDIA EMEA.
Small production runs can be expensive because programming and setup costs are spread across fewer units. For chemistry-based products, changes to a formula can also require changes to batching and validation.
The article looks at using AI with robotic batching to reduce that setup work, allowing manufacturers to produce smaller quantities of more product variations. The proposed benefit is lower minimum orders and less unused inventory.
The approach is still early. A public demo is planned for Q1 2027, and questions remain about production reliability, regulatory requirements, and protecting customer formulas.
