Safety model

This page is the reference for how RosieOS protects people and hardware. Every other page that moves the robot links here. Read it before you arm a real cell.

The short version: RosieOS contains no safety-rated function. The cell's hardware E-stop and safety chain are the only emergency stop. The software adds stops, interlocks and checks that make mistakes less likely, but none of them is a substitute for the hardware chain.

At a glance#

The hardware E-stop is the only emergency stop#

No RosieOS component implements a safety-rated emergency stop, safety gate or enabling device. Wire the cell so that the hardware E-stop and safety chain remove drive power without any help from software.

• rt-core only observes. You can wire an auxiliary contact of the stop chain to a declared drive digital input so that rt-core reports its state. The public API contract defines these observations as "diagnostics and never safety certification or a control decision". rt-core never uses them to decide whether to move.
• The OLP STOP button is software. Its tooltip says so: it stops playback, drops the torch output and releases the lease, and "is not the hardware emergency stop".
• The pendant trigger is a software deadman. On the Steam Deck pendant, jogging needs the right trigger held, and releasing it stops the jog. This is a convenience interlock in application code, not a safety-rated enabling device.

Software stops#

These are the software ways motion ends. Each one is useful. None proves that the robot has stopped.

A client may send Stop with a session it knows even after that session's lease has expired: an expired grant cannot move the robot, but it can still inhibit.

The lease and jog-age ceilings are per cell, in the machine config's control block. The internet link profile uses 3 s and 750 ms, and those values are marked unverified in the contract. Longer values delay the unattended stop after a link loss, which the contract states explicitly.

The motion start gate#

The 1 kHz core decides whether any motion may start: a trajectory, a dense program or a jog. The request is refused unless all of these hold:

1. No other motion source is active. A running trajectory, jog or commissioning step refuses a new start with mode_conflict.
2. The request carries the current generation, and the lease is valid.
3. The machine is armed, the EtherCAT bus is ready and no safety fault is set.
4. The configuration epoch is verified and every requested axis is configured and verified.
5. Every requested axis that requires Home has a valid Home.
6. Every requested axis has valid limits, is in cyclic synchronous position (CSP) mode, is enabled, and reports Operation Enabled with fresh feedback.
7. No axis is outside its limits and moving further out (outside_limits_outward).
8. The first point continues from the held position. A stationary start that is off by no more than the completion tolerance gets a short, bounded alignment ramp. Any other discontinuity is refused.

After a start, the core applies a final output permit every cycle. It clears the drive controlword whenever the lease is invalid or a safety fault is set, and it only reports motion as permitted while the permit and Arm both hold and no safety fault is set. Cell I/O outputs are ANDed with the same permit.

Per axis, status reports the first gate that fails, in this order: drive alarm, mode_mismatch, home_required, coordinate_invalid, not_enabled, not_operation_enabled, brake_wait, then ready.

The core also runs a collision watchdog, configured per drive, that faults an axis when torque or following-error bounds are breached. It detects an impact after it happens. It does not avoid collisions, and a machine config can compile without it. The compiler then prints a missing-collision-watchdog warning.

For the lease, fence and readiness details see Control authority and The real-time core.

What is verified before motion#

Planned weld programs are verified#

A weld program planned in offline programming (OLP) goes through the weld planner's verifier before it can reach the robot. The planner writes a dense trajectory (.rdt) only when every seam and every connecting move has a verifier PASS:

• collisions, penetrations and limit violations are all zero
• no check is left unverifiable
• the seam tracking certificate is within tolerance

Otherwise no .rdt exists, and there is nothing to load. OLP's Load fetches the program by digest from the planner's store only. Before it sends a byte to the robot it also checks:

• that the program's identity matches the header
• that the robot description and cell calibration the plan was made against match this machine
• that every axis has a valid Home

rt-core then admits the program against its own position, velocity, step and digest checks.

The verifier is a conservative geometric certificate against the cell meshes and the arm's collision spheres. It fails closed: it refuses to judge a trajectory against a cell it cannot see. It is not a physics simulation.

You can then replay the exact bytes before Load, in the 3D viewer or on the local rt-core simulator (Simulate in OLP). That replay is an operator step. The software does not require it.

Jog, moves and Home are not verified#

These motions do not pass through the verifier or a simulation first:

• joint jog and Cartesian jog, from OLP, the pendants or the Cartesian motion server
• joint moves (including "all joints to 0") and Cartesian moves
• Home and go-home
• anything sent directly through rtctl, the Go SDK, the C++ client or the dense trajectory daemon

They rely on the motion start gate and on rt-core's position, velocity and continuity admission. rt-core checks joint limits, not collisions with the cell or the part. OLP's own joint and Cartesian moves also plan at 75% of the configured velocity.

What you may claim#

Use this wording, which matches the code:

Every planned weld program is verified against the cell model, collision and joint limits, and can be replayed in simulation, before it can be loaded onto the robot.

Do not say "every motion runs in simulation before the real joints move". That is only true of planned weld programs.

One controller at a time#

rt-control admits one controller at a time. acquire returns a fence (a session token and a generation) under an expiring lease, and every command must carry that exact fence. A second client gets control_already_owned. Stop and a new acquire bump the generation, so a delayed command from an old session is refused. Jog has its own generation inside the session.

acquire must also present the deployment binding (pair id, pair revision and configuration digest), so a client configured for one cell cannot take control of another. OLP, the pendants and the motion servers all go through this lease, so they lock each other out. The lease identifies a client process. It does not authenticate a person.

See Control authority.

Process outputs are refused#

RosieOS does not switch a welding torch. Torch-class outputs are refused end to end:

• rt-core refuses a torch output intent with io_torch_unqualified, and torch_qualified must be false in every machine config
• the dense trajectory daemon refuses a program that contains torch samples with native_torch_unsupported
• OLP refuses to load a program that still requires process outputs. Choose the Dry run · process outputs off run mode, which removes them before Load.

There is no seam tracking or sensing. See Process I/O and sensing.

Simulation does not qualify hardware#

A clean run in simulation says nothing about powered motion. The code and its tests make this point themselves: software success does not qualify powered motion. In particular:

• The Steam Deck v5 pendant is not yet qualified on physical input or real motion.
• reset_fault is an interim capability.
• Hardware bring-up and qualification of a cell are done by the cell owner, by hand.

Before you move hardware#

1. Confirm the hardware E-stop removes drive power, and test it before each session.
2. Clear the cell. Stay outside the robot's reach whenever the drives are armed.
3. Check that the client is bound to the cell you expect. Describe shows the backend (simulation on the simulator) and the configuration digest.
4. Home, then arm, at low speed.
5. For programs, plan, verify and replay in simulation first, and use dry run until process outputs are qualified.
6. After any Stop, read status before you assume the robot has stopped.

Standard warning for motion pages#

Pages that move hardware carry this warning: