A typical computational and control architecture for humanoid robots is hierarchical, designed to manage high-degree-of-freedom (DoF) mechanical structures while ensuring real-time stability and intelligent decision-making.

The computational and control architecture of humanoid robots are typically divided into three major layers: the AI section, the motion control system, and the body (Figure 1).

• The AI system, also called the ‘brain’, handles high-level processing and decision making, enabling task decomposition, task management, understanding the local environment, navigation, inference, learning, and interactions with people.
• The motion control system, the cerebellum, takes information and requirements from the AI system and determines the route to travel, motions to coordinate, balance, and kinematics, like walking.
• The body is responsible for task-specific actions and includes the vision and other sensors like IMUs and tactile feedback, and actuators with fast real-time control loops.

Chips and levels

The AI system processes massive amounts of data from vision and tactile sensors using sensor fusion to understand the environment and make decisions. Chips used here include graphics processing units (GPUs), neural processing units (NPUs), tensor processing units (TPUs), specialized AI accelerators, and high-performance SoCs.

In a humanoid robot, the cerebellum typically includes central processing units (CPUs), more SoCs, application-specific ICs (ASICs), and field programmable gate arrays (FPGAs) to manage real-time physical balance, smoothing joint movements, and adapting the robot’s stance on the fly without needing complex, high-level commands.

The execution layer in the body handles hard real-time safety, motor control loops, and direct sensor inputs at the joint level using microcontroller units (MCUs), ASICs, and a variety of driver ICs.

A humanoid robot can have dozens of joints for walking and grasping objects. Simple applications can use proportional motion algorithms where each joint can be controlled independently by using a simple control system. In more demanding applications, the coupled dynamic forces of the various joints are significant, nonlinear, and complex, demanding more computationally intensive control algorithms.

Basics of humanoid walking

Walking is a complex problem for humanoids. The most agile and human-like humanoids generally use 12 to 14 DoFs (6 or 7 per leg, for example, 3 hip, 1 knee, and 2 ankle) to allow for 3D mobility, complex movements, and balancing.

A simplified approach to humanoid walking treats the torso and arms as the upper-body, while the waist and legs are treated as the lower-body (Figure 2). This control system considers the entire upper body to be a large, rigid structure. Controlling the center of mass (CoM, or center of gravity) of the upper-body is key. The CoM is the single theoretical point where the mass is perfectly balanced.

Manipulator controls

Advanced humanoid manipulator controls require 6 DoF to reach any position and orientation in a workspace. A simpler 5 DoF configuration can be effective for tasks like welding or pick-and-place, where rotational movement about one axis is unnecessary.

• Waist provides base rotation left and right around a vertical axis.
• Shoulder moves the robot’s arm up and down, or forward and backward, in a vertical plane.
• Elbow bends and extends the arm, changing the reach of the manipulator.
• Wrist yaw allows the end-effector, or ‘hand’, to tilt up and down or pivot side-to-side for proper alignment.
• Wrist roll rotates the end-effector clockwise or counterclockwise along the axis of the forearm.

A typical manipulator control architecture, a master control is responsible for sending ‘set point’ information to each of the joint controllers. The joint controllers use the set point information to command the joint actuator to move the joint at the proper speed to the required position (Figure 3).

Summary

The computational and control architecture for humanoids is a layered structure designed to optimize efficiency and support real-time performance. A variety of digital, analog, and mixed-signal ICs, including GPUs, NPUs, TPUs, CPUs, motor drivers, ASICs, and so on, are used in the various levels of the computing architecture. Software tools range from the ROS and AI algorithms to sophisticated motion control software for real-time control of rapid movements.

References

A Multi-modal Architecture for Human Robot Communication, Stanford University
Beyond Wheels: Designing and Building a Walking/Bipedal Robot, KEYi Technology
Computational Options for Robotics, Distelec
Experimental Investigations into Using Motion Capture State Feedback for Real-Time Control of a Humanoid Robot, MDPI sensors
Experimental Validation of the Essential Model for a Complete Walking Gait with the NAO Robot, MDPI robotics
Humanoid robotics – E/E architecture, software and safety, FEV.io
Humanoid Robotics: Tackling Diverse Challenges with Modular Architecture, Advantech
Humanoid robots 101, BofA Institute of Global Research
Mathematical Modeling and Control Architecture of the Autonomous Lower Body of a Humanoid Robot, IIETA Mathematical Modelling of Engineering Problems
Next-Generation Whole-Body Control System of Humanoid Robots,arXiv
Software Architecture and Development for Controlling a Hubo Humanoid Robot, Purdue University
Walking control of humanoid robots based on improved footstep planner and whole-body coordination controller, Frontiers in Neurorobotics
What is the Best Programming Language for Robotics?, RobotIQ

Related EEWorld Online content

What kinematic equations are important for industrial robots?
How does the Zenoh protocol enhance edge device operation?
What are the applications of physical artificial intelligence?
The difference between physical AI and machine learning in power electronics
What is an AI governor and how does it relate to physical AI?

The post Computational and control architectures for humanoid robots appeared first on Microcontroller Tips.

Implementing robust sensor security is essential in connected systems. Compromised sensors can feed corrupt, inaccurate data directly into operational systems, leading to devastating real-world failures, catastrophic physical damage, safety concerns, and compromised decision-making. 

The increasing number of sensors in modern systems and the diversity of sensor types across applications like machine learning (ML) and automation present an expanding attack surface that can be invaded by bad actors.

Sensors are used in a variety of critical systems, from the electric grid to autonomous vehicles and pacemakers. Corrupted data can create life-threatening conditions. Corrupted data can also result in an AI application that makes incorrect predictions, resulting in unsafe actions. Adding to the challenges, sensors are often resource-constrained devices, making it difficult to integrate significant levels of security directly into the sensor.

The growing complexity of sensor networks further expands the attack surface, making implementing sensor security complex as well as critical. That necessitates implementing a defense-in-depth approach that embraces hardware, network, and software layers (Figure 1).

Strategies for sensor security

Hardware considerations for sensor security include tamper detection using physical switches, accelerometers, or other tools to monitor for unauthorized physical access. Unused ports should be physically sealed and secure boot implemented.

Network isolation can be important, including the use of virtual LANs to limit outbound sensor communication and block all unauthorized inbound connections. Use of a zero-trust architecture to verify all communication provides an additional level of security.

A well-regulated and controlled patch management process for the delivery of encrypted firmware updates is essential. ML tools can be used to identify anomalous sensor data that may indicate a sensor that’s been physically compromised or subjected to environmental manipulation.

Holistic approach

Strategies for sensor security must extend beyond the edges of traditional networking. Modern systems no longer include a so-called ‘air gap’ without wired or wireless connections that isolates individual systems from the rest of the operation. Today, most systems are designed to allow various types of external connectivity, adding dimensions of concern to the attack surface (Figure 2).

• Remote virtual private networks (VPNs) used for remote and global connectivity can be hacked.
• Manufacturing execution systems (MES) link high-level business planning systems (like enterprise resource planning, ERP) and the physical production floor.
• Engineering laptops and USB drives are often used to update systems and backup configuration data.

Wired vs. wireless

There are fundamental differences in attack surfaces and attack vectors between wired and wireless sensor implementations. Wireless connections cannot be disabled by simply cutting a wire. Wireless sensors can be targets for signal interception or manipulation.

Wired sensor networks are less flexible than wireless implementations and are vulnerable to communication or power cables being severed. Insertion of a resistor at the sensor end of a connection can allow the control panel to detect if a wire has been cut, or if a sensor has been tampered with. Wired connections can’t be easily intercepted and are relatively immune to hacking, jamming, and electromagnetic interference.  

OT vs IT

Finally, there’s a tension between the security demands of operational technology (OT) on the factory floor and information technology (IT) in businesses. For example, OT systems prize stability and infrequent changes while IT systems require more frequent updates to ensure maximum performance.

The intersection between IT and OT systems must be tightly managed. A strictly IT-related event is not generally life-threatening. An OT-related event can compromise safety. OT concerns extend to supply chain issues and ensuring that new sensors or other assets and maintenance or calibration tools don’t introduce security risks (Figure 3).

Summary

Implementation of sensor security in connected systems is as complex as it is important. There are multiple types of sensors, heterogeneous IoT architectures including wired and wireless devices, and application requirements to consider, plus the intersection of IT and OT systems to manage. External vulnerabilities from new equipment and calibration services can exacerbate the internal networking challenges.

References

A step-by-step guide to achieving fast, secure IoT connectivity and device lifecycle management, Crypto Quantique
Combining Edge Computing-Assisted Internet of Things Security with Artificial Intelligence: Applications, Challenges, and Opportunities, MDPI applied sciences
Enhancing Cyber Security Through Machine Learning-Based Anomaly Detection, International Journal of Engineering Research & Technology
IoT Security: Essential Strategies to Protect Connected Devices, Paessler
OT Cybersecurity: The Guide to Securing Industrial Systems, TXOne Networks
Secure OTA Boot Chains and Firmware Verification: Building Trust in Connected Devices, Promwad
Securing All Your Shiny New Connected Devices, NJCCIC
Securing Connected Devices: Enhancing IoT Security in Manufacturing, Orlan Tech
Security Considerations for Field Equipment in Industrial Systems, Industrial Cyber
Security for Industrial Control Systems (ICS), Splunk
Sensors Cybersecurity, MDPI sensors
What Is ICS Security?, Palo Alto Networks

Related EEWorld Online content

How does the Machinery Regulation (EU) 2023/1230 affect designs?
What is an AI governor and how does it relate to physical AI?
How will the Cyber Resilience Act impact embedded developers?
How does the Zenoh protocol enhance edge device operation?
OpenClaw is open-source edge AI for (almost) every application

The post How to implement sensor security in connected systems appeared first on Microcontroller Tips.

A panel at Advantech’s Edge AI Conference made the case that the gap between promising pilot and production rollout is where the real engineering work begins.

The phrase “edge AI” gets thrown around a lot, but there’s a version that matters to engineers building real-world systems, and it looks nothing like a research demo. At Advantech’s recent Edge AI Conference, a panel featuring Ed Doran, PhD, VP of Strategy at the Edge AI Foundation; Umang Garg, Managing Director at Nagarro; and Richard Huang, Chief Software Architect at Advantech, spent just about 30 minutes cutting through the hype. The result was one of the more technically grounded conversations on edge deployment I’ve heard lately.

Doran opened with a framing worth keeping. Edge AI isn’t just “AI running somewhere other than a data center.” It’s the extension of centralized intelligence into environments defined by real constraints: limited bandwidth, tight power budgets, hard latency requirements, and security boundaries that make cloud connectivity either impractical or unacceptable. That means the shipping container packed with inference hardware sitting outside a mine in Western Australia. It means a vehicle making safety-critical decisions with a degraded radio link. It means a surgical suite where patient data cannot leave the room. Each of those scenarios demands something different from the AI stack, and that diversity is both what makes edge AI valuable and what makes it genuinely difficult to build.

“It’s really hard to do edge AI in that shipping container,” Doran said. “It’s really vital to do edge AI well in the surgical suite.” The implication is that edge AI is not one problem. It’s dozens of constrained optimization problems sharing a name.

That complexity deepens when you layer in physical AI, the convergence of edge AI with robotics, digital twins, and autonomous systems operating directly in the physical world. Physical AI isn’t just processing data at the edge; it’s closing the loop between perception, decision-making, and real-world action in environments where the stakes are high and the tolerance for latency or error is low. It’s what moves edge AI from passive inference into active, embodied intelligence, and it’s where much of the architectural discussion at the session ultimately landed.

That’s part of why Garg’s contribution was useful. Nagarro works across more than 20 countries on industrial edge deployments, and his read on why pilots stall is empirical rather than theoretical. His team has catalogued more than 60 distinct failure points across the journey from proof-of-concept to production rollout. The short list includes the usual suspects: ROI modeling, feasibility assessment, scalability planning. But the ones that kill deployments tend to cluster around solution strategy and enterprise integration. Choosing whether to build custom software, use off-the-shelf tooling, or deploy configurable accelerators isn’t a procurement question, it’s an architecture decision that determines whether you can scale from one facility to 50.

Garg walked through a machine manufacturer case study that illustrated the gap between pilot success and production reality. The customer had been in business for 400 years, operated roughly 250 machine types, and dealt with equipment that could have a 25- to 30-year field life. Machines deployed in the last decade often lacked modern sensor capability, meaning engineers had to physically travel to diagnose failures. The solution layered in edge-based predictive analytics alongside a parallel stream of real-time telemetry, using AI throughout the development process itself. What typically took six months compressed to about six weeks. The rollout now covers 11 machine types across 200 customers, with predictive maintenance running entirely on the local edge device.

On the architecture side, Huang walked through the cross-platform challenge in practical terms. Edge deployments span a range of silicon targets, from Intel and NVIDIA to NXP and Rockchip, and moving an inference application between them is not trivial without an abstraction layer. Advantech’s WISE platform (Wireless IoT Sensing Embedded) addresses this through containerized, pre-validated AI workloads that handle platform migration overhead. It also extends traditional OT data handling beyond numeric streams, supporting image data, binary payloads, and tagged datasets through digital twin protocols, so the same data can be consumed on the edge or passed to the cloud without re-engineering the pipeline. Model lifecycle management and zero-touch device onboarding round out the stack, addressing most of the infrastructure friction that burns development cycles before a single line of application logic gets written.

The AI agent layer sits on top of all of this, and it runs on NVIDIA NeMo, an agent-first, open suite of libraries with built-in skills for accelerating AI agent specialization, optimization, and governance. NeMo integrates with existing AI tools and agent frameworks to optimize specialized agents across cloud, on-premises, or hybrid environments, which maps directly to the deployment diversity Doran described at the session’s open.

The panel closed on AI agents more broadly, and Doran’s framing was blunt: intelligence without action has no value, and action without intelligence is a liability. The two are not sequential, they’re codependent. Edge AI enables agents to act with low latency and high reliability in environments where cloud roundtrips are not viable, but the outcomes those agents produce will also feed the next generation of edge models. The loop is already running. The question isn’t whether to start building agents into industrial stacks. It’s how to build them stably enough to trust in the field.

That’s the part none of the tooling fully solves yet. But the conversation suggests the pieces are closer to assembly than they were two years ago.

The post Edge AI is real. Scaling is the hard part appeared first on Microcontroller Tips.