Skip to content

Configuration, calibration, and maintenance ​

These domains can change device state. Separate reads from writes, record the current configuration, and verify target identity before writing.

Configuration ​

Read hand.config.snapshot() before using a setter. Treat baud-rate, device-ID, and broadcast changes as connection-changing operations; close and rediscover the device as required by the API contract. Obtain joint, speed, and current limits from the target model's approved configuration rather than copying them from another model.

Change the slave ID (SDK 2.1.2) ​

hand.config.set_slave_id() accepts IDs in 1–247. Physically isolate the target hand on its bus, stop motion and Servo, and do not combine the change with calibration or reboot. The SDK requires exactly one connected Hand on the transport; it cannot detect physically attached devices that are not connected through the SDK. Setting the current ID performs no write.

Run from the public example repository root and replace the serial port:

bash
python python/revo3/device_operations.py --port /dev/ttyUSB0 --new-slave-id 2
./c/build/demo/device_operations /dev/ttyUSB0 --new-slave-id 2

These commands default to read-only; add --run to write. An acknowledged or uncertain address-changing write invalidates the original Hand and transport session. Closing Hand alone is insufficient: close the old Manager, create a new Manager, reconnect at the new address, and verify the actual ID and original serial number when available. Do not retry automatically or assume the new ID took effect after a lost response. A write acknowledgement does not guarantee when firmware switches or persists the address.

device_operations also refreshes motor serial numbers and firmware versions. A later touch read failure preserves successful motor reads and reports an incomplete refresh; cached data does not establish that all metadata refreshed successfully.

Calibration ​

Calibration and zero-position operations change the reference for subsequent motion:

  • Verify the mechanical setup and load.
  • Record firmware and configuration before the operation.
  • Set a timeout, but do not interpret timeout as proof that the operation was not applied.
  • Read zero position, State, and Health again after completion.

Firmware update ​

The SDK 2.1.2 firmware_update examples report transfer progress. Python exposes the on_progress callback and operation-handle progress; C++ exposes operation.progress(). 100% means transfer completion only. Reconnect and read the installed firmware version after the operation to verify the result.

Keep motion, configuration, and calibration traffic out of a firmware-update session. Confirm stable power, the target module, firmware package, and device model before starting.

After an interrupted or uncertain firmware operation:

  1. Record the last confirmed stage and structured error.
  2. Do not repeat a write whose effect is unknown.
  3. Reconnect and read FirmwareInfo and Health.
  4. Follow the recovery requirement to continue, reboot, or escalate for manual recovery.

Reboot, factory reset, and firmware update require explicit user intent and must not be generic retry actions. See the device-operation API.

Help