docs(perception): define traversability evaluation sequence
This commit is contained in:
DCCONSTRUCTIONS
@@ -1539,6 +1539,11 @@ production navigation cutover. The result remains replay-simulated;
|
||||
physical-live authority, commands, actuation, planner-authoritative free space
|
||||
and collision-safety acceptance are false. The next milestone boundary is
|
||||
M4.9 recorded-realtime release-candidate validation using this frozen graph.
|
||||
Subsequent operator visual review rejected the LOW-STEP connected-component
|
||||
camera boxes as a general static-obstacle product path. That decision does not
|
||||
alter the immutable M4.8R3 runtime evidence; it redirects the next perception
|
||||
evaluation to the terrain-relative sequence in
|
||||
[`docs/23_TRAVERSABILITY_AND_STATIC_OBSTACLE_STACK_DECISION.md`](23_TRAVERSABILITY_AND_STATIC_OBSTACLE_STACK_DECISION.md).
|
||||
|
||||
## Implementation order
|
||||
|
||||
|
||||
@@ -0,0 +1,278 @@
|
||||
# Traversability and class-free static-obstacle stack decision
|
||||
|
||||
Date: 2026-08-26
|
||||
Status: accepted for sequential recorded-replay evaluation; not accepted for
|
||||
navigation or actuation
|
||||
|
||||
## Decision summary
|
||||
|
||||
Mission Core stops treating the M4.8R3 `LOW-STEP` connected-component and
|
||||
camera-box projection as the product path for general static-obstacle
|
||||
perception. M4.8R3 remains immutable evidence that a bounded occupied-only
|
||||
heuristic can execute in the realtime envelope. Operator review of the complete
|
||||
visual result rejected its obstacle quality and representation:
|
||||
|
||||
- isolated vegetation, curb edges and sparse returns become false obstacles;
|
||||
- bins, carts, thin posts, railings and hemispheres are inconsistently lost;
|
||||
- spatially unrelated points merge into large rectangular camera regions;
|
||||
- one-frame components flicker without ground/obstacle evidence competition;
|
||||
- 2D rectangles erase the free passage between separate 3D obstacles.
|
||||
|
||||
This is an abstraction failure, not a threshold-tuning failure. A navigation
|
||||
system requires a terrain-relative occupancy and traversability product, not a
|
||||
detector that attempts to name every static object and not a bounding box as
|
||||
the safety primitive.
|
||||
|
||||
The sequential evaluation order is:
|
||||
|
||||
1. **GSeg3D + Nav2 Ground Consistency + Nav2 Costmap** — primary candidate.
|
||||
2. **TRAVEL + the same costmap boundary** — class-free challenger if the
|
||||
primary candidate misses compact or thin obstacles or merges passages.
|
||||
3. **Isaac ROS nvblox** — separate GPU occupancy/ESDF candidate after the CPU
|
||||
terrain contour is measured; it is not stacked into the first test.
|
||||
|
||||
RF-DETR remains the semantic risk provider for people, children, animals,
|
||||
cars, trucks, motorcycles and bicycles. It does not decide the presence or
|
||||
shape of an unknown static obstacle. Native `800x600` fisheye input remains
|
||||
unchanged.
|
||||
|
||||
## Required product representation
|
||||
|
||||
```text
|
||||
LiDAR + pose + optional IMU
|
||||
|
|
||||
v
|
||||
terrain-relative ground / non-ground evidence
|
||||
|
|
||||
v
|
||||
temporally stable local occupancy and UNKNOWN support state
|
||||
|
|
||||
v
|
||||
robot-footprint collision cost + traversability
|
||||
|
|
||||
+----> planner / collision monitor (future authority gate)
|
||||
|
|
||||
+----> camera projection (diagnostic visualization only)
|
||||
|
||||
camera RF-DETR ----> dynamic semantic risk hints ----------------+
|
||||
```
|
||||
|
||||
The canonical safety output is a costmap/elevation/occupancy product. Camera
|
||||
boxes may be derived for operator review, but a box must never be the source of
|
||||
occupied cells, clearance, passage width or a control action.
|
||||
|
||||
## Candidate A — GSeg3D and Ground Consistency
|
||||
|
||||
### GSeg3D
|
||||
|
||||
[DFKI GSeg3D ROS 2](https://github.com/dfki-ric/ground_segmentation_ros2)
|
||||
is a BSD-3-Clause ROS 2 component for CPU realtime processing of 3D LiDAR. It
|
||||
publishes separate ground and obstacle point clouds and provides:
|
||||
|
||||
- optional IMU gravity alignment;
|
||||
- two-phase coarse/fine ground segmentation;
|
||||
- configurable slope, local height and inlier thresholds;
|
||||
- ROS 2 Humble and Jazzy support;
|
||||
- no task-specific dataset or neural-network inference.
|
||||
|
||||
Mission Core evaluates it as the first replacement for the current local
|
||||
height connected-component heuristic.
|
||||
|
||||
### Nav2 Ground Consistency
|
||||
|
||||
[DFKI Ground Consistency](https://github.com/dfki-ric/nav2_ground_consistency_costmap_plugin)
|
||||
is a BSD-3-Clause Nav2 costmap layer and is included in the current
|
||||
[Nav2 outdoor 3D-LiDAR tutorial](https://ros-navigation.github.io/mkdocs.nav2.org/rolling/tutorials/general_tutorials/navigation2_with_ground_consistency_layer/navigation2_with_ground_consistency_layer/).
|
||||
It consumes ground and non-ground point clouds and supplies the missing product
|
||||
semantics:
|
||||
|
||||
- ground and obstacle evidence compete per costmap cell;
|
||||
- evidence accumulates and decays instead of trusting one point in one frame;
|
||||
- obstacle height is evaluated relative to local ground;
|
||||
- robot height and minimum clearance are explicit configuration inputs;
|
||||
- sparse cells can use bounded neighboring-ground interpolation;
|
||||
- a cell without reliable support can fail closed instead of becoming free.
|
||||
|
||||
The first test keeps all free-space and actuation authority false. The layer is
|
||||
evaluated only as a recorded-replay occupancy provider.
|
||||
|
||||
### Nav2 boundary
|
||||
|
||||
[Nav2 Costmap 2D](https://docs.nav2.org/configuration/packages/configuring-costmaps.html)
|
||||
provides footprint-aware obstacle, voxel and inflation layers. A later physical
|
||||
gate may add the independent
|
||||
[Nav2 Collision Monitor](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/core_servers/collision_monitor/configuring_collision_monitor_node/),
|
||||
but recorded replay does not publish commands.
|
||||
|
||||
## Candidate B — TRAVEL
|
||||
|
||||
[TRAVEL](https://github.com/url-kaist/TRAVEL) performs class-free traversable
|
||||
ground detection and above-ground instance clustering. Its ROS 2 wrapper is
|
||||
verified by the project on Humble and Jazzy. The published evaluation reports
|
||||
roughly `20-30 Hz` and explicitly targets safe navigation in unseen urban and
|
||||
wild environments without assigning names such as pole, vehicle or wall.
|
||||
|
||||
TRAVEL is valuable when individual compact obstacles and the gaps between them
|
||||
must remain spatially distinct. Its GPL-3.0 license prevents silent admission
|
||||
into a proprietary product runtime. It is initially a benchmark/challenger;
|
||||
distribution consequences require a separate decision.
|
||||
|
||||
Primary reference:
|
||||
[TRAVEL paper](https://arxiv.org/abs/2206.03190).
|
||||
|
||||
## Candidate C — Isaac ROS nvblox
|
||||
|
||||
[Isaac ROS nvblox](https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_nvblox/index.html)
|
||||
uses GPU-accelerated TSDF/ESDF reconstruction from depth and/or 3D LiDAR and
|
||||
publishes a Nav2 costmap. Current NVIDIA documentation supports ROS 2 Jazzy on
|
||||
x86_64 with an Ampere-or-newer NVIDIA GPU and at least 8 GiB VRAM; Worker 006's
|
||||
RTX 4090 is inside that hardware class.
|
||||
|
||||
Nvblox is evaluated separately because it answers dense occupied-space and
|
||||
clearance questions well, but it is not by itself a complete terrain-relative
|
||||
traversability classifier. Its official kernel timings are not an end-to-end
|
||||
Mission Core FPS guarantee.
|
||||
|
||||
## Candidates not admitted to the first sequence
|
||||
|
||||
| Candidate | Reason not first |
|
||||
| --- | --- |
|
||||
| Autoware Universe | Mature road-vehicle perception and occupancy, but a large automotive/lane-driving stack for this rover-sized contour. |
|
||||
| Offroad-Nav 2026 | Relevant complete pipeline, but currently ROS 1 Noetic; ROS 2 port is in development and the real-robot branch is not published. |
|
||||
| `elevation_mapping_cupy` | Strong GPU elevation-map implementation, but the maintained integration remains ROS 1/catkin. It is retained as an algorithmic reference. |
|
||||
| CMU AEDE/FAR/TARE | Proven research navigation components, but not the shortest supported ROS 2 product baseline for this test. |
|
||||
| Additional image segmentation model | Consumes GPU and still cannot establish metric support, clearance or unknown space. |
|
||||
|
||||
## Source representation boundary
|
||||
|
||||
`RAVNOVES00` does not contain a conventional complete raw LiDAR scan per video
|
||||
frame. Its `lio_pcl` stream is a registered vendor-map increment in the SLAM
|
||||
map frame. Missing republication is not free-space evidence.
|
||||
|
||||
Therefore every candidate run must preserve three distinct products:
|
||||
|
||||
1. exact current registered increment;
|
||||
2. bounded causal rolling support/occupancy in the map frame;
|
||||
3. candidate ground/non-ground/costmap output with source lineage.
|
||||
|
||||
For Candidate A, the evaluation adapter may present a bounded causal local
|
||||
cloud in the current body frame. It may not use future frames, clear cells from
|
||||
missing points, or relabel unobserved space as free. Dynamic-object semantics
|
||||
remain outside this static replay adapter.
|
||||
|
||||
## Operator-reviewed regression set
|
||||
|
||||
The following RAVNOVES00 source frames are mandatory review anchors. They are
|
||||
operator-reviewed engineering cases, not independent statistical ground truth.
|
||||
|
||||
| Frame | Required observation |
|
||||
| ---: | --- |
|
||||
| 171 | The grass/curb region must not become a large blocking object; the visible bin must remain obstacle evidence when supported by LiDAR. |
|
||||
| 306 | The cart and right hemisphere must not be lost while curb corners become dominant. |
|
||||
| 368 | The hemisphere extent must stay compact; the right railing must remain obstacle evidence. |
|
||||
| 402 | The near hemisphere must not inflate into a camera-sized rectangular exclusion zone. |
|
||||
| 450 | Curb/ramp terrain must be evaluated relative to local ground instead of becoming arbitrary boxes. |
|
||||
| 509 | Isolated vegetation or sparse returns must not immediately become a stable blocking object. |
|
||||
| 525 | Sparse local returns must not merge into one large occupied camera rectangle. |
|
||||
| 744 | The grass/curb strip must not be promoted into a wall. |
|
||||
| 1122 | The compact hemisphere and both thin posts must be represented when LiDAR support is present. |
|
||||
| 1856 | Two posts remain separate, two hemispheres remain separate, and the passages between them remain explicit. |
|
||||
|
||||
## Acceptance contract
|
||||
|
||||
### Quality
|
||||
|
||||
- Static obstacle output is class-free and geometry-backed.
|
||||
- All supported critical anchors above are occupied or conservatively unknown,
|
||||
never false-free.
|
||||
- Vegetation, curb edges and isolated returns do not create large persistent
|
||||
lethal regions without sustained non-ground evidence.
|
||||
- Separate posts and hemispheres remain separate at the costmap resolution.
|
||||
- A camera rectangle cannot merge two distinct occupied regions or erase their
|
||||
gap.
|
||||
- Unobserved support, drop-offs and no-return regions remain `UNKNOWN/LETHAL`
|
||||
until positive support is observed.
|
||||
- No manual object-class annotation or detector training is permitted for this
|
||||
gate.
|
||||
|
||||
### Realtime and resource envelope
|
||||
|
||||
- Process all `4,489` timeline frames with zero unaccounted loss.
|
||||
- Isolated candidate output keeps up with at least the recorded `10 Hz` source
|
||||
cadence.
|
||||
- Integrated graph FPS regression is at most `5%` relative to the immutable
|
||||
M4.8R3 `11.79902 FPS` reference.
|
||||
- Candidate-stage p95 latency is at most `25 ms` and p99 at most `50 ms` in the
|
||||
recorded replay contour.
|
||||
- The primary CPU candidate does not add another neural model or consume the
|
||||
RF-DETR GPU budget.
|
||||
- CPU, RAM, GPU, VRAM, queue depth, supersession and output age are recorded;
|
||||
no result is accepted only because it looks good in selected frames.
|
||||
|
||||
### Authority
|
||||
|
||||
Passing this document's tests accepts a recorded-replay perception provider.
|
||||
It does not accept physical free space, navigation, commands, actuation,
|
||||
collision safety or a robot body model.
|
||||
|
||||
## Sequential execution plan
|
||||
|
||||
### T0 — Worker and source preflight
|
||||
|
||||
- Inventory Worker 006 OS/WSL, ROS 2, Docker, compiler, CPU/RAM and RTX 4090.
|
||||
- Confirm the immutable RAVNOVES00 source and accepted M4.8R3 result locally on
|
||||
the worker without copying private source evidence back to the Mac.
|
||||
- Record a content-addressed candidate manifest and exact upstream revisions.
|
||||
|
||||
The first T0 snapshot is recorded in
|
||||
[`experiments/perception/M49_T0_TRAVERSABILITY_PREFLIGHT_2026-08-26.md`](../experiments/perception/M49_T0_TRAVERSABILITY_PREFLIGHT_2026-08-26.md).
|
||||
Exact upstream revisions are frozen in
|
||||
[`config/perception/m49-traversability-candidate-manifest-v1.json`](../config/perception/m49-traversability-candidate-manifest-v1.json).
|
||||
T0 found the source and the accepted raw M4.8R3 run intact, but did not start a
|
||||
build: the parallel GAUSS contour was active and free Worker memory had fallen
|
||||
to approximately `669 MiB`. That is a resource-admission stop, not a candidate
|
||||
failure.
|
||||
|
||||
### T1 — Candidate A isolated qualification
|
||||
|
||||
- Build GSeg3D and Ground Consistency in a new isolated `ndc-` worker contour.
|
||||
- Run upstream sample/demo data first to prove the unmodified components.
|
||||
- Measure component latency and memory before adding Mission Core adapters.
|
||||
|
||||
### T2 — Candidate A RAVNOVES00 replay
|
||||
|
||||
- Feed the bounded causal local cloud with exact pose lineage.
|
||||
- Produce ground, non-ground, occupancy and unknown layers for all frames.
|
||||
- Review the ten mandatory anchors and compute full-run stability/resource
|
||||
metrics.
|
||||
- Do not draw system camera boxes until the costmap result is sealed.
|
||||
|
||||
### T3 — Candidate B challenger
|
||||
|
||||
- Run TRAVEL against the identical source representation and anchors.
|
||||
- Compare compact-obstacle recall, passage preservation, temporal stability and
|
||||
CPU cost against Candidate A.
|
||||
- Stop if Candidate A already passes and TRAVEL adds no measurable value that
|
||||
justifies GPL runtime implications.
|
||||
|
||||
### T4 — Candidate C occupancy/ESDF probe
|
||||
|
||||
- Run nvblox separately with RF-DETR disabled for the isolated probe.
|
||||
- Measure GPU/VRAM and 3D occupied-space quality.
|
||||
- Admit it only if it supplies a measured capability missing from the accepted
|
||||
CPU terrain contour inside the one-RTX-4090 production ceiling.
|
||||
|
||||
### T5 — Product integration gate
|
||||
|
||||
- Select one terrain provider and at most one justified occupancy complement.
|
||||
- Re-enable the frozen RF-DETR semantic-risk provider.
|
||||
- Repeat complete recorded-source-paced load acceptance.
|
||||
- Publish a LAB only after the costmap/elevation outputs and limitations are
|
||||
sealed.
|
||||
|
||||
## Immediate next action
|
||||
|
||||
Resume T1 for Candidate A only after the Worker resource gate in the T0 report
|
||||
passes. No LOW-STEP tuning, new object model, camera resize, fisheye
|
||||
rectification, manual dataset or parallel heavy Worker job is authorized by
|
||||
this decision.
|
||||
Reference in New Issue
Block a user