Why an Edge Vision Model Cannot Set the Safe Speed of a Shared Robot Application

The standard talks about the application, not a collaborative brand

ISO 10218-1:2025 is the current industrial-robot safety document. The preview says the word pair “collaborative robot” is not how this edition wants the machine described. Only the application can be developed, checked and validated as a collaborative application. Safety functions used for a shared task can sit in the robot, in a protective device, or in both. A marketing class of arm does not carry the safety case. [1]

The same preview lists safety functions that are about motion limits: speed monitoring, monitored standstill, stopping-time limiting, and stopping-distance limiting. Those functions have to exist as safety functions. A neural network that proposes a task motion is not, by its accuracy on a dataset, one of those functions. If the network is fast, it may be a convenient task controller. The stop that protects a person is still the function whose time and distance were validated. [1]

Certification scope is discussed separately. Humanoid safety standards on this siteThis page stays on the separation-distance arithmetic.

The gap is the distance traveled before the motion is over

Marvel and colleagues at NIST published a working account of speed and separation monitoring as written from ISO/TS 15066. The protective distance at the current instant has to cover four contributions. The person keeps moving during the robot’s reaction time and during the stop. The robot keeps moving toward the person during the reaction time. The robot then travels its stopping distance. Intrusion distance and position uncertainty for the sensor and the robot are added on top. [2]

Reaction time, TR, is the delay from the presence of the person until the robot starts the protective response. Stop time, TS, is the time to reach a safe controlled stop. The NIST account says TS depends on speed and load. A heavier tool, or a faster move, lengthens the stop. A formula that uses one TS for every program is already wrong before any camera is discussed. [2]

ISO 13855’s simpler form, which the same paper cites as the ancestor, is S = vT + C. Here v is the approach speed of the body part and T is the whole sensing-plus-stop interval. The linear form is a rough cousin of the fuller integral. Both say the same thing about latency. Every extra millisecond of T is multiplied by a speed. It becomes millimeters of required gap. It is not absorbed by a higher classification score. [2]

A published vision-model rate is an example of TR, not a safety rating

OpenVLA, a large vision-language-action model, runs at about 6 Hz on an RTX 4090 in the configuration the authors measured, and slower when quantized onto an A5000. Six hertz is about 170 ms between outputs. If a perception stack of that class is placed in the path that must notice a person, some or all of that interval sits inside TR. The person and the robot both travel during it. The paper itself evaluates manipulation, not a safety-rated person detector. The number is used here only as a measured inference interval for a heavy vision model, so the separation formula has a concrete scale. [3] [2]

A lighter network can be faster. That does not flip the logic. Whatever the measured latency of the detector is, it enters TR together with the bus, the safety controller, and the drive. Quoting frames per second for the neural net and ignoring the rest of the chain understates T. Quoting a benchmark latency on a workstation GPU, while the cell runs another computer, uses the wrong T entirely. [3] [2]

There is a second, sharper limit. A detector that is fast and wrong is not conservative in the direction the formula assumes. The formula assumes the sensor reports the person, with a bounded position error ZS. A missed detection is not a larger ZS. It is a failure to start the clock. No choice of robot speed repairs a sensor that does not see the person. The edge model’s dataset accuracy does not appear in the ISO arithmetic. [2]

The safe speed is the speed whose stop still fits the space

Read the formula backwards. The cell has a maximum separation you can actually give the person and the robot, set by the layout. TR is set by the sensing chain you built. TS and the stopping distance are set by the speed, the load, and the validated stop. If the sum is larger than the layout, the legal move is to cut speed, cut load, cut TR, or stop using speed-and-separation for that task. It is not to publish a higher model score. [2]

[2] [1]

ISO 10218-1:2025 names stopping-time limiting and stopping-distance limiting as safety functions. Those names match the TS and stopping-distance terms. A design review can ask for the measured stop at the speed and load of the real program, and for the measured response of the protective device. A design review that only asks for the GPU type has asked the wrong question. [1] [2]

An extra tenth of a second is a distance, once speed is stated

The NIST account does not fix a universal walking speed inside the formula. The speed is an input from the risk assessment. The arithmetic is still worth writing down so latency is not left in milliseconds. Take an approach speed of 1 m/s, chosen here only as a round assumption, not as a value copied from the standard. An extra 100 ms of reaction time is then 0.1 m of human travel, and the robot’s own motion during that same 100 ms adds further distance if it is still moving toward the person. At 1.5 m/s the human term alone is 0.15 m per 100 ms. Double the unmeasured delay and you double that term. None of this depends on how large the vision model is. [2]

Stopping time refuses the same shortcut. Marvel and colleagues note that TS depends on speed and load. A stop measured with an empty gripper is not the stop with a 5 kg tool, and this page does not invent that tool’s distance. The design consequence is procedural. The validation record has to name the load and the speed at which TS was measured. A single “braking time” in a brochure, with no load, cannot be dropped into the formula. [2]

Where the edge computer does belong is in the task path that is allowed to be wrong. It can propose a slower program, a different order of picks, or a pause when its own confidence is low. Those behaviors can reduce how often the safety function has to fire. They do not change the distance the safety function must protect when it does fire. ISO 10218-1:2025’s preview, by refusing to treat “collaborative” as a property of the robot product, blocks the slide from a clever task computer to a missing protective device. [1] [2]

A review meeting can therefore be short. Ask for TR on the wired safety output. Ask for TS at the real load. Ask which term would grow if the camera were moved onto a busier computer. If the answer to the third question is “the task policy would slow down, the safety output would not,” the architecture matches the formula. If the answer is “the same network does both,” the reaction time of that network is inside the safety sum, and its worst-case latency, not its average benchmark, is the number that matters. [2] [1]

Draw the safety wire separately from the task wire

A practical drawing of the cell has two wires out of the camera, or two different sensors. One wire ends in the task computer. Its latency may be long, and its mistakes may be frequent, because a wrong pick can be retried. The other wire ends in the protective device. Its latency is TR in the separation sum, and a missed person is a failed safety function rather than a missed pick. The NIST formula has nowhere to put a retry. The person does not wait for the next frame. [2]

ISO 10218-1:2025’s preview allows the safety function to live in the robot, in a protective device, or in a combination. A combination is still a named function with a measured time. It is not a hope that the task network usually sees people. Once the wires are drawn, the speed limit is the largest program speed whose TS, at that load, still fits the layout after TR and the uncertainty terms. Raising the speed without remeasuring TS is how the formula is silently abandoned. [1] [2]

What to measure before raising the program speed

• TR from the protective device’s own output, not from a task network that is off the safety path.
• TS and stopping distance at the heaviest tool and the highest speed the program will command.
• The position uncertainty the sensor vendor or the validation actually measured, as ZS.
• Confirmation that a missed person is treated as a fault of the safety function, not as a residual of the task policy.

[2] [1]

Until those four numbers exist, an edge model can still be used for the task, beside a protective device whose time is in the formula. It cannot be used as the argument that the robot may go faster because the model is large. The 2025 robot standard’s own preview refuses the shortcut of calling the machine collaborative and stopping there. The application has to carry the safety functions. [1]