ItInsightsWorld: STMicroelectronics Defers Humanoid MCU/MPU Decision Until the Robot Market Takes Shape
Before any silicon path is locked in, STMicroelectronics is first tracking how humanoid demand, mechanical design, and price points stabilize; the market’s immaturity is the reason a more powerful MCU or MPU commitment has not yet been made, according to Allan Lagasca, who leads the company’s robotics segment strategic program.
Edge reaction, central coordination, and the MCU/MPU question
The company’s position is that local processing in cameras and sensors should handle fast actions inside the machine, while a central GPU remains responsible for whole-body coordination. A round trip to that GPU would add latency that a moving robot cannot tolerate. STMicroelectronics has not settled whether those demands favor more powerful MCUs or MPUs, and it ties the answer to market evolution.
“Every millisecond counts,” Allan Lagasca, director of STMicroelectronics’ robotics segment strategic program, told EE Times. “If you want a fast reaction, you should move the processing to the edge. If you want the entire system to work together, that is where the GPU comes in.”
Allan Lagasca
Lagasca said placing inference near the task reduces traffic to a central GPU and avoids delays created when data must leave and commands must return. In machines, those delays can alter physical motion.
When two hands coordinate to pass an object, a delayed command can make a joint miss its target. A few millimeters of error at individual joints may affect the combined movement.
“If inference is performed at the edge, the system can send the necessary command locally and respond faster,” he said.
He described the central GPU as the robot’s “larger brain,” but it still must synchronize head cameras, machine vision, and navigation, and coordinate joints whose sensors are not connected to one another. Without coordination, he said, “the robot could move both feet forward at the wrong time.” STMicroelectronics does not make GPUs.
Lagasca noted that current AI inference products rely on its neural processing unit (NPU) and microprocessor unit (MPU). More powerful chips may be developed only if the market requires them.
Robotics remains a low-volume market, while STMicroelectronics, as an integrated device manufacturer, targets high-volume production. “By following this market, we will better understand which technologies are needed,” he said.
Gesture recognition, sensing stack, and motor mapping
A robotic hand shown at electronica India used a camera to capture an image of a human hand; an AI model then identified 21 points to recognize the gesture. The result was translated into commands for a robotic hand with six motors. The demonstration ran on STMicroelectronics’ STM32N6 32-bit microcontroller.
“The mapping is not simple,” Lagasca said. “It is not even a one-to-one or one-to-two relationship, and it must run continuously as the hand moves.”
Perception begins with a camera module that integrates an image sensor, an inertial measurement unit (IMU) to determine the camera’s position and orientation, and a time-of-flight (ToF) sensor to measure distance. “Capturing an image is not enough; you also need to measure the distance,” Lagasca said. The ToF reading indicates when the fingers should close.
Inference also runs mainly onboard the camera, partly for privacy. As long as an image is used for inference without being stored or sent elsewhere, the system can meet privacy and cybersecurity requirements.
The camera output must then become commands usable by motors. In the gesture demonstration, a standard PLC bridged AI outputs and robotic control. “The difficulty lies in translating the data generated by AI into a format that can be transferred to a standard PLC to control the robot,” he said.
The edge approach can also guide grip adjustment. A person adjusts a hold on a water bottle almost instinctively; a robot must compute the needed grip.
Lagasca gave another example: a hand identifies a water bottle, determines its distance, and adjusts its grip to avoid crushing it or letting it slip. “The MCU, in this case the STM32, performs this inference,” he said.
Responsibility is shared across the machine. Most sensors have their own MCUs, as do motion and motor-control functions, while AI inference has its own NPU. “This creates a distributed architecture rather than putting everything into a single processor,” he said.
Shared suppliers, camera placement, and board space
Because humanoid robot manufacturers may source hands, joints, and cameras from different suppliers, integration can create issues around camera placement, board space, and motor control. A camera mounted on top of a hand may require the robot to reposition its hand before lifting an object, while one mounted underneath may strike the table during pickup.
ST said it is exploring ways to integrate camera technology and other functions into the humanoid hand itself. Although it does not manufacture camera modules, it can combine its technologies with those of its partners.
Earlier this year, STMicroelectronics and camera-module maker Leopard Imaging introduced a multimodal vision module for humanoid robots that combines STMicroelectronics’ imaging technology, 3D depth-mapping, and motion sensors. The module connects over Ethernet through Nvidia’s Holoscan Sensor Bridge to Nvidia’s Jetson computers and Isaac robot development platform, and it is designed to fit the size, weight, and power limits of humanoid robots.
The broader strategy, Lagasca said, is to divide the robot into modules, including hands, joints, feet, and eyes, that can be adapted to different applications and form factors.
Packaging functions inside modules is another challenge: processing, motor control, and connectivity must fit available board space. Lagasca cited a customer requirement for a 6 × 6-centimeter board.
He said choosing MCUs, motor drivers, and connectivity parts separately could produce a design measuring 140 × 330 mm, far larger than the board. For its robotic hand, ST integrated six MOSFETs and three drivers into one package, so a manufacturer can mount one part instead of nine.
Functional safety when moving platforms inherit static standards
Because intelligence is distributed across a robot, safety concerns also arise. Lagasca said existing safety frameworks include Safety Integrity Level (SIL) requirements for industrial applications and Automotive Safety Integrity Level (ASIL) requirements in the automotive sector. These requirements may become relevant as companies from automotive, industrial automation, smartphone, and home appliance markets enter robotics.
Compliance with a standard, however, does not guarantee that the entire robot is safe.
“If a sensor fails, the robot could still cause an injury, even if it meets the relevant SIL or ASIL standard,” Lagasca said.
He said AI can introduce additional risks if a system fails to make a decision or makes the wrong one. All these elements must be considered together to assess functional safety.
Lagasca added that many existing standards were developed for fixed equipment rather than moving robots, and the industry still needs to determine which standards and regulatory requirements are appropriate for humanoid systems, particularly those that interact directly with people.
Chip supplier share of a humanoid bill of materials
Lagasca said STMicroelectronics can address approximately 600 positions in a humanoid robot’s bill of materials (BOM), covering more than 500 components. He added that the share of a robot’s total cost represented by those parts depends on its design, including how many joints, sensors, and AI functions the robot has.
For illustration:
| Case | Humanoid robot BOM value | STMicroelectronics-supplied value | Resulting share |
|---|---|---|---|
| Smaller BOM | $600 | $600 | 100% |
| Larger BOM | $1,000 | $600 | 60% |
Entry-level robots may cost less and have fewer degrees of freedom, while mid-range and high-end systems may require more sophisticated capabilities. Lagasca said that, depending on the design, STMicroelectronics could potentially address 800 or more positions as the number of joints, sensors, cameras, and AI-processing requirements increases.
Proof of concept, labor sectors, and real-world constraints
Lagasca said many applications remain at the proof-of-concept stage despite the growing number of humanoid robot demonstrations. Automotive manufacturing and logistics are among the early areas of interest, because manufacturers can justify the cost of automation and adjust production lines to meet market demand.
He cited Boston Dynamics’ association with Hyundai and Figure AI’s relationship with BMW. Hyundai, which owns Boston Dynamics, plans to start deploying Atlas robots at its Georgia plant in 2028, while BMW has conducted trials for Figure robots in its Spartanburg, S.C., body shop.
Moving beyond demonstrations raises challenges. Training data is one. Lagasca said activities such as drilling, soldering, cooking, and sewing can be recorded and uploaded to create datasets.
He said battery technology does not yet support 24-hour operation, making downtime a practical consideration for developers.
Applications that reach the market will also depend on safety and regulatory requirements. Lagasca said direct physical interaction between humanoid robots and people presents additional challenges, particularly in healthcare.
Cybersecurity is another concern. Lagasca said chipmakers and device manufacturers must account for the EU Cyber Resilience Act and other applicable requirements at both product and application levels. “You do not want 10,000 robots operating in the real world only for someone to hack into them,” he said.
The final split of intelligence between edge processors and the central GPU may hinge on a question the industry has not settled: what a humanoid robot should look like. The architecture “has not stabilized,” Lagasca said. “Some developers ask why a robot should have only two hands rather than six, or only two legs.”
“We do not yet know what the final configuration will be,” he said. Until humanoid machines settle on a form and a cost target, the MCU-versus-MPU decision remains a market-driven question rather than a fixed product roadmap.