A 2026 arXiv survey proposes networking that treats balance, physical contact, task timing, learning, and human oversight as one engineering problem.
A connected humanoid fleet cannot safely operate by passing messages like ordinary software agents. If two robots handle the same object, delayed information can disrupt their timing, change interaction forces, and threaten balance.
That is the focus of a survey posted as a 2026 arXiv paper by researchers affiliated with Kyung Hee University in South Korea and the University of Sydney. It is a literature survey, not a new fleet deployment or a completed humanoid-fleet experiment by its authors.
The paper organizes networked humanoid intelligence around four functions: communication, coordination, collaboration, and social intelligence in human interaction.
Keep balance-critical control close to the robot
A humanoid runs several systems at different speeds. Balance control and physically coupled motion need fresh information with bounded delay. Perception, planning, and model updates generally tolerate longer delays.
That difference should shape the system’s design. Fast stabilization should not depend entirely on a remote server. Slower work, such as planning or fleet-level learning, can use a network connection when the timing allows it.
The survey’s authors write that “networking for humanoids cannot be treated as an independent communication layer.” The network, robot body, control software, and learning system have to be designed together.
This changes what reliable connectivity means. Average network speed is not enough. Engineers also need to consider delay variation, missing messages, and whether information remains useful when it arrives.
A message about a robot’s planned movement can become stale quickly. That matters more when the robot is walking or physically connected to another robot through a shared object.
The survey does not establish a universal safe limit for delay, packet loss, or interaction force. Instead, it identifies these measurements as open evaluation needs. Future tests must connect network behavior to physical outcomes such as balance violations, interaction forces, and performance during joint tasks.
Send useful state, not every sensor stream
Humanoids produce many kinds of information, including body state, sensor observations, task progress, plans, and learned policies. A fleet does not necessarily need to transmit all of that continuously.
The survey describes methods that select compact features, semantic scene information, event-triggered updates, or specific recipients. The goal is to send information that the receiving robot needs, when it needs it.
The authors summarize the principle this way: “Network requirements follow the consuming function, not the robot as a whole.”
In plain English, the entire robot should not have one network requirement. A balance controller may need fresh information within a short control cycle. A planning system may accept a longer delay. A model update can take longer still.
Humanoid-specific messages may also need to describe contact state, gait phase, intended footsteps, interaction force, and changing whole-body occupancy. A simple position or fixed footprint does not fully describe a body whose arms, legs, and torso are moving.
That information also needs a clear period of validity. A planned footstep or body position may no longer describe reality after a stumble, changed task, or delayed transmission.
Coordination is different from collaboration
Communication moves information between systems. Coordination keeps decisions and actions consistent.
In a factory, coordination might assign tasks, reserve a narrow aisle, prevent two robots from claiming the same space, or enforce the order of dependent actions. It can also help robots agree on a shared plan or role.
Collaboration goes further. It combines capabilities or experience to achieve something a single robot cannot do alone.
Two humanoids carrying a long module are collaborating. The shared object physically links their movements: one robot’s motion can affect the other robot’s forces and balance. Their actions must remain synchronized even as conditions change.
This means coordination requires more than exchanging locations. Robots may need to share body-centered information about contacts, motion phase, intended steps, and expected movement.
A useful architecture separates slower global decisions from faster local checks. A fleet manager or other central process can propose assignments and plans. Each robot can then check whether the proposal still fits its current state, physical abilities, and surroundings.
That division is important because agreement does not guarantee safety. Two robots can agree on a plan that one robot can no longer perform safely.
The survey discusses possible ways to manage delayed information, including designs that keep time-critical feedback local or reduce dependence on continuous messages. These are engineering approaches described across the reviewed work, not one demonstrated procedure that the survey prescribes for every fleet.
Learning adds another failure path
Networked humanoids may exchange more than task messages. They may also share data, policies, or learned experience.
That could help a fleet improve after one robot discovers a useful behavior. But learned skills are often tied to a robot’s particular joints, sensors, and end effectors. A policy that works on one humanoid may need adaptation before another robot can use it.
The survey therefore separates network risks from ordinary local robot risks. Stale information is one network-induced problem. Unsafe knowledge propagation is another: a faulty update could spread across multiple robots if the fleet accepts it without suitable checks.
The paper identifies knowledge sharing across different robot bodies as an open problem. It does not present a general verification process that makes every learned update safe.
Human oversight must reach the fleet
Humanoids will also need to coordinate with people. The survey treats human interaction as a distinct function involving intent, expectations, responsibility, and control.
A worker’s instruction or a supervisor’s decision may affect several robots at once. Human-facing behavior also matters: a robot’s posture, motion, and actions can signal what it intends to do.
This makes consistency important. The robots’ visible behavior should match the information and authority state used inside the network. Human oversight must remain part of the system’s design rather than an afterthought added above the robot fleet.
What exists today?
This work is a research survey, not a product people can buy and not a fleet standard ready for deployment. Its authors distinguish physical and simulated humanoid evidence from results involving other robots or abstract software agents, because those substitutes do not fully capture bipedal balance, whole-body motion, contact, and human interaction.
That distinction is central to the reader’s practical question. Many networking ideas can be tested in simulation or on non-humanoid robots, but a safe connected humanoid needs physical trials that measure what delay, packet loss, stale state, and communication failures do during walking and shared physical tasks.
For now, the durable engineering lesson is straightforward: keep balance-critical functions local, tailor messages to the task using them, check shared plans against each robot’s current body state, and test network failures through their physical consequences.