Physical-robot observation

Confirm both running Gen3 bridge paths—with subscriptions only.

This observer reads the wearable rig's existing left and right high-level bridge topics. It never opens a Kortex session, starts bringup, publishes a target, calls a service or homes an arm.

Updated · RLSOK

Download the dual Kinova observer
01

Use the real bridge signals the mock path does not have

The selected public stack launches /kortex_highlevel_bridge_left and /kortex_highlevel_bridge_right for its real high-level path. Each publishes arm-labelled session health and telemetry alongside /real/joint_states. Its mock launch can publish joint state but does not provide those two real-bridge session and telemetry paths.

The observer requires both exact bridge publishers, a connected session message for each arm, /real/telemetry_left, /real/telemetry_right and seven selected joints per arm. Run it only during an owner's existing normal session; do not launch or move the arms for this capture.

02

Download and capture once

Pass the root of the checkout actually running. The v2 bundle records its commit, dirty state and origin. The ZIP is 26,442 bytes; its SHA-256 is 59e4c7a011fb25bc23cf647a62c6d4f52c8c3e14b74fcb4b03ccec586124c433.

curl -fLO https://github.com/realitywarden/rlsok/releases/download/dual-kinova-status-observer-v2/rlsok-dual-kinova-status-observer-v2.zip
curl -fLO https://github.com/realitywarden/rlsok/releases/download/dual-kinova-status-observer-v2/rlsok-dual-kinova-status-observer-v2.zip.sha256
sha256sum -c rlsok-dual-kinova-status-observer-v2.zip.sha256
unzip rlsok-dual-kinova-status-observer-v2.zip
cd rlsok-dual-kinova-status-observer-v2/experimental/composable-shadow
source /opt/ros/jazzy/setup.bash
source /path/to/wearable-dual-arm/install/setup.bash
python3 dual_kinova_status.py   --source-root /path/to/wearable-dual-arm   --output dual-kinova-status.json
03

What the file records

  • Connected session state and recovery count for both named high-level bridges.
  • Selected fault, heat, gripper and contact telemetry for each arm.
  • Seven left and seven right joint positions, stamps, publisher endpoints and the ROS environment.
  • The actual checkout commit and a SHA-256 digest of the complete observation.
04

What it cannot prove

The result is stronger than a generic joint-state echo because the public mock path lacks the required bridge signals. It still cannot authenticate either physical arm, Kortex network peer or IP ownership, prove safe motion, grant permission to move or establish customer acceptance.

Return dual-kinova-status.json with one sentence confirming that both physical Gen3 arms and their normal bridge processes were present. If it fails, return the exact error; do not change the rig or start a second Kortex session for RLSOK.

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

Can this observer open either arm's Kortex session?

No. It creates ROS subscriptions only and has no Kortex API, publisher or service-client surface.

Will the repository's normal mock path pass?

No. Joint state alone is insufficient; both exact real-bridge session and telemetry paths are required.

Does a passing JSON authenticate both physical arms?

No. Pair it with the owner's confirmation of the physical session, exact checkout and normal bridge processes. ROS endpoint metadata is not hardware identity.

Continue with the relevant guide

Try the local example without an application. For setup or integration help, you can also contact us.