A University of Tokyo controller turns thrust into a continuously managed state, while transferring foot load gradually as each step changes contact.
The robot does not cling to the ceiling through a special adhesive or a single clever gait. It stays there by managing two coupled forces at once: its thrusters push the body toward the ceiling, and its feet apply enough normal force to remain in contact while one foot lifts and the other takes over.
A University of Tokyo paper reports a research demonstration of that idea in simulation and on hardware. The machine walked approximately 0.15 meters across a ceiling in four steps over about 8.5 seconds. That is a short laboratory validation, not a deployed ceiling-inspection product. But it exposes the engineering problem clearly: the robot must remain pressed against the surface while its contact pattern changes.
The problem is a force handoff
On the floor, gravity naturally pushes a robot’s feet downward. On a ceiling, gravity pulls the robot away from the surface. The robot must create the missing support force itself.
The platform described by Kazuki Sugihara and Kei Okada consists of two six-degree-of-freedom legs and two vectorable thrusters. Each thruster can rotate to direct its force toward the ceiling’s surface normal. That directional control lets the rotors generate the pressing force needed to keep the feet attached, while also helping control the robot’s orientation.
The difficult moment arrives during a step. One foot must swing free, then land again, while the other foot temporarily supports the robot. The robot’s dynamics change abruptly as a contact disappears or appears. If the controller responds by commanding a sudden jump in thrust, the real rotors cannot follow instantly. The result can be vibration, slipping or detachment.
The paper’s central change is to stop treating thrust as an instantaneous command.
Thrust becomes something the controller carries forward
In a conventional model predictive controller, or MPC, thrust is an input: the optimizer chooses the force it wants at each point in the prediction horizon. MPC repeatedly predicts the robot’s future motion, evaluates constraints and costs, and sends the next command.
Here, the controller treats thrust itself as part of the robot’s state. Its input is the thrust-rate—the time derivative of thrust, or how quickly thrust is allowed to change. The controller then integrates that rate forward in time.
That distinction matters at contact switching. Instead of asking for a new thrust value that may be far from the current one, the optimizer chooses a controlled change. Thrust therefore evolves continuously across the controller’s prediction steps. The authors say this preserves the sparse structure of the optimization problem, helping the system remain fast enough for real-time use.
The paper’s offline comparison illustrates the reason for the design. With thrust used directly as the input, the optimization produced step-like thrust changes of about 3 newtons during contact switching. With thrust-rate input, the thrust changed smoothly. The thrust-rate formulation also converged in 16 iterations in that comparison, versus 26 for the direct-thrust formulation.
This is not merely software polish. A rotor cannot produce an arbitrary force jump with zero delay. A controller that plans commands the hardware can physically track has a better chance of preserving contact.
The feet need a minimum push
Smooth thrust alone is not enough. The optimizer might prefer to reduce thrust because lower thrust is part of its cost function. On a ceiling, reducing the pressing force too far can let a support foot peel away even if other contact constraints still look acceptable in the mathematical model.
The researchers therefore add a lower bound on the foot’s normal contact force—the component pushing directly into the ceiling. During single support, the active foot receives the required minimum. During double support, when both feet touch the surface, that minimum is transferred gradually from the old support foot to the next one.
This is the controller’s load-transfer strategy. Rather than switching support responsibility instantly, it linearly shifts the minimum normal-force requirement while both feet are down. The force handoff and the thrust trajectory are designed to change together.
That detail answers the practical question of how the robot stays attached while its feet switch: the controller does not merely move the swing leg. It coordinates the leg motion, body dynamics, thruster force and contact-force limits in one whole-body optimization.
What the hardware actually demonstrated
The hardware test used tethers to a power supply and control computer, and the robot’s effective mass, including wiring, was 2.0 kilograms. The robot walked about 0.15 meters in four steps. The authors report that the proposed formulation suppressed thrust spikes and excessive vibration.
The reported average MPC solve time during the experiment was 5.47 milliseconds, with 99.7 percent of solutions completed within 10 milliseconds. Those figures describe the controller’s computation, not a complete deployment package.
There is also an important measurement limitation. The robot had no foot-mounted wrench sensors, so the experiment could not directly measure the contact wrench or center of pressure. The paper estimates the ceiling-directed contact force from the difference between thrust and the force associated with the robot’s effective mass, rather than measuring foot forces directly.
That matters for operators. A short, tethered walk shows that the control architecture can coordinate the transition between contacts under the reported test conditions. It does not establish performance on a long ceiling route, irregular surfaces, walls, curved structures or untethered operation. The authors identify transitions between walls and ceilings, curved surfaces and integration with flight as future directions.
For now, the useful consequence is narrower and more concrete: flying humanoids may not need to choose between hovering and walking when they reach an overhead surface. A controller that limits how quickly thrust changes—and deliberately hands contact load from one foot to the other—provides a plausible way to make that transition without asking the hardware to perform impossible force jumps. The next engineering step is to test the same handoff with direct foot-force sensing and without the power and control tethers.