Skip to main content

RobStride Runtime Parameter Table

MotorBridge keeps the upper-level RobStride API shape shared across RS models. The active runtime parameter table is the protocol section 4 “read/write single parameter” list in the 0x7005..0x702E range. Older/manual 0x2000 and 0x3000 function-code fields are not split into per-model high-level tables in v0.5.0.

Runtime Rules

  • Runtime parameter read/write uses communication type 17/18 plus the parameter index below.
  • Parameter index is little-endian in byte[0..2]; the typed value is little-endian in byte[4..8].
  • Parameters that must survive power-cycle require type 22 save after writing. In v0.5.0, robstride-write-param --store 1 performs write, optional verify, then save.
  • Type 18 write ACK timing: communication type 18 parameter writes do not block by default. Set MOTORBRIDGE_ROBSTRIDE_WRITE_ACK_TIMEOUT_MS to enable a conservative synchronous wait when a firmware ACK is required.
  • RobStride set_zero_position() keeps the same upper-level API and writes zero_sta(0x7029)=1 so zeroed motors use -pi..pi on startup. Use store_parameters / --store 1 to persist it.
  • Type 22 save uses payload 01 02 03 04 05 06 07 08 and waits for a RobStride status ACK.

Communication Types Used

Section 4 Parameter List

Persistence and Zeroing Notes

  • W/R or W only means the parameter can be written over CAN; it does not guarantee persistence by itself. Use motorbridge-cli robstride-write-param ... --store 1 when a parameter value must survive power cycling. motorbridge-cli run --vendor robstride ... --mode save remains available as a direct save operation.
  • For RobStride zeroing, MotorBridge keeps the same upper-level command as other vendors. It sends type 6 and then writes zero_sta(0x7029)=1; with --store 1, type 22 saves the -pi..pi startup behavior.
  • Use radians for all position quantities and radians per second / radians per second squared for velocity and acceleration.

Examples

Read mechPos:
Write damper=1 and save:

RobStride Zero Calibration

Use the unified Python package CLI. The current CLI uses subcommands, so RobStride control commands must start with motorbridge-cli run. Before writing zero:
  • Use a verified adapter path, preferably PCAN or a tested CANable/candleLight SocketCAN interface.
  • Scan first and confirm the target motor-id and feedback-id.
  • Move the joint by hand to the real mechanical zero pose.
  • Do not run this command while the mechanism can collide or fall.
Scan and confirm the motor is online:
Read state once:
Set the current mechanical pose as zero. --zero-exp 1 is required for RobStride; without it, MotorBridge prints a warning and does not send the zeroing CAN frame. --store 1 saves the result when the firmware accepts it.
Verify by reading state again:
Then test a small move and return to zero:
For RobStride, MotorBridge also writes zero_sta=1 so the startup range is intended to be -pi..pi. Use the model that matches your motor for limits and logging; the examples above use rs-00.

PP / CSP Position Modes

RobStride-specific pos-vel-pp and pos-vel-csp control paths follow the vendor manual sequences for PP (Profile Position) and CSP (Cyclic Synchronous Position) modes. They are exposed through the C ABI (robstride_send_pos_vel_pp(), robstride_send_pos_vel_csp()), the Python binding, and the Rust/Python CLI.
PP and CSP both write the position target to loc_ref (0x7016), but their velocity/acceleration registers differ — see API: Motor. PP/CSP full manual sequences include an enable ACK wait every control cycle; for high-rate loops use a prepared profile and write loc_ref directly each cycle. The example script robstride_posvel_timing_demo.py compares legacy pos-vel, full-sequence PP/CSP, and prepared high-rate profiles.