Configure Robot

This repository still needs robot-specific configuration before it is safe to run on hardware. It cannot know your exact wiring, motors, gear ratios, or mechanism limits ahead of time.

Before you test on real hardware, update the robot configuration so the code matches the physical machine. If these values are wrong, the robot may fail to move, move in the wrong direction, or behave unsafely.

If you have not decided whether your mechanism should be modeled as Flywheel or PositionJoint, read Mechanism Types first.

In this step you will

What to configure

  • Hardware config Assign CAN IDs, ports, and other device identifiers so each subsystem can find the correct hardware. Start here, because no other configuration matters if the code is talking to the wrong device.

  • Mechanism gains and limits Update gear ratios, inversion, unit conversions, control gains, and safe motion limits for each mechanism. These values determine how the robot interprets sensor feedback and commands motor output.

Expected result

After configuration:

  • The robot builds and deploys successfully.

  • Devices appear on the expected bus with no ID conflicts.

  • Mechanisms move in the correct direction.

  • Sensor readings and commanded motion use the expected units.

  • Basic subsystem behavior works before any serious tuning begins.

Common mistakes

  • Skipping hardware ID verification A mechanism that does nothing is often mapped to the wrong CAN ID or port.

  • Copying constants from another robot unchanged Even similar mechanisms can require different gear ratios, inversion, limits, and gains.

  • Tuning before configuration is correct If IDs, units, or inversion are wrong, tuning will waste time and may make debugging harder.

  • Expecting calculator values to be final ReCalc is a starting point. Real tuning and verification are still required on the robot.

  • Ignoring safe limits Always set reasonable minimum and maximum positions before testing real motion on a new mechanism.