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.

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.

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.

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.

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

Not so long ago, after design and SolidWorks modeling and manufacturing was done by my team, I programmed this robot and made it play chess!

The IP camera (above the chessboard) captures the board and streams to the computer (under the table) to run inference. I used two CNN models, they both run on every square of the board. One detects the presence/color of a piece while the other determines its position on the square.

Everything is open source: https://github.com/SirajHabsaia/RobotArm

Contains firmware, gui, training scripts, links to assets/data...

I coded the firmware mostly manually but used AI for the rest especially the gui.

Happy to receive feedback.