When people hear “robot hardware,” they often first think of visible components like motors or structural frames. In a dictionary sense, hardware simply refers to the physical constituents of a system. But in the context of multi-jointed robots, “hardware” encompasses much more than that. It goes beyond drive mechanisms, sensors, and control PCs to include embedded systems that control motors at high frequencies (high-bandwidth), network configurations for communication with the control PC, physics model-based control such as gravity compensation, and even CoM (Center of Mass) control for floating base control or optimal control-based controllers for basic stability. In many cases within the robotics field, these elements are collectively referred to as the “hardware level.”
Strictly speaking, these elements belong to the software domain. But here’s the thing—without these foundations, a robot can’t even reach a state where experiments or data collection are possible. So viewing robot hardware simply as “a machine with many motors” means you’re missing a crucial piece of the puzzle.
From the perspective of Physical AI, which is a major topic of discussion today, a robot isn’t just a machine executing commands—it’s an intelligent system that interacts directly with the physical world. A robot transmits force, the environment changes in reaction to that force, and the robot perceives those changes back through its sensors. Hardware is always at the center of this loop.
While various multi-jointed robots may look similar in their structural appearance, the way they actually interact with their environment differs significantly depending on their hardware. Even with identical joint structures, the type, material, and ratio of the gearboxes change the output impedance and backdrivability. This directly dictates how rigidly or softly the robot responds at the moment of contact. When you add the robot’s overall mass distribution and inertia into the mix, the actual force and acceleration delivered can vary wildly, even with the same control input. This becomes especially apparent in tasks involving repetitive contact, such as manipulation or locomotion—these differences lead directly to variations in stability and success rates.
The same applies to sensors and control. Control loops, communication latency, noise, sensor sensitivity, linearity, and hysteresis characteristics all play vital roles. When combined with structural stiffness, joint compliance, and friction, the interaction produced by a robot becomes the result of numerous coupled classical mechanical and electromagnetic properties.
Because of these diverse hardware factors, there are inherent limits to fully replicating robot interactions in simulation. Small variables like friction, structural flexibility, sensor non-linearity, and communication delays often play dominant roles in real-world interactions. For this reason, AI-based approaches—specifically Reinforcement Learning (RL) for control and policy learning—often face challenges where models trained in simulation fail to perform on real robots. This is commonly known as the “sim-to-real gap.”
The forces and reactions a robot exchanges with its environment are ultimately determined by the physical characteristics defined by the hardware. But here’s a bigger issue: these physical characteristics vary from robot to robot. Data collected or controllers trained on one robot often fail to achieve the same performance on another. As a result, collecting data with physical robots is difficult, and sharing or reusing data across different platforms is even more complex.
From this viewpoint, the limitations of AI-based robot control often stem from the physical conditions dictated by the hardware rather than the algorithms themselves. Without understanding the hardware, it’s difficult to explain why an AI fails or to define the boundaries of what it can achieve.
In this blog, I intend to discuss robot hardware by breaking it down into several layers. From the visible mechanical structures and actuators to the drive mechanisms and sensors that make them move, and finally to low-level and physics model-based control—we’ll step through the hardware elements required for a multi-jointed robot to function.
I plan to explore the role of each layer, where limitations arise, and how those limits affect real-world robot performance and AI-based control. My goal is to organize these thoughts not just from the perspective of a user, but from the viewpoint of someone who must directly handle, repair, and design these systems.