Localisation loss or jump
Stop autonomous motion, preserve pose/scan/TF evidence and reassess map and start-zone assumptions.
Level-seven field evidence tool · 03
TurtleBot3 route, obstacle and failure acceptance matrix
A seventh-level field record for connecting one robot, map, Nav2 configuration and supervised indoor site to complete route attempts, interventions and release triggers.
Evidence statusSupervised site record · blank template · no unattended-service approvalField definitions reviewed 4 August 2026
How to use
Freeze the object and boundary before recording any result.
Use one matrix for one immutable robot/software/map/site release candidate. It records all route directions, representative obstacles, failure cases, operator interventions and environmental variations before a bounded supervised release.
- 01Freeze robot, firmware, ROS 2, Nav2 packages, parameters, map, footprint and site contract.
- 02Define route start/goal zones, direction, obstacle cases, success, intervention and near-miss criteria.
- 03Verify reachable stop control and keep the supervisor outside the robot path.
- 04Include blocked-path, localisation-loss, sensor-timeout and communication-loss cases.
Field dictionary
Every conclusion should resolve to a field, raw evidence and a rejection condition.
| Code | Field | Input format | Evidence to preserve | Reject condition |
|---|---|---|---|---|
| MOB-001 | Release candidate | Robot model/serial, hardware, OpenCR/SBC firmware, ROS 2/Nav2 commits and battery state | Signed manifest and diagnostic snapshot | Any component differs from the candidate manifest |
| MOB-002 | Map and frame baseline | Map hash/date, map-odom-base transforms, footprint, sensor frames and inflation/keep-out parameters | Map bundle, TF record and parameter export | Stale map, frame discontinuity or undocumented footprint |
| MOB-003 | Site contract | Layout revision, floor, lighting, access, doorway widths, operating period and dynamic-obstacle policy | Dated site drawing and pre-run inspection | Material site difference is not assessed |
| MOB-004 | Route definition | Route ID, start/goal zone, direction, expected corridor, obstacle case and repetition count | Predeclared route catalogue | Route or success criteria created after observing results |
| MOB-005 | Run evidence | Pose/path, command/odometry, localisation, sensor health, planner/controller events and video time base | Immutable rosbag/log export and event index | Only screen video or summary metrics remain |
| MOB-006 | Outcome and intervention | Success/failure, time, path deviation, near miss, recovery, stop and operator action | Complete row for every attempt including aborts | Intervention hidden inside a success result |
| MOB-007 | Failure case | Blocked path, no path, localisation loss, sensor timeout, communication loss or stop input | Expected/observed state and bounded recovery record | Failure response is inferred rather than exercised |
| MOB-008 | Release and regression | Golden routes, thresholds, deviations, accepted site/configuration, expiry and retest triggers | Reviewer-signed bounded release | Release omits change triggers or supervision requirement |
Run matrix
Record success, failure, aborts and human intervention in one matrix.
| Attempt ID | Route/direction | Obstacle/failure case | Config/map hash | Raw evidence | Outcome/time | Intervention/near miss | Disposition |
|---|---|---|---|---|---|---|---|
This blank structure is not evidence of a passed test, certification, compliance opinion or permission for unsupervised operation.
Failure taxonomy
Name the failure so the next run can be materially different.
Sensor or transform timeout
Reject the run; verify lifecycle, clock and data freshness before the next attempt.
Unsafe planning/recovery
Stop, preserve planner/controller events and do not tune only against the observed route.
Contact, keep-out entry or near miss
Reject the candidate release and reopen site, footprint, sensing and obstacle-policy review.
Release questions
Discuss a bounded release only when every question points to evidence.
- 01Is every accepted attempt bound to one robot, software, map, parameter and site hash?
- 02Do both route directions and every declared start/goal zone have evidence?
- 03Are interventions, aborted attempts and near misses counted separately from autonomous success?
- 04Were blocked path, localisation loss, sensor timeout, communication loss and stop input exercised?
- 05Does the release state exactly which changes, dates or events trigger regression testing?
FUURAA analysis
A record should reconstruct the decision—not decorate the result.
The route matrix prevents a navigation demo from becoming an unbounded deployment claim. Its essential unit is not success rate alone, but route × direction × obstacle/failure case × immutable configuration × intervention record.
Primary sources