Building an open-source robot begins in a way that is familiar to assembling IKEA furniture. There is a parts list, called a Bill of Materials, or BOM, containing parts and prices for components such as motors, bearings, screws, wires, cameras, a microcontroller, a battery, and a set of 3D-printed pieces. In place of an instruction booklet there are CAD and STL files, the digital blueprints for each part. (e.g. the SO-ARM100/101 GitHub repository) You fabricate the components, fasten them together, and arrive at a finished physical endpoint with some sort of functionality.
The similarity ends once the robot is powered on. A bookshelf is designed to stay exactly as assembled, whereas a robot has to move while remaining correct about its own position and the state of its surroundings. Furniture is a finished artifact, but robots are systems that run continuously and correct themselves as they go. When designing and building robots, this need for correctness both numerically and temporally is a key consideration.
The rest of this post looks at how that difference manifests, using a common framing in robotics that divides the hardware into three parts: the movement, the body, and the sensor.
This post is written in partnership with Tnkr, platform for building open-source robots. Movement begins with actuators, the components that convert electrical energy into force or motion. A bare motor simply spins when powered, and controlling it means controlling how much power it receives. But, if you want it to reach a particular position, that work falls to a servo. A servo is more complete, because it packages a motor, gearing, a position sensor, and a small controller into a single unit that manages this work on its own. You do not tell a servo how hard to turn, but tell it where to go, and it holds that target for you. Internally it is running a continuous comparison, checking the angle its sensor reports against the angle you commanded and driving the motor to reduce the difference between them. If something pushes the joint away from its target, the sensor registers the change, the error grows, and the controller pushes back until the position is restored. What the servo handles internally points to a more general principle. The underlying chain of cause and effect still runs from electricity to electromagnetic force, from force to torque, and from torque to the motion of a joint, but there needs to be an articulate translation. Torque is rotational force, while a joint angle is a position, and force does not resolve itself into the correct position automatically. Something has to sit between the two, repeatedly evaluating where the joint currently is, where it should be, and how much force to apply to reduce the difference. It is the same structure as a feedback controller in any system that drives a measured value toward a target, constantly evaluating and readjusting as the control loop runs. The most common version of this is the PID controller, which continuously computes the error between the commanded setpoint and the measured value and corrects with Proportional, Integral, and Derivative terms. In plain terms, the proportional term pushes harder the further the joint currently is from its target, the integral term accumulates over time to erase a small error that lingers, and the derivative term eases off as the joint closes in so it settles smoothly instead of overshooting. Between the actuator and the joint sits the transmission, which is the element that has no equivalent in static furniture. A transmission is simply whatever connects the motor to the joint and changes the motion along the way. The reason it is needed is that a motor tends to spin fast while pushing with little force, but a joint usually needs to move slowly with a lot of force and good control. The transmission bridges that force requirement mismatch. A gearbox is the most common example. By linking gears of different sizes, it can make a motor turn roughly ten times slower while pushing about ten times harder, trading away speed to gain strength. A gearbox does not create energy, rather it transforms it. For example, at a 100:1 reduction, torque multiplies by about 100 while output speed divides by 100, which is why high-precision arms often use strain-wave (harmonic) or planetary drives. Unfortunately, the real world brings imperfections to this linkage. It adds a little friction and looseness, so the connection between motor and joint is never quite exact, and the joint can lag slightly behind what the motor is doing. This leads to the central mismatch behind controlling a physical system, especially AI. The command that is sent is not the motion or the torque, but end-state results. An instruction to move a joint to a given position passes through friction and load before it becomes real movement. This gap between commanded and achieved motion is exactly why learning-based controllers like Action Chunking with Transformers (ACT) predict short sequences of actions rather than one step at a time to keep small errors from compounding over a long horizon. The full process therefore forms a loop. Actuators create force, the transmission shapes it, the frame carries it, the sensors observe the result, and the controller measures the error and adjusts before repeating the cycle. Before the structure itself, it is worth defining an important term. A robot’s degrees of freedom (DOF) are simply the number of independent axes along which it can move. Equivalently, it is the number of separate values you need to fully pin down its pose. The first-principles starting point is a single rigid body floating in empty space, which has exactly six: three for sliding along the x, y, and z axes, and three for rotating about them. A robot builds its DOF up one joint at a time, since each actuated joint from the movement section contributes, typically, a single independent axis of motion. Adding DOF buys reach and dexterity but costs another motor and more control logic, so it is important to define the DOF that fits the functionality of the robot. The body is the robot’s physical structure, meaning the frame and all the rigid parts attached to it, down to the joints where one part meets another and is allowed to move. It is matter arranged so the machine can move in specific ways, and that arrangement sets the robot’s physical limits: how far it can reach, how steady it stays, and how much weight it can carry. The point that is easy to miss is that the body is not passive packaging around the intelligent parts. It is itself part of the control system. If the frame flexes, vibrates, or bends under load, the robot’s internal estimate of where its own parts are stops matching reality, and the software is left working with a fictional body which does not match reality. The practical consequence is that good mechanical design reduces the amount of intelligence the system needs. This design process usually starts as a CAD model. CAD, or computer-aided design, is the software where you design a part, and the CAD file holds the full editable design with all its dimensions and history. To share or manufacture that part you usually export it to a neutral format. A STEP file carries the exact solid geometry (as mathematical surfaces and solids, a “boundary representation”) in a form that other programs can open and still treat as a precise 3D object, which makes it the better choice for editing or machining. An STL file is simpler and lossy. It throws away the design intent and records only the outer surface as a mesh of tiny triangles, an approximation of the shape rather than the shape itself. STL is mostly used for 3D printing as the mesh is all that a 3D printer needs, since printing works by building a part up one thin layer at a time. After the design you must actually fill up the intended physical matter with a material of your choice. This is where these tradeoffs become concrete. PLA plastic is inexpensive and quick to print, which makes it suitable for prototypes, though it tends to flex and soften with heat and is fairly brittle. PETG, ABS, and nylon are tougher. Nylon in particular is strong and wear-resistant but readily absorbs moisture and must be dried before printing. Aluminum is light and strong. Carbon fiber offers excellent stiffness for its weight at higher cost and greater difficulty in fabrication. Selecting a material is a design decision with the same character as choosing a technology stack, including the familiar pattern in which the convenient early choice (usually PLA) is the one that later has to be replaced. Sensors are how the robot acquires information, and at the lowest level every sensor turns some piece of physical reality into numbers. Those numbers, taken together, form the robot’s sense of its own state, such as where its joints are, whether it is tilted, whether it has touched something, or what is in front of it. The cleanest way to organize the many kinds of sensors is to ask what each one is looking at. Proprioceptive sensors look inward at the robot’s own body, while exteroceptive sensors look outward at the environment around it. A robot usually needs both, and the specific sensors become easier to understand once you sort them into these two groups and know what each one converts. The proprioceptive sensors report on the machine itself. An encoder sits on a motor and converts its turning into a precise joint angle, which tells the robot exactly how far a joint has moved. An inertial measurement unit, or IMU, senses acceleration and rotation to estimate how the robot is moving and which way is up. Alongside these are the basic internal readings such as how fast the motors are turning, how much current they draw, and the battery voltage. The exteroceptive sensors report on the world, picking up things the robot does not directly control. A camera turns light into a grid of pixels, which is how a robot sees shape and color. A depth sensor or LiDAR measures distance, turning the scene into a map of how far away each surface is. A tactile sensor converts physical contact into a pressure reading, giving the robot a sense of touch when it meets something in its environment. A robot needs both. A camera may show a cup on a table, but that observation is only useful if the robot also knows where its arm, wrist, and gripper are relative to the cup.Proprioception is the foundation that lets a robot interpret what it sees. External information without internal information is a map with no indication of one’s own location on it. None of this data is meaningful without calibration. The robot has to know where each camera is mounted, which direction each axis of the IMU points, and what numerical command corresponds to a given real-world joint angle. Calibration is the layer that maps raw readings into a single agreed coordinate system, splitting into intrinsic calibration (a camera’s own focal length and lens distortion) and extrinsic / hand-eye calibration (the transform between the camera frame and the robot’s own frame). It plays a role similar to configuration and schema in software. Standard tooling for this lives in libraries like OpenCV. When it is wrong, the result is precise, confident, but incorrect. Without it, the robot has sensors and actuators but no reliable model of its own body. The SO-101 is a useful arm to take apart because it was built for exactly this kind of learning loop. It is a 3D printable 6DOF arm from Hugging Face’s LeRobot group and The Robot Studio, starting at a little over $100 per arm. Normally, a kit consists of a “leader” you move by hand and a “follower” that mimics it. You guide the leader through a task, the follower copies it, and the recorded motion trains a model that can later run the follower on its own. If you would rather follow a real build than start from a bare repository, the SO-101 is fully documented on Tnkr, which keeps the interactive 3D model, the parts list, the wiring schematics, and community builds together in one place. The arm is built from smart servos. As covered earlier, a servo packages a motor, gearing, a position sensor, and a small controller into a single unit you command by position rather than by force. The STS3215 is exactly that, a serial-bus servo with its own built-in encoder and control electronics. The follower uses six of them geared for strength and precise holding, while the leader uses lighter gearing so a human can push it around easily, which is the transmission tradeoff made concrete. Rather than each servo running its own wire back to the base, they are daisy-chained, meaning each servo plugs into the next so that one shared line carries power and commands down the whole arm, and each servo is given its own address so the controller can still speak to them one at a time. That chain ends at a controller board at the base, which talks to a PC over USB. The step that ties it together is calibration. You calibrate so the two arms report the same numbers in the same pose, which is what lets a model trained on one robot work on another. This is the part you make yourself, printing the frame in a tough plastic on an ordinary desktop printer and bolting it together. The design matters for control. The SO-101 routes its wires on the outside and stops the wrist from rotating past 360 degrees, both mechanical choices that spare the software from snagged cables and a joint that wraps around on itself. Most of the sensing hides inside the motors. Each joint’s servo has a 12-bit magnetic encoder that reports its angle directly, so the robot always knows the real position of every joint, which is the whole basis for the follower copying the leader. For seeing the world, you add cameras. The simplest setup is a single wrist or gripper camera for close-up manipulation, but most imitation-learning work pairs that gripper camera with a second external camera giving a wider view of the scene, usually fixed front-on or overhead, so the model gets both the detail at the hand and the overall layout. Put together, the SO-101 is this whole post in a minimal physical form. It is built upon a printed body that holds a known shape, encoders and cameras that report state, and geared servos that produce motion, all closed by calibration. Modern robotics connect bits to atoms, and hardware is the bridge between AI and the real world. In our last post, we illustrated robots as a function. The real world challenges that. By understanding the hardware stack into movement, body, and sensor, we hope anyone can get an intuitive understanding of the basic hardware which will embody future intelligence. Interlatent aims to bring Physical AI to everyone, starting with understanding. If any of this resonates, come build alongside us. Sign up to stay in the loop, and join our Discord.Movement
Body
Material Cost Strength Good for Watch out PLA
prototypes, fast prints flexes, softens with heat, brittle PETG
tougher general parts stringy, slower to dial in ABS
tougher, heat tolerant warps, needs an enclosure Nylon
strong, wear-resistant absorbs moisture, must be dried Aluminum
light and strong needs machining Carbon fiber
stiffness for its weight costly, hard to fabricate
Good for prototypes, fast prints.
Watch out flexes, softens with heat, brittle.Sensor
Hardware Teardown: the SO-101
Movement
Body
Sensors
Closing
Sources & further reading
The build: BOM, CAD, file formats
Movement: control, transmissions, gearing
Body: degrees of freedom and materials
Sensors & calibration
The SO-101 and learning-based control