Electronicseng Semiconductors: Latency, Safety and Module Design in the Humanoid Robot Chip Debate

For Electronicseng Semiconductors readers, the humanoid robot question is not a simple chip-capacity argument. STMicroelectronics is tracking demand before choosing between stronger MCUs and MPUs because the body’s moving joints, cameras and sensors create timing constraints that a central processor cannot always handle. Allan Lagasca, who leads the company’s robotics segment strategic program, framed the issue around edge latency, distributed inference and safety rather than raw compute alone.

Where the processing debate begins

STMicroelectronics’ architecture view is that onboard sensors and cameras should manage quick reactions, while a central GPU should be left to coordinate the whole body. The reason is that a round trip to that GPU adds latency a moving robot cannot afford. The company has not yet decided whether the task calls for more powerful MCUs or MPUs, and it says the answer depends on how the robotics market develops.

In remarks carried by EE Times, Allan Lagasca told the source, “Every millisecond counts,” and added, “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.” The same logic applies to physical safety: “If inference is performed at the edge, the system can send the necessary command locally and respond faster,” he said.

For STMicroelectronics, the market’s immaturity is part of the reason for observation. Robotics remains a low-volume market, while the chipmaker, as an integrated device manufacturer, targets high-volume production. Lagasca said, “By following this market, we will better understand which technologies are needed,” before the company commits to a stronger chip path.

Hand-level inference as a practical test

A demonstration at electronica India showed how a robotic hand can turn a human gesture into motion. A camera captured an image of a human hand, after which an AI model identified 21 points to recognize the gesture. That information was translated into commands for a robotic hand with six motors. The gesture recognition ran on STMicroelectronics’ STM32N6 32-bit microcontroller.

Allan Lagasca

The hand mapping is not a simple lookup table. “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.”

The camera module is not only an imager. It combines an image sensor to capture images, 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 tells the hand when to close its fingers.

Inference also runs mainly onboard the camera, partly for privacy. Lagasca said that 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’s output then has to be translated into commands the motors can use. For the gesture recognition 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 also lets the hand adjust its grip. A human adjusts a hold on a water bottle almost instinctively; a robot has to compute the required grip. Lagasca gave the example of a hand that 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.

Why the body still needs a central coordinator

Lagasca 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 that coordination, he said, “the robot could move both feet forward at the wrong time.” STMicroelectronics does not make GPUs.

The chipmaker’s current AI inference products are based on its neural processing unit (NPU) and microprocessor unit (MPU). Whether it develops more powerful chips depends on how the market evolves. Each part of the robot handles its share: most sensors have their own MCUs, as do the 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.

Layer	Primary role in the humanoid system	Latency implication	Relevant example
Edge MCU or NPU	Local sensing, inference and command generation	Avoids a round trip to the central GPU	Gesture recognition on the STM32N6 or grip correction on the STM32
Camera module	Combines image sensor, IMU and ToF sensing	Distance must be available before finger motion is commanded	ToF reading tells the hand when to close its fingers
Central GPU	Synchronizes eyes, navigation and body joints	Required for whole-body coordination, but adds round-trip delay when used for fast reactions	A moving robot cannot afford a slow loop for quick motion

Module boundaries and physical integration

Because humanoid robot manufacturers may source hands, joints, and cameras from different suppliers, integrating these components can create problems with 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.

STMicroelectronics said it is exploring ways to integrate camera technology and other functions into the humanoid hand itself. Although the company 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 method, according to Lagasca, is to divide the robot into modules, including hands, joints, feet, and eyes, that can be adapted to different applications and form factors. Packaging the required functions within these modules presents another challenge, because designers must fit processing, motor control, and connectivity into the 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.

Safety is distributed, and so is risk

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 the 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 added that 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 a robot’s functional safety. 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.

Bill-of-materials reach and cost share

Lagasca said STMicroelectronics can address approximately 600 positions in a humanoid robot’s bill of materials (BOM), covering more than 500 components. 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, he said that if a robot’s BOM were worth $600 and STMicroelectronics supplied all of it, the chipmaker’s share would be 100%. If the BOM grew to $1,000 while the chipmaker’s parts remained valued at $600, its share would fall to 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. Depending on the design, STMicroelectronics could potentially address 800 or more positions as the number of joints, sensors, cameras, and AI-processing requirements increases.

From demonstration to deployment

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.

As examples of links between humanoid robotics and the automotive industry, Lagasca 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 presents several challenges. Training data is one: activities such as drilling, soldering, cooking, and sewing can be recorded and uploaded to create datasets. Battery technology also matters; it 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. 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 the 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.

Selection checklist for Electronicseng Semiconductors readers

• Identify which motions require local response and which require whole-body synchronization.
• Separate MCU, MPU, NPU and GPU responsibilities before selecting silicon.
• Measure camera, IMU and ToF data flow against the latency budget.
• Confirm that AI outputs can be translated into motor or PLC commands.
• Model board space using real placement constraints, including 6 × 6-centimeter board limits and the 140 × 330 mm separate-part comparison.
• Track BOM reach from approximately 600 positions and more than 500 components up to 800 or more positions as joints, sensors, cameras and AI functions increase.
• Include SIL, ASIL, functional safety, EU Cyber Resilience Act and privacy requirements in the design review.

Common misconceptions

• More powerful central compute is not automatically better if it lengthens a control loop that protects a moving robot.
• Edge inference is not only about reducing load; it can also shorten the path between sensing and command.
• Meeting SIL or ASIL does not mean the whole robot is safe, because “If a sensor fails, the robot could still cause an injury, even if it meets the relevant SIL or ASIL standard.”
• A humanoid hand is not a single camera project; the image, distance, orientation and grip correction must remain linked in real time.

Action recommendations

For electronics and semiconductor teams, the practical path is to treat humanoid robotics as a modular latency problem. Keep local sensor processing near the point of motion, reserve the central GPU for body-wide coordination, and document how AI outputs reach motors or PLCs. Designers should compare STMicroelectronics’ NPU and MPU inference products against the market’s still-changing configuration needs, while recognizing that the company is watching volumes before choosing a stronger chip direction.

Frequently asked questions

Why is STMicroelectronics waiting before choosing a bigger MCU or MPU?

Because robotics remains a low-volume market, and the final architecture is unsettled. Lagasca said the company will learn which technologies are needed by following market development.

What does the STM32N6 demonstrate?

It ran gesture recognition at electronica India, using 21 points from a camera image to drive a robotic hand with six motors.

Can a robot keep a bottle safe without crushing it?

In the cited example, distance from ToF and inference on the MCU, in this case the STM32, support grip adjustment. As Lagasca put it, “The MCU, in this case the STM32, performs this inference.”

Does the company supply the central GPU?

No. STMicroelectronics does not make GPUs.

Final reading

The industry has not settled what a humanoid robot should look like, so processor placement remains open. The system architecture “has not stabilized,” Lagasca said. “Some developers ask why a robot should have only two hands rather than six, or only two legs.” The practical conclusion for Electronicseng Semiconductors readers is to design around measurable latency and modular risk first, and around a larger MCU or MPU choice only after the configuration signal becomes clearer. As Lagasca summarized, “We do not yet know what the final configuration will be,” so the chipmaker’s market watch remains the bridge between low-volume prototypes and scalable semiconductor products.