Recent shipped improvements, what changed and how to try them. Each update links to its published release and setup guide.
Current download: RLSOK Local Check 1.5.0. It compares files and sample inputs on your computer. Existing robot setups and Windows management apps have their own update instructions.
Older email links and versioned files remain available. To update an existing robot setup, use its runtime release notes.
v1.5.0 · Local Check release
An easier first try, with a clear download
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.
RLSOK Local Check now uses version 1.5.0. It includes the local checking features from the earlier previews, including ArmPilot, Beast and Pioneer-X Pure Pursuit/MPC saved-file comparisons.
The download page starts with your computer and what you want to do. It shows download size, a copy button for the commands, and plain-language explanations of the two results.
Installers now select the same version as their download package. Older email links, downloads and checksums remain available. The separate robot-runtime and Windows management-app update paths retain their actual versions.
Verification: TypeScript build and package assembly; generated installer/archive/version checks; the packaged sample checked using the Windows host Node runtime. No full suite or GitHub Actions. The Linux installer was not executed on this host.
This release compares local files and example inputs. It sends no robot commands and does not establish live hardware state, private-interface compatibility or customer acceptance. Pioneer Carrot remains unsupported.
Save a selected Pioneer-X Pure Pursuit or MPC configuration with firmware and host source, then compare parameter or algorithm changes against the same reviewed baseline.
The independent Pioneer-X workflow reads the saved tracker JSON and firmware file, copies the related host source, and shows differences such as lookahead 0.6 → 0.7 or a switch to MPC. It includes a selection helper and labeled source-default examples.
Missing or invalid settings and unsupported algorithms are refused. The public Carrot/proportional route and settings path remain unresolved; no live switch interception or command arbitration is claimed. Includes the prior ArmPilot and Beast improvements.
Verification: TypeScript build, twelve focused offline public-source or synthetic checks, and the selection-helper/CLI preparation with 23 files. No full suite, GitHub Actions, ROS, SCADA, micro-ROS, firmware execution or motor command.
Saved files do not establish the current SCADA configuration, active publisher, flashed firmware, hardware identity, Humble compatibility, tracking performance or customer acceptance.
Independent ArmPilot review and Beast node parameters
Compare saved ArmPilot configuration and source without starting the arm, and inspect Beast's updated parameters in their individual ROS 2 node blocks.
ArmPilot RemoteControl and selected MeArm-V1 3D files can be prepared independently, approved as a local baseline and compared later. Reports show changes such as joystick deadband 5 → 6, calibration offsets and firmware source edits. A selection helper and source-path map are included.
Beast preparation and inspection now read the updated esp32_bridge node block, retain teleop and odometry settings under their own nodes, and reject conflicting saved selectors. The earlier wildcard layout remains supported.
Verification: TypeScript build, twenty focused offline public-source or synthetic cases, and both ArmPilot selection-helper/CLI preparation paths. No full test suite, GitHub Actions, robot process or device connection was run.
These workflows compare selected saved files. They do not establish installed firmware, EEPROM state, live overrides, upstream integration, physical position or customer acceptance.
Selected-input checks and readable configuration differences
Inspect selected SO101, Beast and Cartesian configuration relationships before approving a saved baseline, and see the actual before/after values when it changes.
SO101 reports motor/calibration/controller/model mismatches. Beast reports duplicate YAML and command-timeout parameter differences. Cartesian review maps single/dual joints and frames, with optional checks of saved native pose, wrench and JointMove messages.
Saved comparisons retain missing/invalid files and reject ambiguous device aliases. Metal preparation supports Star, vertical Star and Metal leader selections.
Verification: TypeScript build, Python syntax/source review, eighteen bounded offline source or synthetic scenarios, and six native Metal workflow outcomes. No full test suite, GitHub Actions or robot process was run.
Static and saved-message checks do not install a live ROS gate or establish hardware compatibility. Actual private selections, runtime integration and customer acceptance remain separate.
Review an operator-confirmed Piper camera and arm mapping, or compare paired ROS bridge and Sunrise source copies, before connecting the workflow to a robot.
Piper input records single/bimanual selection, side, joint/delivery mode, camera serials, robot serials and CAN adapter identities without requiring a native launch file.
KUKA preparation pairs the selected C++ bridge, Java application and launch files. USB metadata discovery no longer substitutes a parent hub serial for a missing device serial.
Verification: TypeScript build and targeted offline comparisons: twelve Piper mapping scenarios and one deliberately changed public Java port. Changed Python source was syntax-reviewed. No full test suite or Actions was run.
The comparisons use saved inputs. They do not establish fresh device discovery, customer GUI integration, deployed cabinet state, physical compatibility or customer acceptance.
Resolve reviewed camera and adapter identities into configuration copies, save a reviewed baseline, and compare later setup changes without opening hardware.
New preparation guides cover Piper, MakerMods Metal, the SO-101 hardware branch, Dons Beast and Cartesian single/dual configurations. Reports distinguish device renumbering from changed settings, calibration and source.
Missing or ambiguous device matches require review. Separate source workspaces map the SO-101 five-joint trajectory input and the Beast Twist bridge; current configuration and interface evidence are still required.
Verification: Reviewed against pinned public source, with a TypeScript build, Python syntax compilation and package integrity checks. No test suite or GitHub Actions was run for this release.
These are saved, self-attested configuration comparisons. They do not start a robot, prove physical identity or compatibility, install a command gate, or establish customer acceptance.
Capture a selected Tello setup, approve its baseline locally, and compare fresh observations as the existing ROS 2 client makes service calls.
The local watcher records the exact request and compares selected files, ROS environment, installed TelloAction definition and client/server associations. Changed, missing, stale or ambiguous evidence cannot establish a match.
The package includes capture, approval, watch and review commands, the optional client patch, a selection template, and JSON/Markdown reports. Without approval, the watcher only captures facts.
Verification: Checked with four TypeScript test groups, eight Linux recorder checks and seven ROS 2 Jazzy service scenarios using the public client class and localhost mock services.
Tello reports are post-call configuration comparisons. RLSOK sends, blocks, cancels and retries zero robot commands. Physical-drone use and customer-specific configuration remain unverified.
Compare a selected running Nav2 graph and exact FollowPath goal with a local approval. Hexapod comparisons now include fresh gait parameters and the downstream controller binding.
Nav2 checks cover the selected path, controller/goal/progress selectors, observed command chain and freshness. A matching goal can only be handed to a local evidence-file sink; the CLI has no robot action transport.
Hexapod preparation and refresh require controller-state and gait-node exports. Existing workspaces need a new explicit review to include these facts; approvals are never silently upgraded.
Verification: Checked with real Jazzy/Nav2 processes, a Gazebo command path and the public Hexapod model in neutral stance. Changing the gait cycle time changed the report from WOULD_ALLOW to WOULD_BLOCK under the same approval.
These are zero-dispatch evaluation workflows. Simulation and observed ROS metadata do not establish physical-robot identity, motion safety or customer acceptance.
Source workspaces and active controller comparisons
Prepare a separate local review workspace from five inspected public ROS 2 source layouts, using actual selected files and interface facts.
Source recipes cover Hexapod, SO-101, TRIK, the LelyRobot Python bridge and an autonomous rover Gazebo bridge. Preparation creates neither an approval nor a fabricated observation.
SO-101 and TRIK preparation requires a fresh read-only export of the active controller. Later controller changes are compared with the existing approval.
Verification: Checked the pinned public source files and exercised SO-101/TRIK controller replacement with actual ROS controller processes and mock hardware, without sending motion commands.
A public source recipe is a starting point for the selected interface. Local changes, actual device mappings and physical-hardware results still need to be supplied and reviewed.
