Skip to content

OpenPAVE v1.8.3 — Cancellation-safe shutdown, and an honest re-grade

Choose a tag to compare

@odincodeshen odincodeshen released this 09 Oct 16:04
· 3 commits to main since this release

OpenPAVE v1.8.3 — Cancellation-safe shutdown, and an honest re-grade

A patch release on v1.8.2 with two small safety
fixes in run_live found by re-auditing it, plus a documentation refresh that re-grades the validation matrix
against stricter definitions
. No interface changed. (A further fix for undelivered commands followed in
v1.8.4.)

Safety fixes

  • A shutdown signal can no longer be lost. run_live now bounds its observation / inference calls with
    pave_runtime.shutdown.bounded, built on asyncio.wait, instead of asyncio.wait_for. Before Python 3.12,
    wait_for could swallow a cancellation that arrived in the same event-loop iteration in which the inner call
    finished — so SIGTERM / SIGHUP / Ctrl+C could be ignored and the loop keep running. The DGX Spark
    (Python 3.12) was not affected; Python 3.9 was, in about 40% of deliberately aligned cancels and in about 1 of
    25 runs of the existing cancellation test under CPU load.
    (shutdown.py)
  • A STOP now preempts a lease renewal that is hanging on the network instead of waiting behind it (up to the
    5 s send timeout). The preempted renewal is cancelled first, so ordering is preserved: a renewal is never
    delivered after a STOP.

The validation matrix is re-graded

The matrix called several rows "Validated" on the strength of one short run, or a run in which part of the chain
was mocked or forced — for example a TROT produced by a mock runtime rather than by a real gesture.
docs/validation-matrix.md
now defines:

  • Candidate → Experimental → Supported → Validated. Supported = the combination was run through its
    complete flow once on its real hardware. Validated additionally needs a reproducible runbook, structured
    benchmark results, recorded artifacts, documented limitations, and at least 10 runs of every declared action.
  • Evidence class hardware / software — whether a real device was in the evidence run.
Rows
Validated 1 — the software-only control-path benchmark
Supported 8 — the PuppyPi seam rows (DGX and Radxa O6 × both transports), the RPi 5 camera rows, the v1.0 baseline path, and the software-only mock_arm row
Experimental 8 — incl. the five former "Validated" rows (v1.7 headless runs, v1.8 single-shot and live loop on the real dog, gpio_servo) and the /pave console path
Candidate 5 — Jetson Thor and the other Arm-node rows (nothing documented in this repository), SO-101, Raspberry Pi car

Nothing is Validated on real hardware yet. A re-grade table in the matrix records, per row, what changed and
what it still needs; the common gap is ≥10 runs per action, structured results, and a benchmark.

Documentation brought up to date

openpave-platform-spec, further-work, latency-model (the inference segment, ~1.0–1.2 s per frame, had been
measured but was listed as not measured), demo-catalog, physical-ai-validation-workflow, and both READMEs —
including every place that still called a now-Experimental run "validated" or listed Jetson Thor as validated.
Adds the release note for v1.8.2 (its tag was published without one). Older release notes (v1.7.0–v1.8.1)
use "validated" in the earlier, looser sense; the matrix holds the current grading.

Verification

  • 200 unit tests (193 in v1.8.2) from a clean checkout of the tag on Python 3.9 and 3.12 (DGX Spark). Both
    fixes are mutation-checked — reverting each turns its test red (bounded() replaced by wait_for loses 34
    of 84 aligned cancels; without preemption a STOP waits 2.3 s behind a 3 s hanging renewal). The test that exposed
    the first problem failed once in 25 runs under CPU load before the fix and 0 of 60 after.
  • The touched documents were audited against the code: links resolve, the CLI flags and environment variables they
    name exist, the stated defaults match, and the matrix table is internally consistent.

Not verified: a physical actuator or the real dog; device_connect's serve() wiring against a live runtime.

Compatibility

No interface changes. run_live behaves the same except in the two situations above.

Full notes ·
compare v1.8.2…v1.8.3