Methods: how every number in the viewer is computedالمنهجية: كيف يُحسب كل رقم في العارض

Summary. The certificate's minimum separation is computed by sirb/verify.py with exact polynomial root finding, never by sampling time. It is a property of the planned polynomial paths as written, with drones treated as points.

For each pair of drones, time is split at every segment breakpoint. A drone is held at its start position before its first segment and at its final position after its last, so it keeps occupying space. On each sub-interval the squared centre distance is a scalar polynomial. Its minimum is at an interval endpoint or at a real root of its derivative. Roots come from companion-matrix eigenvalues (the algorithm behind numpy.roots), are polished with two Newton steps, and every candidate is evaluated directly as the distance (not via a square root of the polynomial, which loses precision near zero). A coarse safety grid is added to the candidates; extra candidates can only lower a reported minimum toward the true value.

The verifier shares only the trajectory data classes with the planner, so it is an independent check of the planner's output. Accuracy is about 1e-9 m for well-scaled data (docs/VERIFIER.md), but monomial-basis root finding degrades for badly scaled polynomials, and this is not interval-arithmetic proof.

Search radius. By default 4 x d_min. Pairs whose minimum is below the radius are reported exactly. If no pair is, the reported value is the radius and is flagged as a lower bound (min_separation_is_lower_bound). The radius is clamped to at least 1.01 d_min + 1e-3 so violations cannot hide.

Verdict. PASS means no structural, dynamic, geometric or separation violation beyond the tolerance policy: a limit is violated only if exceeded by more than tol * (1 + |limit|) with tol = 1e-6. Separation is violated if the minimum is below d_min - tol*(1 + d_min).

Margin over d_min in the verification record panel is the exact minimum separation minus d_min.

Summary. n_segments is the total number of polynomial segments in the fleet. n_pairs_checked is the number of drone pairs that survived the prefilter and were solved exactly.

Each piece gets an exact axis-aligned bounding box (per-coordinate extrema from derivative roots). Pieces are sorted by start time; only time-overlapping pieces of other drones are compared, and a pair is kept only if the box-to-box distance is at most the search radius. That distance is a lower bound on the true distance, so the filter discards only pairs that provably cannot come closer than the radius. Survivors are solved in vectorised batches and reduced to one minimum per drone pair.

Summary. min_separation_m in the show file is the declared required centre-to-centre separation. In the bundled shows its source is labelled assumption (see the sources field of the limits, and docs/RESEARCH.md / docs/SHOW_SCHEMA.md). Changing it changes the verdict; it is not derived from a regulation.

The viewer's separation colour mode compares nearest-neighbour distance to this value: red below d_min, amber below 1.25 d_min, green otherwise. The 1.25 factor is a display choice, not a safety margin.

The crowd line, buffer and geofence drawn in the 3D views come from the same limits (crowd.y, crowd.min_distance_m, geofence); the crowd region is y <= crowd.y and the buffer line is drawn at crowd.y + min_distance_m. Their sources are also listed as assumption or cited guidance in the certificate.

Summary. For each segment the extrema of |v_h|^2, v_z (max and min), |a|^2, |j|^2 and the coordinates x, y, z are found from derivative roots, not sampled. The table shows the maximum reached over the show and the limit from the show file. Geofence and crowd rows are margins (distance to the limit; larger is safer).

Structural checks cover time contiguity (1e-9 s), position continuity (1e-4 m), velocity continuity (1e-3 m/s), acceleration continuity (1e-3 m/s^2; a step would mean unbounded jerk) and finite coefficients. Limits marked assumption in the certificate are not datasheet values.

Summary. fleet_sha256 is the SHA-256 digest returned by Fleet.content_hash() over the trajectory data. The certificate records it so that a verdict can be tied to exactly the paths that were checked. It identifies content; it is not a signature, carries no timestamp and says nothing about who produced the file. The viewer shows the first and last 8 hex characters; the full value is available under "Show full hash" and via the copy button.

Summary. recomputation_ok is the boolean returned by verify_certificate(cert, fleet) in scripts/build_viewer_data.py when the data bundle was generated. That function checks the tool name and certificate version, the fleet hash and drone count, then re-runs verify with the recorded search radius and tolerance and compares the verdict, the numeric results (relative tolerance 1e-9), the violation counts and the lower-bound flag.

It is a recomputation by the same verifier code on the same fleet, so it detects tampering and non-reproducibility, not a bug shared by the verifier itself. The browser does not re-run it.

Summary. The lists in the verification record panel are quoted from sirb/certificate.py (GUARANTEES, NOT_GUARANTEED) and stored in each certificate.json. The guarantees hold only under the declared model. The non-guarantees include real aircraft tracking, wind, GNSS error, aerodynamic interaction, vehicle size and battery behaviour, failures and contingencies, and any regulatory, airworthiness or operational approval property.

The certificate statement is: "simulation-validated only; not flight-certified; no regulatory compliance claim".

Summary. scripts/build_viewer_data.py samples each trajectory every dt = 0.2 s, stores positions as int16 centimetres and, for every frame and drone, the distance to the nearest other drone (scipy.spatial.cKDTree) as uint16 centimetres. The viewer interpolates linearly between frames for positions and for these distances.

• Min nearest-neighbour distance now is the minimum over drones of the interpolated value at the current time.
• So far is the running minimum over frames up to the current time (and the current interpolated value).
• Drones below d_min counts drones whose interpolated nearest-neighbour distance is below d_min.

Sampling can miss a closest approach that happens between two frames (two drones closing at 10 m/s each cover 4 m in 0.2 s), and positions are rounded to 1 cm. For the nominal plan the exact verifier number is authoritative: for example the sampled minimum of the 100-drone show is 2.19 m versus the exact 2.1886 m. For stressed scenarios the stored minimum is also a sampled value from the realised paths.

Summary. Each stressed scenario takes the nominal plan, which passed the specified separation check, sampled at 0.2 s as a reference and flies it through a simulated tracking loop with disturbances (sirb/disturbance.py, sirb/stress.py, sirb/contingency.py). Every parameter is either cited in docs/RESEARCH.md or labelled ASSUMPTION. No real flight data is used.

Wind

Mean wind at 20 ft (w20) with a 1/7 power-law altitude profile (ASSUMPTION). Turbulence intensity from the Dryden low-altitude relations of MIL-HDBK-1797 as implemented in MathWorks documentation: sigma_w = 0.1 W20, sigma_u = sigma_v = sigma_w / (0.177 + 0.000823 h_ft)^0.4. Those relations were built for piloted aircraft; applying them to a small multirotor is an ASSUMPTION. Spatial structure by frozen turbulence: every drone sees the same first-order Gauss-Markov process delayed by its position along the wind, plus an independent local component (fraction 0.3, ASSUMPTION), so differential wind between neighbours is physical rather than imposed.

GNSS error

Per-drone position-estimate error: white noise (RTK-fixed level, ASSUMPTION informed by a u-blox ZED-F9P datasheet figure) plus, for a configured share of drones, a first-order Gauss-Markov bias with sigma gnss_bias_sigma and a 30 s time constant (ASSUMPTIONS informed by forum-reported float errors). Optional dropout windows random-walk the error (dead reckoning, ASSUMPTION). Differential per-drone errors are what matter for separation.

What the minimum in a scenario means. After realising the paths, the closest approach over the show is computed on the realised, sampled paths. The viewer's scenario minimum is the stored sampled value (see above). Comparing it with d_min tells you what this one simulated run did under these assumed models; it is not a probability and not a guarantee.

Summary. Each drone's error eps = x - r obeys eps'' = -kd eps' - kp eps - kp e(t) + a_wind(t) with kp = omega_n^2, kd = 2 zeta omega_n (omega_n = 2 rad/s, zeta = 0.9, ASSUMPTIONS), where e(t) is the GNSS estimation error (the controller acts on the estimated position) and a_wind = drag_gain x wind velocity (drag_gain 0.3 1/s, ASSUMPTION). It is discretised exactly with a zero-order hold. The number shown is the largest absolute value of eps over all drones, axes and frames, stored as max_tracking_error_m.

Summary. Discrete events are drawn at uniform random times in [0.15 T, 0.85 T] for randomly chosen drones (no drone gets two events). Event counts for comms loss and low battery are binomial draws from the scenario's fraction. Each event is replaced from its step onward by a behaviour (sirb/contingency.py):

• continue: the pre-programmed path keeps playing.
• hold: hover at the event position for hold_s (10 s), then descend vertically.
• descend: descend vertically in place at 2 m/s (ASSUMPTION).
• ballistic (motor failure only): uncontrolled fall, see below.

The bundled scenarios use motor failure with ballistic fall, and comms loss with hold-then-descend. The diamonds in the 3D view switch on at the event time; the "failure events triggered" readout counts events whose time has passed. The behaviour table in the scenario panel shows the configured mapping from event kind to behaviour.

Summary. After a motor failure the drone leaves its commanded path and falls under gravity with horizontal velocity decaying at air_drag_per_s = 0.5 1/s (ASSUMPTION), handled by sirb/stress.py. The model ignores tumbling, aerodynamics of the airframe and debris. The ids listed in the scenario panel are the drones that fell this way. Whether a falling drone passes close to another is part of the scenario minimum; what it would do to people or property on the ground is not modelled.

Summary. The parameter list in the scenario panel is the exact override set passed to StressConfig in scripts/build_viewer_data.py; all other parameters keep the defaults in sirb/disturbance.py. They are chosen stress levels, not measurements of any site. Wind is in m/s at 20 ft; fractions are shares of the fleet; gnss_bias_sigma is metres per axis.

Summary. The viewer shows one realisation per scenario, generated with seed 20261011 (plus a small per-scenario offset, as in build_viewer_data.py), so the bundle is reproducible. The stress module can run many trials (Monte-Carlo with Wilson confidence intervals for violation rates) but the viewer does not display those statistics. A single run may be milder or harsher than typical.

Summary. Nothing here has been validated against flight data. Known gaps:

• Drones are points in the verifier; the 0.24 m vehicle radius is only used for a contact flag in the stress code. The viewer draws drones larger (0.9 m) for visibility.
• The tracking loop is a generic second-order model, not a real autopilot. Command latency and an acceleration cap exist as opt in options (docs/MODEL_FIDELITY.md) but are off in the scenarios shown here; estimator behaviour is not modelled.
• Wind uses aircraft-derived turbulence spectra, a power-law profile and a simple drag gain; no gusts at the scale of a real site, no terrain or building wakes, no downwash between close neighbours.
• GNSS error is a simple bias plus noise; jamming and spoofing are not simulated in these scenarios.
• Failure behaviour is simplified; battery, link and failsafe logic of a real fleet differ by vendor.
• Limits such as d_min, geofence and accelerations are assumptions or cited guidance, not approved operating conditions.
• Stressed scenarios evaluate distances between drones only. Geofence containment, distance to the crowd, ground impact of falling drones, battery endurance and launch/landing are not evaluated under disturbance, and the "corridor" behaviour can leave the geofence.
• No regulatory property is claimed or implied. A real show needs an operator safety case and approvals from the relevant UAE aviation authorities.

Summary. data/index.json lists shows and scenarios. <scenario>.bin is little-endian int16 of shape (frames, n, 3) in centimetres; <scenario>.nn.bin is uint16 of shape (frames, n) in centimetres. Frame: x east, y north, z up, local origin, metres (docs/SHOW_SCHEMA.md). Values are clipped to +-327.67 m by the int16 range, which covers the geofence and crowd line of the bundled shows. The 3D scene maps (x, y, z) to (x, z, -y).