RESEARCH CONCEPT / RESTRICTED SPACE

Where could a robot reach after a failure?

A practical explanation of fault-derived restricted space for mobile robots and humanoids.

A robot's planned route tells us where it is supposed to go. Safety engineering must also ask where it could go when something fails. That question becomes especially important when a robot can travel through a building, carry a load, or lose its balance.

Imagine a humanoid carrying a box down a warehouse aisle. Its planned movement may fit inside a narrow lane. If a hip drive fails, however, the robot could fall sideways. An arm could swing beyond the lane. The box could move farther than the robot's body. The space affected by that failure can be much larger than the space used during normal walking.

Three spaces to keep separate

The operating space describes the space used for the intended task. The reachable volume for a fault describes where the robot, its tool, its load, and relevant parts could reach under one defined failure scenario. This research proposes combining those fault volumes to help establish a restricted space that accounts for the failures identified by the risk assessment.

A restricted space must be supported by actual limiting measures and their demonstrated behaviour. Drawing a boundary in software does not establish that the physical robot will remain inside it. The method described here is a research approach to finding the necessary bounds, rather than a claim that an existing robot already enforces them.

Build one volume for each relevant failure

Start with the risk assessment. Identify failures that could create hazardous movement. Depending on the design, these might include loss of drive torque, a failed brake, an incorrect position measurement, loss of steering, or loss of payload retention. The list must come from the actual application.

For each scenario, define the starting conditions. Record the robot's posture, speed, load, direction of travel, and contact with the floor. Determine what movement can occur before detection, during the response, and after that response begins. For a falling humanoid, turning off a motor may not end the movement. Gravity can continue to move the body and its load.

The result should be a three-dimensional volume. Height matters as well as floor area. A low object, a person's head, and an overhead obstruction can be affected differently by the same failure.

Combine the volumes without adding their distances

The mathematical term for combining these regions is geometric union. In ordinary language, keep every point included in at least one of the fault volumes. Where two volumes overlap, count that space once.

Think of tracing several overlapping shapes onto one transparent sheet. The final outline surrounds all the shapes. You do not add the width of every shape to obtain one enormous distance. This distinction matters when a calculation produces an unexpectedly large result. The result must be traced back to its assumptions and geometry.

Timing is part of the space calculation

A robot moving at 1 metre per second travels 50 millimetres during a 50 millisecond interval if its speed stays constant. This simple distance is only one part of the calculation. Travel during braking, rotation, falling, sliding, and payload release may also need to be considered.

Those effects must be modelled consistently. If one simulation already includes motion during the detection delay, that motion must not be added a second time as a separate allowance. A large safety boundary can be justified, but double counting does not make a calculation defensible.

What makes the result credible?

Each boundary needs evidence. Important inputs include measured response times, braking performance, body dimensions, mass distribution, joint behaviour after a fault, floor conditions, and load retention. Simulations should be checked against physical measurements wherever practical.

Uncertainty must also be stated. If floor friction is unknown, a precise stopping distance is not justified. If the model does not include a released load, its result cannot be described as containing that load.

A dynamic boundary could change with posture, speed, and payload. Any practical use would need trustworthy information about those conditions, controlled update timing, and a validated way to enforce the boundary. When those conditions cannot be established, the system needs a defined response.

The question for an industrial client

Ask the supplier to explain what physically limits the robot after each relevant failure and what evidence supports that limit. A demonstration of normal motion does not answer a fault question. The engineering objective is a boundary that is traceable to the risk assessment, the robot's behaviour, and the protective measures.

Continue reading: How to test a safety claim