Autonomous Vehicle Testing and Configuration Management

This web copy is a reference version for members. The controlled copy is the signed document held by the team; in a conflict, the signed document governs. Reading it does not replace induction, training or per-activity clearance.

1 Scope and Applicability

This SOP covers every occasion on which a Racerbot vehicle is powered with the wheels able to turn, and the configuration control that makes a test result mean something. It applies to bench testing, low-speed testing in ASB 9819, and course testing in the corridors and open floor space adjacent to the workspace.

Testing is indoors only, on the Burnaby campus, and only after 17:00 when the route is clear of routine through traffic. The vehicles are 1/10-scale F1TENTH/RoboRacer platforms with a speed ceiling of 8 m/s (about 29 km/h).

• Applies to every member taking part in a test session in any role, including spotters and observers.
• The Test Lead role is assigned by the Tech Team Lead, the Autonomous Team Lead, or a member either of them has named in writing for that session.
• Outdoor testing, testing in a public thoroughfare during business hours, testing above 8 m/s, and testing at a venue Racerbot does not control are all outside this SOP.
• Competition running is governed by the organiser’s rules in addition to this SOP. Where the organiser is stricter, the organiser governs.

Any person present; member, spotter, passer-by or visitor may call STOP at any point. Everything stops immediately and does not restart until the Test Lead has heard the concern and resolved it. Calling a stop in good faith never counts against anyone.

1.1 Purpose

This SOP exists to make sure a moving vehicle can always be stopped, that nobody who has not agreed to be near it can get near it, and that when a run goes wrong the team knows exactly which software and hardware were on the car at the time.

1.2 Keywords

F1TENTH; RoboRacer; deadman; LB; ackermann_mux; teleop; autonomy; VESC; LiDAR; test lead; spotter; exclusion zone; course; build record; configuration management; SOP-TECH-01; SOP-ADM-09.

1.3 Contact

Questions about this document or the equipment it covers go to the Tech Team Lead. Questions about the workspace go to the Operations Coordinator. Questions about safety go to the FAS Safety Officer. Contact details are available to members through the team’s internal channels.

2 Introduction

The vehicle is small, fast and, in autonomous mode, driven by code that a student wrote this week. Two things follow. The car must be stoppable by a human any time during testing, and it must never be able to reach a person who is not part of the test.

The software enforces the first of those. Every node in the Racerbot workspace that can move the car — manual teleop and every autonomy node alike — refuses to publish a non-zero drive command unless a person is physically holding the LB button on the controller and the controller stream is live. That check runs before every other watchdog in the node. Let go of LB and the car stops, regardless of what the software thinks it is doing.

The barriers, the spotters and the 17:00 rule enforce the second. They exist because the corridor is a shared space and the people in it did not sign up to be near a test.

3 Equipment and Apparatus

4 Materials and Supplies

• Lithium polymer packs, 2S to 4S, handled entirely under SOP-TECH-01. Packs are charged in ASB 9819 before the session and carried to the test site at charge, in a fireproof bag inside a rigid container.
• No chemicals are used in this procedure. Isopropyl alcohol for cleaning tyres or sensors stays in the workspace under SOP-TECH-06 and is not brought to a corridor session.
• Spare fasteners, tyres and a basic tool roll, so a loose part is fixed rather than run on.

5 Hazard Assessment

6 Hazard Control Measures

6.1 Mandatory engineering controls and PPE

Engineering controls

LB deadman enforced inside every node that can move the car; 8 m/s software speed ceiling; teleop priority over autonomy at the command mux; continuous physical barrier on both sides and both ends of the course; bench stand that lifts the wheels clear for powered bench work.

Required PPE

Closed-toe, closed-heel shoes for anyone inside the barrier line; high-visibility vest for spotters and for anyone setting out or striking barriers in a corridor.

Change-out

Barrier tubing that no longer stands up or no longer forms a continuous line is repaired or replaced before the next session.

6.2 The four levels of stop

Every member briefed for a session must be able to state these four in order. They are tested at the start of each session as part of the Section 7 checklist.

1. Release LB on the controller — Every driving node stops publishing a non-zero command within one control cycle. The car stops. The default. This is how a run is ended, every time.
2. Ctrl+C the control-layer terminal — The driving node exits. Nothing is publishing drive commands; the mux times out after 0.2 s. When the car is stopped but the software is misbehaving, or level 1 did not appear to work.
3. Catch the car — Spotter at the nearest corner moves to intercept car with tubing to prevent car from moving When the terminal command isn’t connected to the car.
4. Disconnect the battery — All power removed. The car is inert. Last resort, and only when the car is stationary and safe to approach.

6.3 Roles for a course session

A course session does not run without a Test Lead, an operator and a spotter at every corner. If there are not enough people, the session is a bench or low-speed session instead. There is no version of this where a corner goes unwatched.

6.4 Waste disposal

• Broken chassis parts, tyres and printed components go to general or plastics waste as appropriate. Nothing from a test session is hazardous waste unless a pack was damaged.
• A pack damaged in a crash is handled and disposed of entirely under SOP-TECH-01 §6.4 and §8.5. It is never put in general waste.

7 Pre-Run Inspection Checklist

The Test Lead completes this before the first run of every session. If any item fails, the session does not start.

• It is after 17:00 and the route is clear of routine through traffic Observation
• Barrier forms a continuous line down both sides and closes both ends Walk the perimeter
• Signs posted at both ends with the Test Lead’s name and number Visual
• Course is clear of open stairwells, unsecured doors, drops and fire equipment Walk the route
• A clear walking route past the course remains available to others Walk it
• A spotter is posted at every corner and each one has been briefed Headcount
• Everyone present can state the four levels of stop Ask them
• Controller battery charged; F710 in XInput mode; link stable Controller and terminal
• Deadman test passed: wheels raised, arm the car, release LB, wheels stop Observed by Test Lead
• Chassis fasteners, steering linkage, wheel nuts and body mounts secure Hand check
• LiDAR clean, seated and unobstructed; sensor mounts tight Visual
• Battery pack passes SOP-TECH-01 §7 and is strapped in, not taped Inspection and hand check
• Software build recorded in the run log: branch, commit, parameter set Run log
• Any new or changed autonomy code has been run in simulation first Run log

8 Procedure

8.1 Before the session

1. The Test Lead confirms the session plan: what is being tested, which build, what speed, and how many people are needed.
2. All code that is run on car must be pre-tested in simulation.
3. Packs are charged in ASB 9819 under SOP-TECH-01 and carried to the site in a fireproof bag inside a rigid container. Charging never happens at the test site.
4. The Test Lead records the intended build: branch, commit and parameter set, in the run log before the car is powered.

8.2 Setting out the course

1. Choose a route with no open stairwell, no unsecured door swinging into it, no drop and no fire equipment inside the barrier line.
2. Set out the barrier tubing as a continuous perimeter down both sides and across both ends. A gap in the barrier is a gap the car can leave through and a gap a person can walk in through.
3. Post a sign at each end: TESTING IN PROGRESS — DO NOT ENTER.
4. Leave a clear walking route past the course. Never barrier a corridor end to end so that someone has to turn back.
5. Position spotters at every corner. Brief each on their sight lines and confirm each can be heard by the operator.

8.3 Briefing

The Test Lead briefs everyone present, every session, even when the same people did the same thing yesterday. The briefing covers: what is being tested; the four levels of stop; that anyone may call STOP; who is spotting which corner; where the extinguisher is; and what to do if the fire alarm sounds.

8.4 Running

1. The Test Lead declares the course live. From this point nobody crosses the course and nobody steps inside the barrier line without the Test Lead declaring it clear first.
2. Start the foundation layer (bringup). The car will not move from this alone — that is by design.
3. Start exactly one control layer: manual teleop, or an autonomy node. Never both. Two control layers running at once means the one you are testing is silently ignored.
4. Build up in stages. Walking-pace run first, then half speed, then target speed. A new build or a new course starts at walking pace regardless of how well it ran in simulation.
5. The operator holds LB for the run and releases it to end the run.
6. Abort immediately if anyone approaches the barrier, if the car behaves unexpectedly, if a spotter calls STOP, if a part comes loose, or if anything smells hot. Aborting costs a run. Not aborting costs more.
7. Between runs, the car is disarmed before anyone touches it. Nobody reaches into a powered vehicle.

8.5 Ending the session

1. Release LB, stop the control layer, then the foundation layer.
2. Disconnect the pack. Bring it back to storage voltage under SOP-TECH-01 §8.3 before putting it away.
3. Strike the barriers and signs and leave the route exactly as you found it.
4. Complete the run log while the session is still fresh, including anything that surprised you.
5. Report any collision, near miss or damage under SOP-ADM-09 the same day.

8.6 Configuration management and the build record

Each vehicle has a build record in the team repository. It is updated when the configuration changes, not at the end of the semester.

• Parameter changes made live during a session are recorded in the run log at the time and committed afterwards. A parameter that exists only in someone’s terminal history is not a configuration.
• After a collision or an unexplained behaviour, the exact build is frozen — nobody pushes over it — until the post-incident review under SOP-ADM-09 is done.

8.7 Troubleshooting

9 Collision, Injury and Property Damage

1. Release LB. Stop everything before you do anything else.
2. Look after the person first. Call 911 if the person is unresponsive or if the injury is serious, then Campus Public Safety on 778-782-4500.
3. Disconnect and quarantine the battery pack under SOP-TECH-01 §8.5. A crash damages pouch cells invisibly and the failure shows up on the next charge.
4. Photograph the scene, the car and the barrier layout before anything is moved.
5. Freeze the software build until review is complete.
6. Report the same day under SOP-ADM-09, and tell the Team Lead, the Operations Coordinator and the FAS Safety Officer.

10 Decontamination and Housekeeping

• Barriers, signs, cables and tools are struck and removed at the end of every session.
• Tyre marks and debris on the floor are swept or wiped.
• The vehicle is wiped down, inspected for damage and returned to its storage position in ASB 9819. Packs go back to storage voltage in their bags.
• Damaged parts are removed from the car rather than left fitted for next time, and the removal is recorded in the build record.

11 Emergency Procedures

11.1 Fire alarm during a session

1. Release LB and disarm the car.
2. Strike the barriers immediately — they must not obstruct anyone evacuating.
3. Evacuate. The car stays. Do not go back for equipment.
4. Go to the assembly area and account for everyone in the session.

11.2 Battery event during or after a session

Follow SOP-TECH-01 §11 exactly.

11.3 Injury

Call 911 for anything serious. Call Campus Public Safety on 778-782-4500 for first aid. Do not move a person with a suspected fracture or head injury. Send someone to meet responders at the building entrance and guide them in.

11.4 Reporting

• Injuries, fires, smoke, property damage, extinguisher use and near misses are reported the same day to the Team Lead and the Operations Coordinator, and to the FAS Safety Officer.
• An SFU incident report is filed for any injury, fire, exposure, property damage or significant near miss.
• The full process — what counts, who is told, how the review runs — is SOP-ADM-09, Incident Reporting and Post-Incident Review. Reporting in good faith is never penalised, including when the person reporting caused the problem.

Emergency contacts:

Assembly area for the Applied Sciences Building is the point shown on the evacuation map posted in ASB 9819. Do not re-enter the building until emergency or safety personnel authorise re-entry.

12 References

• SFU Racerbot POL-03 — Operations: Safety, Facilities and Property, §5.
• SOP-TECH-01 — Lithium Battery Safety, Charging and Storage.
• SOP-TECH-06 — Day-to-Day Lab Operations and Housekeeping.
• SOP-ADM-09 — Incident Reporting and Post-Incident Review.
• Racerbot car workspace documentation — architecture and safety model, including the LB deadman policy and the command arbitration priorities. github.com/sfu-racerbot.
• F1TENTH / RoboRacer platform documentation and build guide.
• SOP-004-FAS — Lithium-Ion and Lithium Polymer Battery Safety and Emergency Response, Faculty of Applied Sciences, Version 1.0, August 2026.
• SFU Racerbot Student Team Risk Assessment, 2026-09-10.
• SFU Racerbot Student Team Lab Safety Plan, 2026-09-10.

Appendix A — Attachments

Attachments are listed in the order they are referenced and filed behind this page.