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 observerUse 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.
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
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.
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.