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