Confirm the running LelyRobot sensor path—without touching its command path.
When the owner already has LelyRobot running for normal maintenance, this observer subscribes to one /ultrasonic_left message and writes a digested JSON file. It never opens the serial port, publishes /cmd_vel, calls a service or starts the robot.
Updated · RLSOK
Download the LelyRobot observerUse the sensor path that already exists
The pinned public LelyRobot source keeps the read and command paths separate at ROS level: /arduino_bridge publishes sensor_msgs/msg/Range on /ultrasonic_left, while motor commands arrive on /cmd_vel. The observer listens only to the sensor topic.
Run it only while the owner's normal Python or C++ bridge is already active. Do not power the robot, start bringup or open a second serial connection solely to create this file.
Download and capture once
Download the v3 read-only status bundle and checksum, source the ROS 2 workspace that already sees LelyRobot and select the bridge process actually running. Pass the actual checkout root; the observer records its commit, dirty state and origin. The 37,906-byte ZIP has SHA-256 f1c37feab0f1475cc7e92a47f71186feba307de3214918850102d9677a1ccf02. It waits for a transient unknown ROS publisher name to resolve, then still requires the expected bridge.
curl -fLO https://github.com/realitywarden/rlsok/releases/download/live-status-observers-v3/rlsok-live-status-observers-v3.zip curl -fLO https://github.com/realitywarden/rlsok/releases/download/live-status-observers-v3/rlsok-live-status-observers-v3.zip.sha256 sha256sum -c rlsok-live-status-observers-v3.zip.sha256 unzip rlsok-live-status-observers-v3.zip cd rlsok-live-status-observers-v3/experimental/composable-shadow source /opt/ros/humble/setup.bash source /path/to/lelyrobot_ws/install/setup.bash python3 lely_status.py --source-root /path/to/Lelyrobot --bridge-variant python --output lely-status.json
What the file checks
- Exactly one sensor_msgs/msg/Range publisher named /arduino_bridge on /ultrasonic_left.
- A non-empty sensor frame, valid ultrasonic/infrared type and finite range values inside the message's declared bounds.
- ROS distribution, RMW implementation, domain ID, message stamp, endpoint GID, source commit and selected Python/C++ bridge variant.
- A SHA-256 digest of the complete observation.
What it cannot prove
One ROS sample is useful evidence that the selected sensor path was live. It does not authenticate the Arduino or flashed firmware, establish which physical chassis produced the sample, prove motor stopping or command delivery, or approve movement.
Return lely-status.json only with the exact checkout commit and confirmation that the physical robot and normal serial bridge were present. Keep that owner statement separate from what the JSON itself proves.
Sources and verification scope
Source code and guides describe implementation and setup. Release notes identify reported checks and their limits. Publication alone does not establish customer use or physical-robot validation.
Frequently asked questions
Does this open or write to the LelyRobot serial port?
No. It subscribes only to the already-running ROS sensor topic and has no serial, publisher or service-client surface.
Does it send a stop command for safety?
No. A stop command is still a hardware command. This observer sends nothing and must be used only during the owner's normal maintenance session.
Is the JSON alone proof of a physical LelyRobot run?
No. The owner must also identify the exact checkout, active bridge and physical session. The JSON cannot authenticate the Arduino or distinguish every possible mock publisher.
Continue with the relevant guide
Try the local example without an application. For setup or integration help, you can also contact us.