In the past three decades, humanoid robots have evolved from laboratory prototypes to commercially viable products. However, the design of an embodied robot that is both affordable and capable remains a challenging task. This article describes my work on creating a flexible and scalable hardware and software framework for a small humanoid robot. The proposed architecture adopts a dual-controller strategy: a PC104 embedded computer serves as the high-level processor, while an STM32 microcontroller acts as the real-time servo controller and sensor hub. The software environment is based on Ubuntu 12.04 LTS and the Indigo distribution of Robot Operating System (ROS), which together provide a rich development ecosystem for perception, planning, and control. The complete system was evaluated through power consumption tests, inertial sensor tests, serial communication tests, and a face-tracking demonstration. The results confirm that the platform satisfies the design goals and provides a solid foundation for further embodied robot research.
1. Introduction and Background
Humanoid robotics is a multidisciplinary field that combines mechanical design, electronic circuits, control theory, computer software, and biomimetic perception. An embodied robot, in contrast to a purely industrial manipulator, is expected to operate in human-centered environments, walk on two legs, recognize faces, understand speech, and perform dexterous manipulation. These requirements impose significant pressure on the embedded computing system, actuator selection, and software integration. During the last few years, many research institutions have focused on the development of humanoid platforms. The key technologies are still dominated by a few developed countries, but the gap is narrowing. In China, the rapid development of humanoid robots is driven by national initiatives such as “Made in China 2025,” and many university research groups have produced working prototypes. Nevertheless, there is a lack of cost-effective, customizable, and maintainable systems that can be directly transferred to industrial products.
From the perspective of control system architecture, humanoid robots have evolved through centralized, distributed, and fieldbus-based systems. Centralized control is simple but suffers from wiring complexity and processor overload. Distributed control improves real-time performance but often requires expensive multi-board designs. Fieldbus-based systems such as CAN or serial buses provide a good balance between wiring complexity and communication speed. In addition, modern small humanoid robots often use digital servo motors to reduce mechanical complexity. The recent market trend is toward small humanoid robots driven by standard servos, but many of them rely solely on a single microcontroller, which limits their ability to handle advanced perception tasks.
In my research, I aim to solve these limitations by designing an embodied robot with a dual-controller architecture that separates high-level computation from low-level real-time actuation. The high-level controller runs Ubuntu and ROS, which facilitates code reuse and rapid development. The low-level controller is responsible for reading inertial sensors and driving multiple servos. Such an architecture is highly modular, and each part can be upgraded or removed according to the target application. This is particularly important for commercial products, where different versions of an embodied robot may need different sensor suites or actuator configurations.
Table below summarizes the control architectures commonly used in humanoid robots.
| Architecture | Advantages | Disadvantages | Typical Use |
|---|---|---|---|
| Centralized | Simple wiring, low cost, easy debugging | Heavy processor load, poor extensibility, signal interference | Small toy robots, simple humanoids |
| Distributed | High real-time performance, parallel computing | Expensive, complex synchronization, large volume | Advanced research humanoids |
| Fieldbus-based | Open protocol, high speed, robust communication | Needs specialized interface hardware, higher design complexity | Industrial humanoids, humanoids with many joints |
| Dual-controller (proposed) | Balanced performance and cost, modularity, maintainability | Requires careful protocol design between processors | Commercial humanoid robots, embedded AI platforms |
Among these, the dual-controller architecture is particularly attractive for an embodied robot that must balance real-time control and high-level intelligence. By assigning time-critical tasks to a microcontroller and computationally expensive tasks to an embedded computer, the system achieves both responsiveness and versatility.
2. Overall System Design
Before selecting components, I analyzed the intended application scenarios. The embodied robot is designed for a market-oriented product, targeting users above ten years old. The robot height should be between 0.5 m and 1 m. The robot should be able to walk, perform complex gestures, recognize faces, and support voice interaction. The development cycle should be less than one year, and the hardware and software must be maintainable. In addition, the robot must work from a battery, so power consumption must be carefully controlled. The final design should have a high performance-to-cost ratio.
Based on these requirements, I defined the following functional specifications:
| Function | Implementation strategy |
|---|---|
| Attitude sensing | Gyroscope and accelerometer modules connected to STM32 |
| Actuation | 20 digital servo motors with serial bus control |
| High-level computation | PC104 embedded computer with Atom dual-core processor |
| Perception | USB camera for image acquisition and face detection |
| Software integration | Ubuntu 12.04 LTS and ROS Indigo |
| Power | 11.1 V lithium battery and multiple voltage regulator circuits |
The overall hardware architecture is illustrated in the following figure. The system is organized around a dual-processor topology; all high-level tasks are executed on the PC104 board, while time-critical tasks such as sensor reading and servo control are handled by the STM32. The two processors communicate over a serial link using a custom protocol.
The software platform selection is equally important for an embodied robot. Several embedded operating systems were considered, including Windows CE, Palm OS, μC/OS-II, and Linux. Windows CE offers a familiar GUI but is not open source and has limited community support. Palm OS is mainly designed for PDAs and lacks real-time features. μC/OS-II is highly reliable and small, but it is not free for commercial use and does not provide a rich application ecosystem. Linux, on the other hand, is open source, highly configurable, and well supported by a large community. It also supports standard POSIX APIs and provides excellent networking capabilities. Therefore, I chose Ubuntu 12.04 LTS as the host operating system for the PC104 board.
On top of Ubuntu, I deployed ROS Indigo as the robotic middleware. ROS provides a distributed communication framework based on topics, services, and actions. It also includes powerful development tools such as Rviz for visualization and Gazebo for physical simulation. The use of ROS greatly accelerates the development of complex robotics algorithms, including path planning, simultaneous localization and mapping (SLAM), and human-robot interaction. For an embodied robot, ROS facilitates code reuse and modular software design, making it easier to extend the system with new capabilities in the future.
The following table compares candidate operating systems for the embedded computer.
| Operating System | Open Source | Real-time Capability | Development Ecosystem | Overall Suitability |
|---|---|---|---|---|
| Windows CE | No | Moderate | Good GUI support | Limited |
| Palm OS | No | Weak | Poor for robotics | Not suitable |
| μC/OS-II | No (commercial license) | Excellent | Small footprint, but limited libraries | Suitable for tiny controllers only |
| Ubuntu Linux | Yes | Good (with RT patches if needed) | Very rich ecosystem, ROS support | Best for high-level control |
3. Hardware Design
3.1 Power Module
The power module is the foundation of the entire embodied robot system. The robot operates from a rechargeable 11.1 V, 1800 mAh lithium battery. The required rail voltages are 12 V for servos, 5 V for logic and communication circuits, and 3.3 V for the microcontroller and inertial sensors. Since the battery voltage is approximately 11.1 V when fully charged, a 5 V regulator and a 3.3 V regulator are needed. I selected the LM78M05 linear regulator for the 5 V rail and the EZ1117 chip for the 3.3 V rail. The 5 V output is generated by the LM78M05, and then the EZ1117 converts the 5 V to 3.3 V. Capacitors are added to suppress high-frequency noise and stabilize the output.
| Module | Chip / Device | Voltage (V) | Purpose |
|---|---|---|---|
| Battery | Lithium-polymer | 11.1 | Primary power source |
| Servo power | MX-28T servos | 12 (direct from battery) | Joint actuation |
| Logic level | LM78M05 | 5 | TTL communication, FT232, miscellaneous logic |
| MCU rail | EZ1117 | 3.3 | STM32, LIS331DLH, L3G4200D |
| PC104 | Embedded computer board | 12 | High-level processing |
The efficiency of a linear regulator can be approximated as
$$
\eta \approx \frac{V_{\text{out}}}{V_{\text{in}}} \times 100\%.
$$
For the 5 V regulator fed from 11.1 V, the efficiency is approximately 45%, which is acceptable for short-duration experiments but not optimal for long battery life. To improve the overall efficiency of future products, a buck converter could replace the linear regulator, but for the present design the linear approach was selected for its simplicity, low noise, and small footprint.
3.2 Actuation Module
The drive module is critical because it determines the robot’s motion quality. After comparing direct-current motors, stepper motors, and servos, I selected the Dynamixel MX-28T digital servo from Robotis as the joint actuator. Each servo integrates a gear reducer, a DC motor, and a control circuit. The MX-28T supports half-duplex asynchronous serial communication and can be daisy-chained on a TTL bus. It can also provide position, temperature, load, and input voltage feedback. This makes the servo an ideal building block for an embodied robot because it simplifies wiring and enables online monitoring.
Key parameters of the MX-28T are listed in the table below.
| Item | Value |
|---|---|
| Mass | 72 g |
| Dimensions (mm) | 35.6 × 50.6 × 35.5 |
| Gear ratio | 193:1 |
| Operating voltage | 10 – 14.8 V |
| Stall torque (at 12 V) | 2.5 N·m |
| Stall current (at 12 V) | 1.4 A |
| No-load speed (at 12 V) | 55 rpm |
| Minimum step | 0.088° |
| Operating range | 360° |
| Communication | Half-duplex asynchronous serial, TTL multi-drop |
| Feedback | Position, temperature, load, voltage |
The servo communication protocol uses data packets. An instruction packet consists of a header, servo ID, packet length, instruction code, parameters, and a checksum. The same format is used for status packets, except that the instruction field is replaced by an error code. The checksum is computed as
$$
\text{Checksum} = \sim\left( \text{ID} + \text{Length} + \text{Instruction} + \sum_{i=1}^{N} \text{Parameter}_i \right) \bmod 256.
$$
For example, to control servo ID 1, the packet is 0xFF, 0xFF, 0x01, 0x04, 0x03, 0x03, 0x01, 0xF6. The first two bytes are the header, the third byte is the ID, the fourth is the length, the fifth is the instruction, the sixth and seventh are parameters, and the last byte is the checksum.
The baud rate of the servo bus is stored in the control table at address 0x04. Different baud rates result in different communication errors. The table below shows a subset of possible settings.
| Value (HEX) | Target BPS | Actual BPS | Error (%) |
|---|---|---|---|
| 0x01 | 1,000,000 | 1,000,000 | 0.000 |
| 0x03 | 500,000 | 500,000 | 0.000 |
| 0x04 | 400,000 | 400,000 | 0.000 |
| 0x07 | 250,000 | 250,000 | 0.000 |
| 0x09 | 200,000 | 200,000 | 0.000 |
| 0x10 | 117,647.1 | 115,200 | −2.124 |
To minimize communication errors, I set the servo bus baud rate to 1 Mbps. The twenty servos are allocated to the legs, arms, waist, and head. Each servo is assigned a unique ID so that the STM32 can individually address them. For synchronized motion of multiple servos, I used the broadcast mode and the SYNC WRITE instruction. This avoids the accumulation of delay caused by writing to servos one by one. The timing delay for twenty servos in a single write is approximately 13.2 ms per servo, which would result in 264 ms total delay for a sequential write. By using the synchronous write command, the entire group can be updated with a single packet, and the actuators start moving only after receiving an ACTION command.
3.3 Serial Communication Module
Two serial communication channels are needed in the system. The first channel connects the STM32 to the servo bus. Since the MX-28T uses a half-duplex single-wire TTL bus, a directional control circuit is required. I used the 74HC126 tri-state buffer to enable or disable the transmit and receive paths. The second channel connects the STM32 to the PC104 host. To simplify firmware development, I selected the FT232 USB-to-serial bridge chip. The FT232 is reliable and has native driver support in Ubuntu. The STM32 communicates with the PC104 using the USART3 peripheral at a baud rate of 1 Mbps, matching the servo bus speed. Data from the PC104 is packed according to the servo protocol and forwarded directly to the servos by the STM32.
The STM32’s USART1 handles servo communication. Its receive interrupt routine stores incoming data into a DMA buffer. After receiving a complete packet, the STM32 parses the instruction and executes the corresponding action. Sensor data from the gyroscope and accelerometer are also packed into a similar format and transmitted to the PC104. This uniform protocol design greatly simplifies the software architecture.
3.4 Attitude Measurement Module
Accurate attitude estimation is essential for maintaining the balance of an embodied robot. I compared several types of sensors for measuring tilt, angular rate, and acceleration. The comparison is shown below.
| Sensor | Measured Quantity | Advantages | Disadvantages |
|---|---|---|---|
| Inclinometer | Angle | High accuracy, low cumulative error | Slow dynamic response, limited bandwidth |
| Gyroscope | Angular velocity | Fast response, good dynamic performance | Drift and integration error over time |
| Accelerometer | Linear acceleration | Simple, low drift, good for static tilt | Noisy under dynamic motion |
| Ultrasonic sensor | Distance | Low cost, simple | Only for ranging, poor on non-flat surfaces |
| Infrared sensor | Distance | Fast response | Affected by surface reflectivity |
No single sensor is sufficient for reliable attitude estimation. I therefore selected two MEMS sensors: the LIS331DLH three-axis accelerometer and the L3G4200D three-axis gyroscope. Both chips are manufactured by STMicroelectronics and support both SPI and I²C interfaces. In my design, I connected both sensors to the same SPI bus with different chip-select lines. The STM32 reads the angular rate and acceleration values periodically. The measurement range of the accelerometer was configured to ±4 g, while the gyroscope was set to ±500 dps. The 16-bit output data are combined as follows:
$$
\text{raw} = ( \text{HighByte} \ll 8 ) \,\text{|}\, \text{LowByte}.
$$
Then the raw value is converted to a physical unit by multiplying by the sensitivity factor. For the LIS331DLH at ±4 g, the sensitivity is approximately 0.001 g/LSB; for the L3G4200D at ±500 dps, the sensitivity is approximately 0.0175 dps/LSB.
The SPI interface uses four wires: MISO, MOSI, SCLK, and CSPin. Data are sampled on the rising edge of the clock. Registers such as CTRL_REG1 and CTRL_REG4 are programmed to set the output data rate, power mode, and measurement range. For example, CTRL_REG1 of the L3G4200D is set to 0xFF, which enables the X, Y, and Z axes, activates the normal power mode, and selects an output data rate of 800 Hz.
3.5 Vision Module
For visual perception, I chose a Logitech C905 USB camera. It is a driver-free camera based on the UVC standard, so it works directly with Video4Linux in Ubuntu. The camera has a Carl Zeiss autofocus lens, a 2-megapixel CMOS sensor, and an integrated microphone. It can capture video at 1920×1080 resolution, but for real-time processing I downscaled the frames to 320×240. This resolution reduces computational load while maintaining sufficient accuracy for face detection and tracking. The camera is mounted in the robot’s head and connected to the PC104 via USB.
| Item | Specification |
|---|---|
| Lens | Carl Zeiss, autofocus |
| Interface | USB 2.0 |
| Sensor | 2 megapixel CMOS |
| Maximum Resolution | 1920 × 1080 |
| Additional Feature | Built-in microphone |
3.6 PCB Design
All the above modules were integrated on a four-layer printed circuit board. The board includes the STM32F103RET6 microcontroller, the power regulation circuits, the FT232 USB-to-serial converter, the servo bus transceivers, and the inertial sensor chips. I carefully placed the gyroscope and accelerometer near the geometric center of the board to reduce rotational coupling. The PCB was designed to be compact enough to fit inside the robot’s chest cavity. High-speed signal traces were kept short, and decoupling capacitors were placed close to the power pins of each integrated circuit.
4. Software Design
4.1 Embedded Operating System Porting
For the PC104 board, I prepared a customized Ubuntu 12.04 LTS system image. Instead of installing the operating system from scratch on every robot, I used Remastersys to create a bootable ISO image of a preconfigured Ubuntu system. The image includes all necessary drivers, development tools, and libraries. To restore the system to another PC104 board, I used Clonezilla, a free and open-source disk cloning tool. The process consisted of four main steps: first, create the Ubuntu image; second, make a Clonezilla live USB drive; third, copy the image to the USB drive; fourth, boot from the USB and select the restore option. This method dramatically reduces deployment time for manufacturing multiple units of the embodied robot.
4.2 ROS Platform Deployment
After installing Ubuntu, I deployed ROS Indigo on the PC104. I used the apt-get package manager to install the ROS base system, followed by additional packages such as rviz, gazebo, and tf. After installation, running roscore successfully launched the ROS master, which is the central communication hub. The ROS environment enables distributed processing: the face detection node can run on the PC104, while the motor control node can communicate with STM32 through a serial bridge. This modular framework is very beneficial for an embodied robot, as different algorithms can be independently developed and tested.
I also created the robot’s three-dimensional model in ROS using the Unified Robot Description Format (URDF). URDF is an XML-based language that defines links, joints, geometry, inertia, and visual properties. I modeled all major links of the robot including the trunk, arms, legs, and head. Joints were specified as revolute or continuous, with appropriate limits and axes. The resulting model can be visualized in Rviz and loaded into Gazebo for simulation. Figure below is a snapshot of the ROS simulation model for the lower body and the full humanoid.
Although I cannot display the actual simulation snapshots here, the URDF model allows me to validate the kinematic structure of the robot before executing motions on the real hardware. The model also serves as a basis for motion planning and collision avoidance algorithms in future work.
4.3 Motion Parameter Design
The gait generation algorithm was developed by another team member, so I focus here on the servo parameter tuning and motion execution interface. Before a new motion is executed, I need to initialize the servo parameters such as the compliance margins and slopes. The compliance parameters determine how aggressively a servo reaches its target position. By adjusting these parameters, I can reduce mechanical shock and improve the smoothness of motion. The table below lists the compliance level ranges for the MX-28T servo.
| Level | Range | Typical Value |
|---|---|---|
| 1 | 0 – 3 | 2 |
| 2 | 4 – 7 | 4 |
| 3 | 8 – 15 | 8 |
| 4 | 16 – 31 | 16 |
| 5 | 32 – 63 | 32 |
| 6 | 64 – 127 | 64 |
| 7 | 128 – 254 | 128 |
I measured the response time of servo ID 1 while varying the compliance margin. The response time reached a minimum when the margin was set to zero. Similarly, the compliance slope had a minimum response time at a value of 52. Therefore, I configured all servos with the same optimized compliance values to achieve fast and accurate motion. In addition, I implemented a torque feedback function by reading the current load from the control table address P_PRESENT_LOAD_L. This information is useful for detecting abnormal states such as physical blocking or excessive external force.
For synchronized multi-servo motion, the STM32 receives a packet containing the target positions of all servos. Instead of sending individual write commands, it uses the SYNC WRITE instruction with the starting address and length. The data are temporarily stored in each servo’s buffer, and the actual actuation is triggered by the ACTION command. This method ensures that all joints begin moving at the same time, greatly improving the coordination of walking and whole-body motions.
4.4 Face Tracking Task
To demonstrate the capability of the software framework, I implemented a non-specific face tracking function on the embodied robot. The vision module captures frames, and OpenCV (version 2.4.9) is used for face detection. The face detection algorithm returns the coordinates of the center of a detected face. The control law for the head pan and tilt servo motors is a simple proportional-derivative (PD) controller, whose continuous transfer function is
$$
G(s) = K_p \left( 1 + T_d s \right).
$$
Let \(X_i\) be the current x-coordinate of the face center and \(X_0\) be the image center. The x-direction error is defined as
$$
e_x = X_i – X_0.
$$
The required angular increment for the pan servo is computed as
$$
\Delta \theta = K_p e_x + K_d \left( e_x – e_{x,prev} \right),
$$
where \(e_{x,prev}\) is the previous error. A similar computation is performed for the pitch servo using the y-coordinate. To avoid excessive oscillation, I set the deadband threshold to 16 pixels in the horizontal direction and 12 pixels in the vertical direction. The face tracking algorithm first searches for a face by rotating the head left and right, then up and down. Once a face is detected, the controller continuously adjusts the head to keep the face centered in the field of view. If the face is lost, the system resumes the search pattern.
The software framework is shown conceptually below. It consists of several C++ classes that abstract the low-level hardware. The STM32Board class handles serial communication with the microcontroller, while the MotionModule class provides an interface to servo actions. Derived classes implement walking, demonstration playback, and head control. This object-oriented design enables fast integration of new functions into the embodied robot.
5. System Debugging and Results
5.1 Prototype and Power Test
A complete prototype of the embodied robot was assembled according to the proposed hardware design. I measured the output voltages of each power rail using an oscilloscope. The battery voltage was approximately 11.8 V. The LM78M05 produced a stable 5.0 V output, and the EZ1117 produced a stable 3.3 V output. All tested modules, including the STM32, gyroscope, accelerometer, and communication chips, received their correct operating voltages. The table below records the measured values.
| Rail | Nominal (V) | Measured (V) | Status |
|---|---|---|---|
| Battery | 11.1 | 11.8 | OK |
| 5 V regulator | 5.0 | 5.0 | OK |
| 3.3 V regulator | 3.3 | 3.3 | OK |
| MCU core | 3.3 | 3.3 | OK |
5.2 Gyroscope and Accelerometer Tests
I recorded the gyroscope and accelerometer output while the robot was walking forward. The x-axis and y-axis angular velocities fluctuated during walking, which demonstrates that the sensors correctly capture the body’s rocking motion. When the robot stopped, the angular velocities returned to zero. During a forward-fall experiment, the accelerometer showed a large positive acceleration along the x-axis, followed by a large opposite acceleration when the robot rose. The gyroscope also showed a significant angular rate change during the fall. These signals provide essential feedback for balance control.
The following table summarizes the sensor behavior under different motion states.
| Motion State | Gyroscope X-axis | Gyroscope Y-axis | Accelerometer X-axis |
|---|---|---|---|
| Stationary | Near zero | Near zero | Constant ≈ 0 g |
| Walking forward | Oscillating | Oscillating | Oscillating around 0 g |
| Forward fall | Large spike | Small change | Large spike |
| Standing up | Opposite spike | Small change | Opposite spike |
| Turning (left/right) | Moderate change | Moderate change | Small changes |
The results confirmed that the sensor orientation and register configurations are correct. The data were transmitted to the PC104 in real time through the FT232 bridge at 1 Mbps, with no packet loss observed within a 10-minute test window.
5.3 Face Tracking Test
The face tracking module was tested by moving a human face laterally and vertically in front of the robot. The OpenCV detection algorithm successfully identified the face and computed its coordinates. The head servos responded according to the PD control law, and the errors decreased to near zero when the face remained stationary at the image center. The figure below shows the upper-computer interface with the detected face and the real-time coordinate display.
I also logged the angular positions of the two head servos during the tracking process. Servo ID 19 controlled pan, and servo ID 20 controlled tilt. When the face moved horizontally, servo 19 changed its position accordingly while servo 20 remained almost unchanged. When the face moved vertically, servo 20 responded. This decoupled behavior validates the control strategy and the synchronization of the servo bus.
The table below shows representative tracking performance data.
| Face Displacement (pixels) | Pan Servo Correction (degrees) | Tilt Servo Correction (degrees) | Final Error (pixels) |
|---|---|---|---|
| +30 | +12 | 0 | 2 |
| −25 | −9 | 0 | 3 |
| +20 vertical | 0 | +8 | 2 |
| −20 vertical | 0 | −7 | 1 |
The tracking latency was about 100 ms, which is acceptable for human-robot interaction. The robot could reacquire the face after losing it by performing a systematic search pattern.
5.4 Communication Reliability
I performed a stress test by sending 10,000 servo control packets from the PC104 to the STM32. The STM32 forwarded the packets to the servo bus, and the servos executed the corresponding actions. The packet success rate was 99.98%, with only two corrupted packets caused by electrical interference. This high reliability is partly due to the checksum and the use of a dedicated UART line with the FT232 chip.
6. Conclusion and Future Work
In this work, I designed, built, and tested an embodied robot system based on a dual-controller architecture and the ROS platform. The main contributions are summarized as follows:
First, I proposed a hardware architecture that combines a PC104 embedded computer and an STM32 microcontroller. The PC104 provides high computational power for image processing, path planning, and communication with cloud services. The STM32 handles real-time sensor acquisition and servo control. This division of labor improves the overall responsiveness of the system and reduces the cost compared to a fully distributed architecture.
Second, I implemented a modular power system that supplies 12 V, 5 V, and 3.3 V rails from a single lithium battery. The system was verified to be stable during continuous operation. Third, I deployed Ubuntu and ROS on the PC104, and I created a URDF model of the humanoid robot in ROS for simulation and visualization. Fourth, I developed a face-tracking function using OpenCV and a PD controller, demonstrating the integration of perception and action in the embodied robot.
There are several limitations and directions for future improvement. The MX-28T servos have limited torque, which restricts the maximum height and weight of the robot. Using higher-torque servos or a parallel actuation mechanism would allow a larger embodiment. The ROS simulation is not yet fully connected to the real robot; future work should implement a ROS hardware interface so that commands issued in Rviz can directly drive the actual servos. Moreover, the attitude measurement module currently includes only a gyroscope and an accelerometer. To achieve robust walking, additional sensors such as joint torque sensors, foot force sensors, ultrasonic distance sensors, and laser scanners are needed. These sensors would also enable autonomous navigation and mapping.
The current system uses a PD controller for face tracking. In future versions, a more advanced controller, such as a model predictive controller or an adaptive controller, could improve tracking accuracy under fast motion. Furthermore, the integration of speech recognition and natural language understanding would significantly enhance the interactive capabilities of the embodied robot. With the increasing maturity of cloud robotics, the PC104 could also be connected to remote computing servers for tasks that require deep learning models. The modular design presented here will continue to serve as a solid foundation for these enhancements.
In summary, the dual-controller based embodied robot with ROS provides an excellent balance among performance, cost, scalability, and development speed. The system has been successfully validated in terms of power management, sensor accuracy, communication reliability, and real-time face tracking. It offers a practical reference for commercial humanoid robot development and demonstrates the powerful potential of combining embedded controllers with open-source robotic software.