Documentation

Architecture

A Repose application is a Copper application. Repose supplies the manipulation components; Copper supplies the static graph, the message clock, logging and replay. There is no Repose runtime of its own.

The pipeline

One motion, end to end. Every arrow is a typed Copper message; every box is either a library call or a task named in RON.

the plan → time → follow → control loop
joint_statePlanRequestPlanPathTrajectorysetpointJointCommandBridgerobot or simulatorGoalCuJointGoalTaskPlannerplanner taskTimingCuPlanToTrajectoryFollowerCuFollowTrajectoryControllerCuControllerTask
  1. State. A bridge publishes CuJointStatePayload<N> — measured positions, velocities and robot status — on its joint_state channel.
  2. Goal. CuJointGoalTask pairs the first ready state with a configured goal and emits one CuJointPlanRequest. Your own source task can emit requests instead.
  3. Plan. A planner task searches joint space for a collision-free path and publishes a CuJointPlanPath — including on failure, with a status that names the reason.
  4. Time. CuPlanToTrajectoryTask turns the geometric path into a timed CuTrajectoryPayload inside the configured velocity and acceleration limits.
  5. Follow. CuFollowTrajectoryTask samples that trajectory on the message clock and emits a setpoint each cycle.
  6. Control. CuControllerTask compares setpoint and measured state, applies the watchdog and rate limit, and emits the one command type every bridge carries: CuJointCommandPayload<N>.
  7. Bridge. The bridge translates that payload to the robot (or simulator) and feeds measured state back. Swapping robots changes this box only.

Library or task?

Most crates ship both surfaces over the same code. Call the library when you drive the logic yourself — a pre-flight check, a test, a one-off IK solve. Use the task when Copper should drive it: the task owns scheduling, config from RON, freezing for replay, and publishing results as messages. Applications normally compose tasks and write no glue code; the MuJoCo example is a complete loop whose only application code is a test observer.

The rules everything follows

  • Static over dynamic. Joint count and every capacity are const generics. A 6-axis arm is CuKinematicChain<6>; a trajectory is CuTrajectoryPayload<6, 1024>. Sizes are checked at compile time, not at runtime.
  • Zero allocation on the hot path. Hot-path methods write into caller-owned &mut buffers and return a status. Nothing in a task cycle parses XML, looks names up, or grows a container.
  • no_std runtime, std startup. Runtime crates build with default-features = false for embedded targets. The one std-only step — URDF/SRDF parsing — happens once at startup and produces the same fixed-size models.
  • Typed units. Public APIs use Copper SI types (Angle, Length, velocities, accelerations). Joint values are CuJointPosition: Revolute(Angle), Prismatic(Length) or Fixed — a metres-where-radians bug is a type error.
  • Failures are data. Fallible calls return CuResult; planners and IK publish an explicit status (CuPlanStatus, CuIkStatus) instead of dropping the result. Library and task code never panics.
  • Deterministic. Sampling planners draw all randomness from the job seed (a Copper CuRng resource), and Copper logs every message. Replaying the .copper log reproduces the run, plan included.
  • Configured, not coded. Robot, models, planner, limits and speeds are RON config. Tasks never pick a robot implicitly: chain is always given, as a preset name or an inline spec.

Where robots plug in

Bridges live outside the core workspace, in repose-bridges, and implement the vendor-neutral contract: the same four channels and session lifecycle for an igus ReBeL, a UR arm, URSim or MuJoCo. That is why the template's src/program.rs does not change when the robot does.