RESEARCH CONCEPT / CONTINUOUS INTENT VALIDATION

Does the robot still behave as predicted?

Continuous Intent Validation explained through measurements, practical examples, and the conditions needed to trust a comparison.

Continuous Intent Validation, shortened to CIV, asks a simple question throughout a robot's movement: does the measured behaviour still agree with the behaviour we predicted under the current conditions?

Robots already use feedback to control their movement. They also use monitoring and fault detection. CIV proposes treating the continuing validity of a motion prediction as an explicit condition that can be checked. Whether that adds useful information beyond existing methods is a research question that must be tested.

A command and a prediction are different

A command says what the robot has been asked to do. For example, move a box to a shelf. A prediction estimates how the physical robot should respond, given its present position, speed, load, and other relevant conditions.

The controller uses feedback to adjust the movement. CIV compares a predicted physical state with a measured physical state. A controller may successfully reach the destination despite a change in friction or load. Depending on what is measured and modelled, a separate comparison might reveal that the physical response has changed.

The comparison in plain language

r = x_m − x_hat

Here, r is the difference, called the residual. x_m is the measured state. x_hat is the predicted state. Both must describe the same physical quantities at the same time.

Suppose the predicted tool position is 500.0 millimetres and the measured position is 500.4 millimetres. The residual is +0.4 millimetres. A measurement of 499.7 millimetres would give −0.3 millimetres. The sign tells us the direction of the difference.

A difference does not automatically mean a fault. Sensors have measurement uncertainty, and models contain approximations. An acceptable range must be established for the specific system and conditions. The example numbers above explain the arithmetic. They are not recommended safety limits.

Measure the behaviour that matters

Position may be important, but it may not be enough. A robot at the expected position could be travelling too quickly or rotating in an unexpected direction. Depending on the purpose, the comparison may need position, speed, acceleration, orientation, torque, or motor current.

Different quantities use different units. Millimetres of position and metres per second of speed cannot simply be added together. Each comparison needs suitable limits or a justified mathematical treatment. The monitored state must match the hazard the function is intended to address.

Timing can create an apparent error

Imagine comparing a photograph taken now with a prediction for two milliseconds earlier. At 1,000 millimetres per second, that timing difference creates an apparent position difference of about 2 millimetres even if the robot moved exactly as expected.

Prediction and measurement therefore need a known time relationship. Sensor delays, processing delays, communication delays, and the age of the data all affect the comparison. A frozen sensor value may look plausible while no longer describing the moving robot.

Agreement can be misleading

If the prediction and the measurement both depend on the same faulty sensor, both can be wrong in the same way. Two software calculations are not automatically independent. The architecture must consider shared sensors, shared power, shared communication, and other failures that could create false agreement.

The model also needs defined operating conditions. A small residual does not establish model validity if the payload, tool, speed, or operating mode lies outside the conditions used to validate it.

A learning system introduces another issue. If it continually adjusts the model to match a slowly developing fault, the residual may become small again. Model changes and comparison limits therefore need a controlled validation process. Common behaviour is not automatically safe behaviour.

Permission to continue

In the developing CIV concept, completing a movement is something to validate before permitting the next action. For example, a lifting sequence should not assume that a box is secure merely because the lifting command finished. The relevant completion conditions must be defined and checked.

Continuing permission also depends on the checks remaining valid. Loss of measurement, loss of model validity, or a significant departure needs a specified response. The complete detection and response time must fit the application. Waiting longer to avoid nuisance alarms can allow more hazardous movement.

What the research must demonstrate

Tests should compare CIV with existing monitoring under the same conditions. They should measure missed detections, unnecessary detections, response time, repeatability, and behaviour when sensors or communication fail. CIV could add value, duplicate existing functions, or perform worse. The test programme must allow all three outcomes.

CIV is a developing research concept. No safety certification or performance level is claimed. A useful comparison alone does not establish a complete safety function. Sensing, calculation, decision, and physical response all need appropriate engineering and evidence.

Continue reading: How robots share their plans