Choose your setup guide.
Try the included example first. Then choose the guide for the project files you want to compare. Each guide lists what you need and explains the result.
Start here: an example on your computer
v1.5.0 · · RLSOK Local Check
Try the included example on Ubuntu, see which setting changed, then choose a guide for your own project. No robot or account is needed for the example. The example runs on Ubuntu and sends no robot commands. Windows and Mac users can watch it on the download page.
- Try the included example
- Compare ArmPilot settings without starting the arm
- Inspect selected SO101, Beast and Cartesian configuration inputs
- Saved setups: device binding, calibration and configuration changes
- Piper: review confirmed camera and arm roles
- KUKA: compare saved ROS bridge and Sunrise source files
- Tello: passive service-call observation and configuration review
- Nav2: observed graph and exact-goal review
- Hexapod: observed gait and controller configuration
- Source workspaces and selected interfaces
- Interface configuration and custom field mapping
For an existing UR5e setup with a cloud account
This is a separate setup guide; you do not need it for the example above. Robot runtime: v1.4.5. The guide below documents the original v1.3.0 Zero-to-Shadow workflow with Hosted Cloud. Its guide edition and control-plane version are separate from the local checking tool above. This installer selects the stable runtime.
RLSOK is Robot Software Execution Authorization. Immediately before ROS 2 controller dispatch, it rechecks whether the exact approved robot-software release, robot, controller, configuration, required runtime capabilities, and a short-lived Permit still authorize the next command, then records Evidence. This UR5e workflow observes the real JointState and trajectory-controller boundary in a supported ROS 2 environment.
curl -fsSL https://rlsok.com/install.sh | sudo sh
source /opt/ros/jazzy/setup.bash
rlsok setupThe released Linux bundle is self-contained. Node.js, npm, source checkout, API keys, Workspace IDs, hand-calculated hashes, and blank ExecSpec JSON are not part of the normal product flow.
What setup does
- Validates Ubuntu 24.04 x86_64, ROS 2 Jazzy, and the loaded Fast DDS implementation.
- Identifies an official UR5e from its robot description, namespace, controller manager, UR controller types, active scaled trajectory controller, JointState set, and action. No topic or action names are requested; only a robot namespace is requested if several match.
- Reads a live JointState sample, hashes the selected policy artifact, and stores an immutable local copy.
- Generates stable device, robot-profile, controller-profile, ROS binding, runtime-policy, and Draft release identities.
- Opens browser pairing. A verified user approves the exact Draft while the terminal waits; raw Cloud credentials never appear in the flow.
- Re-hashes the protected artifact, evaluates a hold-position proposal against live robot state in Shadow, and makes zero controller calls.
- Writes local Evidence, stores hash-chained Cloud Evidence, reads it back, verifies its hash, and reports the exact paths and result.
Official support boundary
| Area | Supported golden path |
|---|---|
| Original guide edition | v1.3.0 |
| Robot-side runtime | 1.4.5 |
| Cloud / control plane | 1.3.0 |
| Operating system | Ubuntu 24.04 x86_64 |
| ROS distribution | ROS 2 Jazzy |
| DDS / RMW | Fast DDS · rmw_fastrtps_cpp |
| Official robot integration | Universal Robots UR5e · official ROS 2 driver |
| State interface | sensor_msgs/msg/JointState |
| Controller boundary | control_msgs/action/FollowJointTrajectory |
| Control plane | Hosted RLSOK Cloud |
The official robot claim is limited to the UR5e integration above and is validated with the official driver's mock-hardware simulation; no physical-robot validation is claimed. A recognized but incomplete UR graph fails closed. Unrelated JointState/FollowJointTrajectory graphs are labeled generic protocol support, not official robot support.
Generated configuration remains inspectable
- Credentials:
~/.config/rlsok/cloud-credentials.json - Setup state:
~/.config/rlsok/setup.json - Releases, protected artifacts, proposals, and Evidence:
~/.local/share/rlsok
Cloud receives the artifact SHA-256, size, and binding metadata—not the policy bytes. Advanced users can inspect and replace generated profiles through the existing manual release workflow before any canary or released deployment.
Connect the learned policy
rlsok observe
from rlsok import propose
propose(next_joint_positions)Setup stores the exact joint order and proposal channel, so policy code does not contain ROS topic or action names. The Python surface submits a proposal only; the separately running gate retains release and controller authority, and Shadow makes zero controller calls.
Failure recovery
| What RLSOK found | Next action |
|---|---|
| ROS 2 not available | Source /opt/ros/jazzy/setup.bash in the same terminal, then rerun rlsok setup. |
| Wrong DDS implementation | Export RMW_IMPLEMENTATION=rmw_fastrtps_cpp before setup. |
| No JointState sample | Confirm ros2 topic list -t shows JointState and ros2 topic echo --once <topic> receives data. |
| No trajectory action server | Start ros2_control, check ros2 control list_controllers, then inspect ros2 action list -t. |
| Pairing expired | Run rlsok pair again and approve the new short code within 10 minutes. |
| Artifact changed | Create a new setup Draft. RLSOK will not reuse approval after the artifact digest changes. |
Run rlsok ros2 doctor for detailed diagnostics. Internal failure identifiers remain available in debug output, but the normal path explains what was expected, what was found, and the next command.
Security guarantees preserved
- The paired runtime can create only the exact onboarding Draft; it cannot approve it.
- Approval records the authenticated approver and finalizes the approval-bound ExecSpec hash.
- Shadow still requires an approved release and short-lived, single-use Cloud and local execution authority.
- Cloud-connected operation never falls back to standalone behavior.
- Shadow never calls the configured trajectory controller.
Upgrade and removal
Re-run the verified installer command to upgrade. Run sudo /opt/rlsok/uninstall.sh to remove installed runtime versions and the system command. User configuration and Evidence are preserved so removal does not destroy audit records.
Responsibility boundary
RLSOK determines whether a specific release remains eligible for the configured controller path. It does not determine whether resulting physical motion is safe, and it is not a hard real-time or functional-safety system.
Independent E-stops, safety PLCs, certified controllers, motion limits, mechanical safeguards, site procedures, and hazard analysis remain required. No physical robot validation is claimed by this release.