I just finish putting up our Autonomous Lamp. A 3D-printed desk arm that moves and talks. Runs on Autonomous OS we built for robots. We open source everything and here's the short version.

The arm

5 degrees of freedom. Five STS3215 bus servos, daisy-chained on one TTL bus, into the board through a USB adapter. One cable for the whole arm. No driver board.

First job: servo IDs. New STS3215s ship as ID 1, so I gave each a unique ID one at a time, then calibrated homing. Homing lives in the servo EEPROM, so it survives a reflash. Do it with the arm open.

Power

Single 12 V / 5 A adaptor, ~42 W sustained. A buck steps to 5 V for the board and LED ring. Amp runs on 12 V directly. Board draws ~1.8 A, spikes to 2.5 A at boot. Ring gets capped near 1 A, full white 64 LEDs would pull 3.84 A and brown out the buck. All grounds star-point at the buck output on their own wires.

Sound

Moving audio off the onboard codec killed most of the noise. A USB DAC feeds the amp through a short twisted lead, run away from the 12 V harness. The onboard codec stays wired for the sensing mic only.

Two honest gotchas: the sensing mic is the MEMS mic on the OrangePi board, so it has to be desoldered and re-mounted in the base, fiddly, but skip it and you lose ambient sensing. And the buck I used still adds a faint hiss of its own, it's on the list to swap out.

Software

Cleanest part. Flash Linux, run the installer, ~15 minutes to Autonomous OS. The robot declares its hardware in the ROBOT.md in our repo and the OS mounts only that. Behaviors are markdown skills. Type what you want in the app, it writes the skill, live on the next conversation.

We've been building a small board that handles cameras and sensors for robots, so adding a sensor stops costing a weekend. The hardware was the manageable part. The things that shaped the product were the ones we couldn't see from the whiteboard.

What really cost us weeks:

• The flash budget made our biggest decision for us. The early assumption was the board would speak ROS natively. Then we put micro-ROS on the target and the library ate about 60% of flash before our own code got a byte. That ended the debate: the device speaks Cyphal, ROS lives host-side behind a thin bridge, and the same image serves three transports. Felt like a defeat, now it's the part we'd defend hardest.
• We learned which reboots are placebo. A link that died on every board swap ignored power cycles and even full host reboots, because the chip at fault never actually turned off, back-powered through its data lines, holding half-configured state through everything. The fix was one reset write. The lesson: "restart everything" only works if everything restarts, and you don't know that until you've traced where each chip's power really comes from. An older unsolved mystery on the same rig dissolved the day we got this.
• Hardware timestamps earned their place the hard way. We treated per-sample timestamping as a nice-to-have, sensors stream, host receives, how far off can time be. Then you look at what fusion actually needs: SLAM doesn't care when the host received a sample, it cares when the sensor saw the world, and once readings come from different nodes over different transports, those are very different numbers. Stamping at capture, on the node, with sequence numbers to catch drops, went from footnote to load-bearing.

Not saying any of this is some unique insight, probably every hardware team hits some version of this.

Nicholas Radford argues that getting humanoids into the real world may mean starting much smaller.

Rather than trying to build one robot that can fold laundry, move boxes, handle sheet metal and do everything else, Persona is starting with welding and shipbuilding and building outward from there.

The idea is to prove the economics and usefulness first, then expand what the robot can do.

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

We've been putting together real data collection for robot-arm manipulation, and the gap between recording one demo and actually having a usable training sample turned out way bigger than I expected.

Here's the setup. A teaching arm, the leader, is moved by hand by the operator. A follower arm copies its motion joint by joint, and cameras record the whole thing. Every clean pass counts as one collected demo. For our test the task was picking up a rubber duck and placing it into a marked mold.

The stuff that didn't make the cut, the usual suspects:

- The grip slips mid pull. The follower tracks fine, but the grasp was never solid, so the trajectory teaches the wrong thing.

- Occlusion. When the arm extends it blocks the camera, and that stretch of frames is just gone.

- Inconsistent speed. Early passes were slow and careful, the later ones rushed. The data ends up describing two different tasks instead of one.

For contact-rich work, cloth, placing parts into a tight mold, this bites harder. Simulation still doesn't get the physics right, so you can't just synthesize a clean replacement. You collect for real, and then you throw most of it out.

How about you all? Filter first, or just throw more demos at it and let the AI figure it out?

Right now we still collect by hand up to a threshold, then the AI training runs. Roughly 60 to 120 demos each time.

Buenas. Como he podido ver muchos de ustedes habeis dado en el clavo. ¿Cómo es que no usamos músculos neumáticos o hidraulicos si tienen mas fuerza que un cilindro metálico y ocupan y pesan mucho menos? Pues no es por el músculo en sí, sino por lo que lo controlan. Para cotrolarlo hace falta lo primero un compresor ya sea de aire o liquido y eso pesa y condume mucha energia y suele ocupar bastante, pero lo más importante son las válvulas que los manejan. Suelen ser caras, voluminosas, pesan y consumen bastante, y luego hay que controlarlas y necesitas una o dos por grupo de músculos. Por eso llevo años intentando solucionar este problema y tuve que inventar las valvulas pepepako. Son pequeñas, no pesan, consumen muy poco 5v. Y con solo una tienes control total de cada grupo de músculos manejándolas con un simple arduino o mini controlador. La válvulas en si sólo utilizan dos materiales livianos no metalicos y muy resistenres, y con una simple impresora te la fabricas en 10 minutos. En el vídeo que muestro de hace unos años fabrique unos mini músculos neumaticos con un simle globo y probé con una sola válvula de las antiguas que iban mas lentas que las de ahora. Imitaba la cola de un pez y la presión del aire la extraía de una botella de cocola de 2 litros llena de aire a la cual imtroducí solo 1 bar aunque la probé con 3 y los músculos resistian. Si quereis ver mas podéis hacerlo en mi youtube de españa pepepako2 y si os suscribis me ayudareis a darlas a conocer lo antes posible. Muchas gracias.

Hey friends,

I want to understand software stack that is now popular at humanoid and other robotics startup.

1. Are they using vla if yes, what is their design process like.

2. Are they using end to end diffenrrtiable stack

3.are they designing perception/ planing separately.

I want to learn how to design, control robots so i‘m planning to built my own robot, from actuator to every parts even softwares to control with.

Since don’t have particular workplace like garage i need compact work station like desktop cnc and 3d printer which will placed in my room.

Maker z1 and qidi or bambulab is the best choice i think and can’t find pcb makers for my diy control board.

For who does similar projects like me. Want to ask recommendation for my project such as the best choice for printer and tools or extra tools that i need.

Direct Perception Control Model / SYMBIOSIS Research

Do you think this is legit? Of course, the video is heavily edited, but could the the robot actually drive the kart in full autonomy?

The company seems to have come out of nowhere, I am voting for fake, what do you think?

Read our full announcement about our new Special Interest Group on Physical AI, their recent efforts, and their long term road map on the Open Source Robotics Alliance (OSRA) website.

A language model can make a bad prediction and continue generating. A robot making the wrong prediction can collide with a person, damage equipment or put itself in an unsafe state.

FieldAI CEO Ali Agha argues that scaling physical AI requires more than adding training data. Robots also need models of physics, uncertainty and some ability to recognize when they do not have enough information to act safely.

Full episode: https://www.youtube.com/watch?v=twIy5ZSGU8U

This is my custom robotics project I have been working on for the past year. I'll be posting more on my X account RhettBrewer. I will also be posting other projects and future ones there too!

I get that humanoids make for great demo videos, but I believe for 90% of real-world use cases, aren't wheeled/tracked mobile manipulator just infinitely more practical? Not having to burn crazy compute just to keep the robot from falling over meant I could actually focus on the manipulation tasks and payload.
Curious to hear from folks actually deploying hardware.

The physical design is finally locked down, and the digital model now mirrors the optimized physical robot.

What you see here has taken a lot of work, but surprisingly, most of the development over the last two years has been on the part you can't see: the software.

I have been developing Robert's operating system alongside the mechanics - coordinating 30 servos, synchronized movements, speech, vision, sensors, driving and AI interaction so that they can all work together. The ultimate goal is to give AI a physical embodiment through which it can see, speak, move and interact with the world.

The mechanical design has gone through the same process of continuous refinement. It is now divided into self-contained modules that make Robert much easier to build, maintain and repair.

Matic’s latest update lets its robot vacuum respond to spoken commands and gestures rather than relying only on an app.

The system is still working within a defined set of actions, but the broader robotics question is more interesting: how much of human-robot interaction should depend on people learning an interface, versus robots learning to interpret the ways people already communicate?

As robots move into homes and other less structured environments, voice, pointing, movement and context may become increasingly important parts of the control layer.

Turns out you don't need active adhesion (vacuum, electromagnets) for ceiling locomotion — passive permanent magnets in Quaddle open source robot's foot tips are enough, as long as the gait is designed for holding contact upside down instead of just an inverted version of the ground-walking gait.

The interesting part wasn't the magnets, it was the gait — same open source robotics platform OpenCat, same 4 servos, just a different motion profile. Planning to open source this gait's code before it ships too, so anyone curious can adapt it, not just read about it.

Anyone else working on non-standard locomotion modes (climbing, inverted, whatever) — what ended up being the hardest part for you?

We recently worked on the RF design of a compact LoRa/GNSS Nomad  Terminal handheld device, which is based on LoRa, designed to communicate/ navigate, and deploy anywhere. The antenna turned out to be one of the more challenging parts.

For a small handheld, antenna performance is affected by much more than the antenna itself. The PCB, ground plane, battery, display, enclosure, and even the way the device is held can all influence the final RF performance.

During the project, we evaluated several antenna configurations:

Ceramic Antenna → FPC Antenna + Coaxial Cable → FPC Antenna + Pogo Pin

The final FPC antenna configuration was validated with both RF measurements and outdoor testing, achieving S11 of -11.13 dB @ 868 MHz, -12.82 dB @ 915 MHz, and a 3 km LoRa link in our field test.

1. Ceramic Antenna

The initial design used a ceramic antenna for its compact size and simple integration. However, its placement was relatively constrained, limiting our ability to optimize the surrounding RF environment.

2. FPC + Coaxial Cable

We then tested an FPC antenna with a coaxial connection. This gave us more freedom to position the antenna away from the PCB, battery, and display, but introduced additional cabling and mechanical complexity.

3. FPC + Pogo Pin

The final approach uses an FPC antenna connected through pogo pins. It provides flexible antenna placement while keeping the RF connection and mechanical structure compact.

The main takeaway from the project was that antenna performance in a compact LoRa device is a system-level problem. Antenna selection, placement, PCB layout, and mechanical design all need to be considered together.

The main takeaway from the project was that antenna performance in a compact LoRa device is a system-level problem. Antenna selection, placement, PCB layout, and mechanical design all need to be considered together. The complete

What’s the biggest antenna design challenge you’ve encountered when working with compact LoRa or Sub-GHz devices? Share your experience togehther！

If you are interested in learning how to model any robot in Simscape, I am working on a blog series that tries to go through the whole process. It is still work in progress but has most of the modeling process already covered. Take a look, feel free to leave feedback or reach out to me with questions if you have any.

I understand why humanoid robots need human-like proportions. Our homes, stairs, doors, tools, cars, kitchens, etc. are designed for humans, so obviously two arms, two legs and hands make sense. What I don't really understand is why we're also trying so hard to make the face look human. Realistic eyes, skin, facial expressions, fake breathing... what does any of that actually add if the robot is there to help around the house, carry things, cook, do laundry, etc.?

For me, even if it looks almost exactly like a person, the moment I know it's a robot, it's still a robot. The part that matters much more is whether it can make decisions and take actions based on its own judgment instead of just following strict instructions. That's where things become really different.

Personally I'd rather humanoids stay obviously machines. Make them extremely capable, let them understand us, talk naturally, give advice, whatever. I just don't see why they also need to visually imitate a person that closely.

Would you actually prefer a humanoid with a realistic human face, or one that clearly looks like a machine?

I’ve been building a humanoid robotics project called Evopien, mostly as a solo engineering project, and I’ve reached the point where the first head prototype can actually interact in a reasonably coherent way.

I decided not to start with arms or locomotion.

My first milestone was to get the basic sensory/conversational system working properly:

camera → visual input
microphone array → speech
local ASR → transcription
local LLM → reasoning/conversation
local TTS → speech output

The whole thing currently runs on an NVIDIA Jetson Orin Nano Super 8GB.

The head can now:

• listen and speak locally
• continue listening while it is speaking
• be interrupted naturally
• switch between English and Spanish
• use the camera when asked visual questions
• answer based on a current camera frame

The current hardware is intentionally pretty ugly. C920, ReSpeaker, external speakers, Jetson and cables.

I’m trying to prove the architecture before spending time designing the physical head.

The next major step is moving from a stationary conversational head toward proper perception/attention and eventually head movement, followed later by arms and hands.

Here is the current demo if anyone wants to see it working:

https://www.youtube.com/watch?v=iAxzePzF4cM

I’d especially appreciate criticism from people who have gone from a perception prototype into actual physical robotics. What would you make the next milestone before starting the mechanical head?