v0.5.0: flight in degraded visual conditions, lit by the vehicle's own light

Flight in degraded visual conditions: the location has no light of its own,
the vehicle carries the only one, and that light flickers, fails, runs out of
charge or goes out for good. The vehicle judges its light by what its own
camera sees, flies home when the light is unreliable or the charge no longer
covers the way back, and when it is blind for good it descends level on the
IMU and lands. Darkness the camera looked into is a measured prohibition,
told apart from a surface. Every flight is recorded whole in real time with an
RViz overlay of what the vehicle knows and decides. Validated on Urban Circuit
Practice 01 (environment-assets-urban-v1) on the stereo set without GNSS, no
static map, no lidar: five point-to-point flights on 5dd839b, every one
complete and collision-free with no failing line, 1.58 to 1.77 m/s with the
true position 0.79 to 1.79 m from the goal at its acknowledgement (r1205 to
r1210). Roadmap items 17, 19 and 20 close with it.

Recordings of this release, the whole flight uncut in real time, the world on
the left and RViz on the right:

• Point-to-point through the dark building, 420 m:
  https://youtu.be/WlpePGmt19A

• The light lost mid-flight, dead reckoning, blind descent, landing:
  https://youtu.be/ED4aYhnpKRs

• The light failing, judged unreliable, the way home:
  https://youtu.be/PhPgzjhcdpQ

• A 240 s light battery, the turn home in time:
  https://youtu.be/QMme-iyhJrc

• Roadmap item 17: flight in degraded visual conditions
  (docs/scenarios.md, docs/camera_perception.md).
  The location's light is off for good; the vehicle's carried light is the
  evaluation's, with three profiles: moderate (the norm of every flight: short
  dimming every few seconds, dark never longer than 2 s), severe (outages
  growing to 4.5 s every 8 s) and lost (gone from the forty-fifth second),
  and an optional charge in seconds. The camera stream's own failures (frames
  lost, frames late) are injected the same way. What the stack does with it:

  • The braking contract reads the forward frame's light and its observed
    share: a frame the contract reads as blind holds the vehicle where it
    stood (specification K9, K15), and the carried light is judged unreliable
    after one outage of 3.5 s or 60 percent of dark in two minutes (K12),
    which gives the goal up for the start.
  • Dead reckoning (K13): past its 1 s unaided timeout the visual-inertial
    estimator keeps a sound pose for 10 s more, declared as such, its height
    held to the barometer's change and its horizontal velocity bounded by the
    rotors' drag; then it falls silent and the autopilot's own failsafe acts.
    A reading across the rotor axis beyond any flight's drag is left out: a
    body landed on a slope reads the ground's friction there, which the model
    took for 21 m/s (r1194).
  • Darkness is not unknown (K14): a blind frame held for 2.5 s marks the
    frustum it looked into as observed unobservable, a prohibition as a
    surface is, cleared when seen through again; a blind frame's stereo
    returns never reach the memory; the memory tells an occupancy no measured
    return has hit from a surface and RViz draws it grey.
  • The blind landing (K19): three seconds into dead reckoning the offboard
    descends the vehicle level at 0.5 m/s in the autopilot's velocity mode and
    lands it; an estimator that sees again first takes the flight back.
  • The battery (K11): the goal is given up for the start when the charge
    left falls below 1.1 times the way home's estimate, one and a half times
    the path flown over the mean speed with a 20 s reserve; a flight launched
    without a battery never gives its goal up for it.
  • The crash judge (A9): every contact is a crash, the one exception a level,
    slow landing of the body on a floor while the offboard's blind descent
    goes on; a floor touched in flight is a crash (r1184).
  • The memory never forgets by time (K10, the owner's decision); the sensor
    mount is repaired, the memory no longer a false layer 0.24 m above the
    truth (K22).

• Roadmap item 19: a goal proven unreachable sends the vehicle home. The
  mission monitor floods the obstacle memory from the vehicle every 10 s
  (goal_reachability_proof_3d) and, on a closed component, replaces the goal
  with the start through the objective channel; the arrival at the start is a
  goal's arrival like any other. Implemented and held by unit tests; the proof
  has not fired in a flight yet (every return flown was the light's or the
  battery's), which roadmap item 24 closes with item 18's blocking scenario.
  The visual-inertial estimator relocalizes on its own map, 0.2 to 0.7 m at
  the return.

• Roadmap item 20: the simulation slowed and the flight recorded with nobody
  at the desk. Every onboard timer runs on the node clock (K24);
  REAL_TIME_FACTOR is a parameter of the run, 1.0 unless set, never above
  (K25); the host's verdict counts a flight only when the simulator held the
  factor it asked for and the estimator's pose age stayed under 300 ms (A7).
  tools/record_flight.sh records a flight at 0.6 through a GL capture shim:
  the whole flight, every frame re-timed to its moment on the simulation
  clock (no frame further than 0.5 s from it, A11), the windows below the
  others and minimized by themselves; tools/fly_until_valid.sh and
  tools/record_until_pass.sh fly again under the host's load.

• The RViz evaluation overlay (K26, docs/rviz.md): the
  mission's events on a topic, and over the view what the vehicle decided,
  LIGHT (what the harness set) beside SEES (the share of its range the
  vehicle's own frame grants), CHARGE, and the estimate's trail (white)
  against the truth's (green). The evaluation reads the stack; nothing of the
  stack reads the evaluation.

• The clearance law carries the estimate's vertical error (K27): the body's
  clearance is measured where the estimate puts it and 0.5 m lower and
  higher, so a motion the estimate holds 0.3 m above a floor stops before
  it. The camera estimator's height runs 0.3 to 0.6 m from the truth with or
  without dead reckoning. The cost: the acceptance's mean speed 1.70 m/s
  against 1.90 before it.

• The offboard node is split into a header and three sources; its mode stream
  goes on through a planner-loss hold (without it the autopilot left offboard
  before the hold's landing).

• Set aside by the owner (A8): the long flight to B and back, and the
  goal-outside flight until item 19's proof is flown. The lidar is not
  recorded (its picture is black). The cooperative mission waits for item 15.

• Known risk, kept by the owner's decision
  (docs/technical_debt.md): the blind landing holds
  no horizontal position and lands where the vehicle drifted to; of twelve
  blind landings in the dark, nine stood, one met a ledge with a rotor
  (r1181) and two tipped on uneven ground four seconds after a level touchdown
  (r1192, r1193).

• Validated with environment-assets-urban-v1 on 5dd839b (the release's
  stack; aaf105c adds the evaluation's fixes and the documentation).

v0.4.0: flight without a map, GNSS, magnetometer or lidar

Flight with no map, no GNSS, no magnetometer and no lidar: the vehicle
navigates a multi-level 3D building on a forward stereo pair and two
time-of-flight sensors, and a visual-inertial estimator on that same pair is
its position and heading. Both are the defaults of every single-vehicle
flight; the 3D lidar and its estimator stay available on request. The release
also carries the goal-in-truth requirement in the mission check, the camera
simulation holding real time, and the removal of the interception missions and
the airborne radar. Validated on Urban Circuit Practice 01
(environment-assets-urban-v1) with no static map, on 7e95336: r579 to r583
on the stereo set without GNSS and r584 to r588 on the 3D lidar without GNSS,
ten flights of ten complete and collision-free with no failing line. Roadmap
items 9, 14 and 16 close with it.

• Roadmap item 16: flight without GNSS, without the magnetometer and without
  the lidar. A visual-inertial estimator on the forward stereo pair (a stereo
  multi-state constraint Kalman filter on Eigen alone with first-estimate
  Jacobians, visual_inertial_odometry.hpp; a Lucas-Kanade feature tracker
  with the gyroscope's prediction; visual_inertial_odometry_node inside the
  process that owns the pair's images) replaces them as the autopilot's
  external odometry. LOCALIZATION_PROFILE=visual_inertial is the default
  wherever the stereo sensor set is the default; the lidar keeps
  lidar_inertial, gnss is a request, and the multi-vehicle launches stay on
  gnss until the vehicles share a frame (item 15). visual_inertial_shadow
  runs the estimator beside GNSS for comparison. See
  docs/localization.md. Accepted on 7e95336 by two
  series of five flights, none with a crash or a failing line: the stereo set
  without GNSS on the defaults at 1.48 to 1.79 m/s with the true position 0.47
  to 1.42 m from the goal at its acknowledgement (r579 to r583), and the 3D
  lidar without GNSS at 2.42 to 2.67 m/s (r584 to r588). This closes roadmap
  items 16 and 9; 7e95336 is the release candidate.
• The mission check fails a flight whose goal was not reached in truth: at
  every goal acknowledgement the true position must be inside the 2.0 m
  capture radius. The estimator's health and its error against the true pose
  are notes.
• The simulated autopilot stamps on the simulation clock (UXRCE_DDS_SYNCT 0,
  px4_clock_is_ros_clock), the pair's images are taken from Gazebo inside
  the matcher's process (gazebo_stereo_depth_node), and the GPU is polled
  every ten seconds: a camera flight holds a real-time factor of 0.93 to 0.97
  and the autopilot no longer reacquires its timestamps (17 to 0 per flight).
• Fixed: a planning tick could last 2.5 s beside a wall the envelope touches
  (the latest scan's returns, a centimetre apart, each walked against the
  departure at every body position); the scan is thinned to the nearest return
  per 0.05 m cell. Every planning tick that ends without a horizon now names
  its reason. Also fixed on the camera profile: a steep motion judged with the
  forward sensor's margin, a memory revision published under two stamps,
  low-speed refusals of the unseen-motion rule, and a heading frozen while an
  arrival rests the vehicle.
• Roadmap item 15 stage 0: the interception missions, the airborne radar and
  the grid-city world they flew in are removed from the repository. Gone are
  the radar simulators, trackers, interceptor guidance, target assignment, the
  interception referee and its truth boundary, the non-cooperative avoidance
  pipeline and its controller parameters, the grid-city world specification
  with its generated SDF, occupancy, ESDF and topology artifacts, the world
  generator, the interception and grid-city scenarios, and their make targets,
  wrapper scripts, messages, tests and documentation. The shared multi-vehicle
  infrastructure that the cooperative mission uses is kept under neutral names
  (multi_vehicle_scenario.py, multi_vehicle_spectator_node,
  multi_vehicle_diagnostics_mux_node, multi_vehicle_truth_launch.py), and
  VehicleDestroyed keeps only the civilian role and the two physical death
  causes. What remains is the imported Urban Circuit Practice 01 environment
  with its point-to-point and cooperative traffic missions. The Completed
  roadmap entries 1 to 5 and 6.1 stay as history, each marked as removed.
  Confirmed by five urban point-to-point flights of five on one commit (r448
  to r452, lidar-inertial profile, 2.58 to 2.94 m/s, no crash); the
  cooperative mission is not flight-verified after the removal.
• Fixes the confirming series needed: the four general tick diagnostics lost
  with the interception ones are restored; the autopilot's estimator sources
  are set before EKF2 starts, so it no longer fuses GNSS height for its first
  90 ms and resets the height by 7.84 m at takeoff (r439); a refused stop
  leaves the vehicle on its still valid resident trajectory when the braking
  path itself is blocked, instead of a blind straight brake into the wall
  (r440, r445); the lidar-inertial submap evicts its oldest keyframe without
  rebuilding the voxel hash, so a scan's cost no longer grows with the submap
  (r447: 155 to 266 ms a scan, external-vision fusion lost, crash; r448 to
  r452: at most 99 ms at 82 to 92 thousand points).
• The speed policy's stopping laws answer for the vehicle as it flies. The
  limits that depend on a distance (clearance, route clearance, blocked
  route, curvature, goal, route endpoint) are the exact jerk-limited slowdown
  from the measured forward acceleration, and the evidence-facing ones also
  charge the measured delay of the loop behind a falling reference
  (reference_tracking_lag_s, 0.3 s). A law of instantaneous deceleration
  let the vehicle accelerate under a falling limit and cross it inside its
  braking distance (r320, r440): 7 to 15 crossings a flight before, 0 to 2 in
  the series r470 to r474.
• A moving vehicle is offered the certified stop before any revocation,
  whatever ended the replacement, and the stop no longer depends on the
  cycle's route-bound validation world. Certified stops flown a flight: 9 to
  21 against 0 to 2; blind brakes of the offboard above 2 m/s: 1 to 4, none
  above 3.5 m/s and nearly all taken over by a certified stop within 0.8 s,
  against 3 to 11 up to 5.9 m/s. What remains is the stop refused for the
  clearance of its rest pose.
• The lidar-inertial estimator reads the scan to the sensor's whole 35 m, so a
  street longer than 30 m no longer leaves the registration without a
  measurement along it (r461: a 2.0 m slide of the estimate).
• Roadmap item 14, stages 1 and 2: CAMERA_PROFILE=stereo_tof mounts a
  forward stereo pair (1280 x 960, 120 degrees, 0.20 m baseline) and two 8 x 8
  time-of-flight sensors beside the lidar; stereo_depth_node recovers depth
  by semi-global matching and publishes it, with the time-of-flight zones, as
  rays that are hits, free rays or nothing; a second obstacle memory
  integrates them in shadow. Against the lidar memory its occupied voxels
  agree to 97 to 98 percent within one voxel and it finds 96 to 99 percent of
  the lidar's inside the third of the volume it observes. Camera flights run
  on the textured GUI world, at 7.5 Hz, on the gnss localization profile.
  The roadmap's speed estimates for the camera profile are corrected by the
  braking contract (6.4 m of confident depth admit 2.5 to 3.0 m/s).
• At the mission goal a moving vehicle is left to the goal hold instead of
  being offered a stop every second, which kept the mission from being
  acknowledged on the GNSS profile (r481).
• Roadmap item 14, stages 3 and 4, and its closure: the vehicle navigates on
  the stereo pair and the two time-of-flight sensors alone, with the lidar
  absent from its model, and that sensor set is now the default everywhere
  (CAMERA_PROFILE=stereo_tof, NAVIGATION_SENSOR_PROFILE=stereo_tof; the
  lidar profile is CAMERA_PROFILE=none NAVIGATION_SENSOR_PROFILE=lidar). The
  braking contract reads the range of the sensor whose field holds the motion
  (6.4 m forward inside 60 by 52.4 degrees, 2.8 m inside 22.5 degrees of the
  vertical), a gaze policy turns the heading to the motion, and a motion the
  vehicle does not face answers to what memory has observed along it. The
  launch's one obstacle memory is the vision memory; the raw world, the
  planner and the execution core are unchanged. Single-vehicle flights on the
  stereo profile use the gnss localization profile until roadmap item 16
  adds visual-inertial odometry. Accepted on one commit: five flights with
  the lidar absent (r506 to r510: mission complete, no crash, 1.48 to
  1.67 m/s against a 1.226 m/s gate, route availability 97.6 to 98.8
  percent, planner p95 152 to 158 ms) and five control flights of the lidar
  profile (r511 to r515: 2.65 to 2.82 m/s). The final series on the defaults,
  with no profile variable set and the horizon rule below in place (r523 to
  r527 on cd461d0): five of five, no crash, 1.17 to 1.57 m/s with one flight
  under the gate, route availability 98.2 to 99.2 percent. The multi-vehicle
  launch carries the same defaults and has not been flown on them.
• A published horizon may not carry speed along a motion its own planned
  heading leaves unseen, faster than memory admits along it
  (firstUnseenMotionState3D in the horizon assembler's candidate validator;
  the arrival search shortens a refused candidate to rest before that motion).
  r518: the simulator fell behind the wall clock, the autopilot's timestamps
  were reacquired and no horizon could be committed for 1.7 s; the resident
  horizon flew the route's turn at 2 m/s with the pair still facing away, into
  a structure memory first held 0.67 s before the contact. Camera flights see
  10 to 15 such reacquisitions each, lidar flights none or one. The rule costs
  about a fifth of the stereo profil...

v0.3.0: navigation without GNSS and magnetometer

Navigation without GNSS and without a magnetometer: a lidar-inertial
estimator is the vehicle's position and heading, fed to the autopilot as
external odometry, and it is the default of every single-vehicle flight.
The release also carries the resource and transport budgets of roadmap item
10, the withdrawal of the wrong static maps, the braking contract along the
direction of motion and the fixes listed below. Validated on Urban Circuit
Practice 01 (environment-assets-urban-v1) with the 3D lidar and no static
map, r430 to r434 on the lidar-inertial profile and r352 to r356 on GNSS.

• Roadmap item 13: the stack flies without GNSS, the magnetometer or the
  simulation heading source, and every single-vehicle flight now does so by
  default. LOCALIZATION_PROFILE=lidar_inertial runs a lidar-inertial
  estimator (IMU integration, point-to-plane registration against a sliding
  keyframe submap, a Kalman step with degenerate-axis and innovation gating)
  that feeds the autopilot's external-odometry interface; gnss restores
  the simulated GNSS and heading source, which the multi-vehicle missions
  still fly, and gnss_shadow runs the estimator beside GNSS for comparison.
  The mission check proves the profile from the autopilot and ROS logs,
  reports the estimator's health and fails a flight that left the autopilot
  without an estimate. Measured at the r430 to r434 series: no crash, 2.57
  to 2.97 m/s, the autopilot's estimate 0.15 to 0.22 m from the true pose
  across the track at p95 against 0.19 to 0.25 on GNSS, the estimator at 0.5
  cores and 59 MiB. Loop closure is deferred: the drift does not grow with
  the flight's length. docs/localization.md describes it.
• The static maps published for Urban Circuit Practice 01, Finals Prize Round
  World 07 and Cave Circuit Practice 01 (static_r050, static_r100) were
  checked against their worlds, found wrong, and withdrawn from the
  environment manifest; the three environments ship their source bundle only
  and fly no-static with the 3D lidar. A release environment may now carry no
  static map, and the topology compiler says so instead of asking for one.
• Every transport hop reports what its delivery took, the mission check
  reads the four hops and splits the observation age, and the obstacle
  memory transports at the scan rate, 10 Hz instead of 2. DDS delivers a
  memory update in 0.15 ms, so the age the planner sees is the publication
  period plus the memory's scan-to-publication time: 404 ms at p50 and 636
  at p95 at 2 Hz against the 600 ms the braking contract charges, 184 to
  200 and 252 to 274 at 10 Hz, for 0.3 cores of the controller and about a
  millisecond of tick. The r352 to r356 series on it flew without a crash at
  2.72 to 3.06 m/s with every dynamics, tick, resource and transport check
  green. Roadmap item 10 closes on that.
• Every flight records what its processes consume (resources.csv,
  resources_host.json), and the mission check gates the record's coverage
  and the onboard processes' memory growth and reports their cost. On r345
  the onboard processes used 2.73 cores at p50 and 3.36 at p95, 798 MiB of
  resident memory and 206 MiB of GPU memory, the GPU 42 percent of an RTX
  3060 Laptop, at a real-time factor of 1.00; the record cost the flight
  nothing the tick could measure. docs/resource_budget.md reads the figures
  and names the Jetson Orin family as the class of onboard computer they do
  not exclude, with every assumption behind that marked as one.
• The rollouts obey the braking contract along their own direction: the
  dynamics carry the contract's admitted speed at 33 vertical shares from
  level flight to a pure climb or descent, read by one lookup in the host and
  CUDA dynamics, the overspeed cost, the reference clamp and the route ETA
  model; the scalar bound is the table's largest entry. One bound for every
  direction was the contract's worst case, 4.62 m/s under the 1.4 m/s^2
  vertical law, and it held the level legs of r312 to r319 at a p90 of 4.3 to
  4.6 m/s against the 5.65 the contract admits there, about a tenth of the
  mean speed. It was flown as 4e1f3fce and withdrawn after r320, whose
  braking margin the blocked-route distance below had already made negative.
• The blocked-route speed limit measures the distance the vehicle actually
  has to the block: the smaller of the stations remaining along the route and
  the straight line to the blocked sample. A route may turn on its way to the
  block while the braking vehicle crosses the turn's chord, and in r320 the
  block sat 4.8 m along the route with the wall 2.7 m ahead, so the limiter
  admitted 4.36 m/s where the stop it then needed was 2.81 m long and the
  vehicle met the wall a second later.
• Two laws were flown and withdrawn, and what they measured is recorded here.
  A stop whose rest pose released the envelope margin along the clearance
  ladder (so that a stop refused only on that margin, as in r320, is
  published instead of leaving the vehicle without a braking owner) touched
  a wall twice in four flights: r326 at 2.56 m/s and r334 at 0.06 m/s while
  holding. Measured against the true Gazebo pose over 56 hold episodes of
  r303 to r334, a holding vehicle drifts 0.102 m at the median, 0.370 m at
  p95 and 0.394 m at most, which is more than the 0.27 m the envelope
  carries over the hull: the rest margin is not a reserve to release but a
  measured amplitude, and it is if anything too small. The directional
  rollout speed bound was restored on top of that stop and is withdrawn with
  it, since r320 showed it needs the braking owner the refused stop did not
  provide. The tree returns to the state that flew r315 to r319 without a
  crash.
• A leaned execution body (the rim grown to the tilted rim's reach) was flown
  and withdrawn: with it the vehicle never left the launch platform in r325
  (the whole flight in no_executable_route_hold, planner p95 4.1 s). The
  measurement that motivated it stands and is recorded here: over the 408
  braking episodes of r303 to r324 the airframe holds 0.303 rad of tilt at
  the median and 0.384 at p95, which puts the rim 0.078 to 0.090 m beyond the
  upright body. It is not what struck the wall in r320: the contact point
  there sits 0.465 m from the true centre, inside the 0.55 m upright body,
  and 0.28 s earlier the footprint readiness already reported
  strict_status=raw_collision with status=clear, the contact exemption
  covering a body that was still moving into the mapped wall at 1.5 m/s.
• The rollouts obey the braking contract along their own direction: the
  dynamics carry the contract's admitted speed at 33 vertical shares from
  level flight to a pure climb or descent, read by one lookup in the host and
  CUDA dynamics, the overspeed cost, the reference clamp and the route ETA
  model; the scalar bound is the table's largest entry. One bound for every
  direction was the contract's worst case, 4.62 m/s under the 1.4 m/s^2
  vertical law, and it held the level legs of r312 to r319 at a p90 of 4.3 to
  4.6 m/s against the 5.65 the contract admits there, about a tenth of the
  mean speed. Flown first as 4e1f3fce and withdrawn after r320 struck a wall
  with no braking owner; restored with that hole closed above.
• The production tick takes 22.7 ms at the median and 30.8 ms at p95
  (r314) instead of 52 to 55 and 70 to 98 ms (r303 to r313): a path
  validation builds its collision oracle once instead of once per segment,
  and the oracle's constructor scans every one of the scan's 63 700 lidar
  returns for finiteness (4b3dac94). The mission check now bounds the
  tick at 30 ms p50 and 45 ms p95 from the summary percentiles and reports
  the share of ticks over the 20 ms deadline (71 percent on r314).
• The vertical law is checked on the statistic it rests on: the
  descent-arrest check reads the plateau of each arrest episode and holds
  its median over at least three episodes to the law's 1.4 m/s^2; the
  former median over every windowed sample measured the ramps and fell to
  1.16 on r312 against its 1.2 bound while the plateaus sat at 2.0.
• The tracking-error tube law keeps its 0.075 s: the p99 exceedances of
  r288, r307 and r310 were short episodes at horizon rebuilds and 2 m
  radius turns with the position estimate 0.3 m ahead of the vehicle;
  without that lead the p99 is 0.08 to 0.18 m (r312 to r314).
• PX4's EKF2 no longer assumes a 110 ms GNSS delay in simulation
  (EKF2_GPS_DELAY 0 in the parameter stream). The Gazebo bridge stamps
  the navsat sample at receipt, and the default delay placed the position
  estimate ahead of the true pose along the motion by the speed times
  0.11 s, measured as +0.118 to +0.120 s on r308 and r311 with the
  controller-dynamics recordings, 0.35 m at 3 m/s.
• The vertical law is the fifth percentile of the arrest plateau: the
  guaranteed vertical stopping deceleration and the planned vertical
  acceleration go from 2.0 to 1.4 m/s^2. Over the 91 descent arrests
  recorded in the 25 urban flights r268 to r308 the plateau reaches
  1.41 m/s^2 in 95 percent of them and 2.19 at the median, so half of the
  arrests fell short of the former value, which was the median of five
  flights. The braking contract's worst-direction limit becomes 4.62 m/s
  (was 5.14); the level-flight limit does not move.
• Roadmap: item 12 (persistent full-3D strategic navigation) is closed on the
  v0.2.0 evidence; its unrepeated Manhattan gate, availability targets and
  cooperative/interception re-flights move to item 9, now split into stage A
  (full mission suite on the current locations) and stage B (the large city).
  Item 10 records the debt measured at closure, first of all the production
  tick at p50 55 ms against its 20 ms deadline. Completed items are summarized
  in a Completed section at the end of docs/roadmap.md with stable numbers.
• The navigation stack reads the autopilot through one contract
  (autopilot_state.hpp, ...

v0.2.1: one-command bootstrap of a fresh clone

• scripts/bootstrap.sh prepares a fresh clone with one command: host
  checks, the dev image, the PX4 checkout and its px4_sitl build inside the
  container, the workspace build and the urban environment assets, then the
  urban point-to-point simulation (--headless, --no-run). The 3D-lidar
  profile launches the PX4 binary directly, so the SITL build was a manual,
  undocumented step before. Verified on a fresh clone of v0.2.0: the
  preparation took about 25 minutes with the dev image already present, and
  the headless flight that followed completed the mission at 3.162 m/s
  (389.8 m in 123.3 s) without a crash.

v0.2.0: point-to-point 3D navigation without a static map

First tagged release of the 3D navigation stack: point-to-point flight without
a static map through a complex 3D urban location, from revisioned 3D-lidar
evidence alone. Roadmap items 1 to 8 are complete; item 12 (persistent full-3D
strategic navigation) is the substance of this release and stays in progress.

Validated scenario

make sim-urban-point-to-point-headless on the Urban Circuit Practice 01
location (environment-assets-urban-v1), no static map, 3D lidar 360 by 181
beams at 10 Hz. Five consecutive flights on commit 9ab94040 (r288 to r292),
nothing changed between them:

Flight	Path	Duration	Mean speed	Crash	Route availability	Planner p95
r288	399.9 m	137.8 s	2.901 m/s	none	95.1 %	154 ms
r289	384.6 m	148.8 s	2.584 m/s	none	93.1 %	152 ms
r290	401.5 m	134.4 s	2.986 m/s	none	92.0 %	157 ms
r291	371.5 m	123.9 s	2.998 m/s	none	91.2 %	154 ms
r292	417.2 m	134.7 s	3.097 m/s	none	88.9 %	155 ms

The mean flight speed counts every hold, stop and replan from mission
readiness to the successful result. The headless mission check requires at
least 2.5 m/s and no crash; it still requires 97 percent route availability,
which these flights do not reach (see the limitations).

Other scenarios (sim-headless Manhattan, cooperative traffic, interception)
build and pass their contract tests but were last flown before the September
navigation changes listed below; they are not part of this release's
validation.

Navigation laws in this release

• Contact is the depth the body already has in the evidence, judged voxel by
  voxel along the departure chain and never carried to another wall; one law
  for the planner and the executor, with a regression reproducing the r216
  contact deadlock (061e2532, 4bf8a4dd).
• A rest hold keeps its anchor while the vehicle still stands within the hold
  tolerance of it, and the offboard continues a lapsed stationary hold at its
  own position (d746bdb8).
• A vehicle is at rest only while it is not accelerating: the rest rearm and
  the hold certification require the measured acceleration within 1 m/s^2
  (ebadf243).
• The vertical dynamics are the descent arrest the airframe delivers, 2 m/s^2
  for both the guaranteed vertical deceleration and the planned vertical
  acceleration (a44cc7e0).
• The tracking-error tube law prices the envelope's clearance with a 0.075 s
  response horizon and a 3 m/s progress floor; the physical body's own
  clearance bounds that floor, down to 1 m/s for leaving a contact
  (d187e249, 9ab94040).
• A blocked route's replacement is taken as soon as it is raw-valid; the
  grace a worse replacement used to earn is nil (5d5dd9ea, cb45e5fb).
• A full raw snapshot recovers the transport admission from deltas that
  outran it (b116f7fe).
• The 3D lidar cloud is registered with per-source time offsets, the position
  source at -120 ms and the attitude source at 0 (a00368b2); the memory is
  no longer smeared by the vehicle's own roll and pitch.
• Braking contract: 14 m guaranteed detection range, 2 m physical margin,
  0.6 s evidence age, 4 m/s^2 horizontal and 8 m/s^2 lateral acceleration,
  12 m/s^3 jerk; the translational limit is 5.14 m/s.
• Mean flight speed is a mission-check metric (03632053), 2.5 m/s in this
  release.

Known limitations

• Route availability after bootstrap is 88 to 95 percent on the urban
  location; the 97 percent threshold of the mission check is not met. The
  remaining unavailability is replacement search after walls revealed a few
  metres ahead in unknown space, which stays traversable without penalty by
  design.
• Speed next to walls is bound by the body's own clearance: with the 0.55 m
  body model (0.16 m beyond the rotor tips) and a lateral tracking error of
  0.09 to 0.15 m at p99, the reference falls to 1 m/s where the body keeps
  less than 0.075 m.
• The position estimate is not corrected against the map: PX4's local
  position sits 0.1 to 0.3 m from the true pose, and walls are mapped in the
  estimate's frame at observation time.
• Descents are planned at 2 m/s^2 and arrested at the same; passages that
  open below the vehicle are entered more slowly than before.
• The speed profile, the lidar model and the braking contract are tuned on
  this simulation (PX4 SITL, Gazebo Harmonic, ROS 2 Jazzy). Nothing here is
  validated for real aircraft.

Compatibility

• Environment assets: environment-assets-urban-v1 (Urban Circuit Practice
  01), environment-assets-v1 (Finals Prize Round World 07, Cave Circuit
  Practice 01).
• Runtime: ROS 2 Jazzy, Gazebo Harmonic, PX4 from external/PX4-Autopilot,
  the container workflow in docker/.
• The runtime manifest of every flight (log/runs/<id>/manifest.json) records
  the package version, git describe, the commit and the effective overrides.

Environment Assets v1

Versioned external environment sources and generated Occupancy3D/ESDF3D maps for drone_city_nav. Every archive is pinned by environments/environment_manifest.yaml and SHA256SUMS. The normal Git repository contains only the compact deterministic integration fixture.

Urban Environment Assets v1

Pinned Urban Circuit Practice 01 source dependencies and the project-generated 0.5 m Occupancy3D/ESDF3D map. Archive hashes, map dimensions, per-resource licenses, and provenance are recorded in environments/environment_manifest.yaml.