Flight Review (logs.px4.io) has served the PX4 community for nearly 10 years since its first commit in October 2016. Built on Tornado/Bokeh/SQLite with an S3 FUSE mount, it processes 350k+ ULog flight logs but suffers from significant infrastructure pain: every page view re-parses the raw ULog file to regenerate all 35+ Bokeh plots, the S3 FUSE mount is fragile, the SQLite database locks under concurrent access, and the Python/Bokeh stack makes the frontend difficult to extend. This document proposes a ground-up replacement designed for performance, extensibility, and operational simplicity at any scale.
browse.py line 88-95 fetches all 353k public logs from SQLite into Python memory on every request. When there's no search term, it's fast — it only processes the paginated slice (10-25 rows). When searching, it calls get_columns_from_tuple() on every single row (string formatting, airframe lookups, datetime conversions, HTML generation), then does Python string matching. 353k iterations of expensive Python work per keystroke. The database has zero indexes.
The /dbinfo endpoint on logs.px4.io is completely non-functional. It queries SQLite for all ~353k public logs using an N+1 query pattern (one SELECT per log to join generated data), serializes ~205MB of JSON in-process, and attempts to serve it synchronously through Tornado. Every single request exceeds nginx's proxy timeout and returns a 504.
Over the 14.5 days of available nginx logs (Feb 24 – Mar 10, 2026), there were 1,679 requests to /dbinfo. Of these, 1,618 (96.4%) returned 504 gateway timeout, 41 returned 499 (client closed connection while waiting), and the remainder were 404/500/502 errors. Zero requests returned a successful 200 response. The endpoint is 100% broken.
A single IP address (122.179.88.65, using python-requests/2.32.5) accounts for 89% of all /dbinfo traffic. It polls 24/7 in a retry pattern: 5 requests at ~1 minute intervals, a 10-minute pause, then repeats. This is consistent with a client that sends a request, waits 6
| # rover: SIH Ackermann default tuning causes 56% speed overshoot and hairpin stall | |
| ## Summary | |
| The SIH Ackermann rover airframe (`10045_sihsim_rover_ackermann`) ships with default parameters that produce poor control behavior in two areas: | |
| 1. **Speed overshoot (56%):** The feedforward term `RO_MAX_THR_SPEED=3.2` commands near-full throttle (94%) for a 3.0 m/s setpoint, but the SIH plant can only sustain ~2.6 m/s at full throttle (F_thrust=400*thr vs F_drag=50*v^2). The P and I gains (0.001) are effectively zero, so there's no closed-loop correction. | |
| 2. **Hairpin heading stall:** During sharp turns, `RO_SPEED_RED` slows the rover, which reduces kinematic yaw slew rate at low speed, which prevents the rover from turning fast enough, which keeps heading error high, which keeps speed reduced. The yaw accel/decel slew limiters make this worse by artificially capping the yaw rate command. |
| Target | Autostart | Simulator | What it does |
|---|---|---|---|
jmavsim / jmavsim_iris |
10017 | jMAVSim (physics + viz) | Builds jMAVSim jar, launches PX4 + jMAVSim together |
none |
(none, uses saved params) | None | Launches bare PX4, no simulator |
none_iris |
10016 | None | Launches PX4 with Iris airframe, no simulator |
sihsim_quadx |
(env-based) | SIH | PX4 with built-in quad physics |
Source: https://dronecode.org/membership/ (comparison table, parsed from HTML icons)
| Benefit |
|---|
| Technical Steering Committee Seat (TSC) |
| Exclusive Webinar featuring your contributions to open-source |