Docs menu
Code testing
The order to work in when your code runs on a real car: shell, build, tests, launch, then a clean stop.
A session on a car follows the same order every time: connect and source the workspace, build, run the tests, launch the foundation and one control layer, then stop in reverse. The commands are checked against the car workspaces, and the workspace docs cover each mode in more depth.
New tech team members pass the Linux terminal skills assessment in Stage 2 Tech onboarding before their first car session.
Rules for every session
The car can hurt itself, people and property, so two rules apply before anything else:
- Wheels off the ground for the first run of any new code or config change. The car sits on a stand until the change has done what you expected with no load on the wheels.
- Never set
enable_deadman: false. Every node that can move the car requires a person holding LB on the F710 controller, and that check is in each node’s own code. A node with the deadman disabled keeps driving after the person lets go.
The pre-run checklist is the full list to work through before the car moves.
- Build and testSource the workspace in each terminal, build with colcon and run a package's tests so that a missing import fails loudly.
- Launch and stopStart the foundation and exactly one control layer, check the controller and servo from a third terminal, and shut down without killing the drivers.
- TroubleshootingThe faults members hit most often in a session on the car, with the cause and the fix for each.