Add a 2nd-order critically-damped attitude reference model whose angular-velocity output is fed forward onto the rate setpoint, removing the steady-state ramp-tracking lag of the pure-P attitude law. The model uses an exact closed-form discretisation, so it is unconditionally stable.
Parameters:
- MC_REF_W_N reference-model bandwidth [rad/s]
- MC_REF_FF feedforward gain [0..1]; 0 disables the anticipation
- MC_REF_FF_MAX per-axis feedforward saturation [deg/s]
The commanded yaw rate is always fed forward at unity (it is a setpoint, not a model prediction), so MC_REF_FF scales only the error-driven anticipation and MC_REF_FF=0 is the exact legacy pure-P law. Shipped disabled by default to avoid changing behaviour on existing platforms; enable per-airframe. Includes docs and the updated controller diagram.
* fix(docs): invert vectorized diagram SVGs in dark mode
* docs(docs): Apply fix as a class
* Add yarn lock to fix CI
---------
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Option to keep a gimbal pointing at a fixed attitude, not linked to any user input.
Roll and Yaw angle setpoints are 0, Pitch can be set in separate parameter.
* docs(hardware): rewrite board support guide around real process
The board support guide described a theoretical category-first process that
no longer matches how board support actually happens. Manufacturers were
left unsure of the concrete steps, leading to repeated email requests for
guidance.
Restructure the guide around the actual GitHub-driven flow: build your own
firmware target, reserve a board ID via a PX4-Bootloader PR, provide a
unique USB VID/PID, demonstrate flight with logs, and open the PR. Keep the
support categories as a reference section that explains support
responsibility rather than process.
Spell out that QGroundControl uses the USB VID/PID to identify hardware, and
warn that reusing another vendor's pair causes misidentification. Promote
the ArduPilot board-ID alignment note and point it at the current hwdef
location. Demote VER/REV ID to a clearly-deprecated edge case: explain the
resistor/EEPROM mechanism and its original cross-vendor baseboard/FMU intent,
note the ecosystem has deviated from it, and that Dronecode no longer offers
standards validation. Update the Discord link to chat.dronecode.org.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs(hardware): align porting guide with board support guide
The porting guide's 'Officially Supported Hardware' section restated the
board support process and contradicted the rewritten board support guide.
It also told manufacturers to ship hardware to the dev team for port
validation, a service Dronecode no longer offers.
Replace that section with a short pointer to the board support guide, which
is now the single source of truth for the support process, and keep only the
high-level support benefits and maintenance expectations. The technical
porting content (architecture, file layout, host OS config, RC UART wiring)
is unchanged.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs(hardware): make board support guide discoverable for manufacturers
The board support guide was only reachable by navigating into the hardware
integration section. A manufacturer browsing the user-facing autopilot pages,
the exact audience, had no path to it, and one of those pages still stated
the obsolete 4-month compatibility commitment.
Add 'how to get your board supported' pointers from the manufacturer-supported
and experimental autopilot pages, the flight controller index, and the
development landing page. Remove the stale 4-month rule from the
manufacturer-supported page. Strengthen the guide's opening paragraph so the
phrases manufacturers actually search appear up front.
Word the links to avoid conflating the guide (how to get a board supported)
with the 'Manufacturer Supported' category (one of several support levels).
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs(docs): Minor tweaks
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Remove broken anchor link to modules_driver.md#rc-input which does not
exist. Use inline code formatting instead.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Add hardware documentation for the VOLOLAND NarinFC-H7 flight controller
including pinouts, serial port mapping, PWM output groups, and analog
inputs. Fix version badge to v1.17 and clarify RC_IN is wired directly
to FMU via RC_INPUT driver.
Based on work by @vololand and @hamishwillee from PR #26542.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* fix(fw_mode_manager): honor DO_CHANGE_SPEED in manual airspeed modes
Re-anchor the throttle-stick airspeed interpolation on the last
MAV_CMD_DO_CHANGE_SPEED value (falling back to FW_AIRSPD_TRIM if none).
Previously, _commanded_manual_airspeed_setpoint was stored but never
read when FW_POS_STK_CONF bit 1 was set (the default), so
DO_CHANGE_SPEED had no effect in Position/Altitude.
With this change:
- Stick centered = commanded cruise speed (= FW_AIRSPD_TRIM if no command).
- Stick deflection deviates from cruise between FW_AIRSPD_MIN/MAX.
- Disconnecting the controller collapses the interpolation to the cruise
(Sticks zeroes the throttle channel on manual_control_signal_lost).
- No setpoint jump when a controller is plugged in with stick centered.
- No behavior change for users who never send DO_CHANGE_SPEED.
* fix(fw_mode_manager): clear DO_CHANGE_SPEED override on mode change
Reset _commanded_manual_airspeed_setpoint to NaN when entering a
manual airspeed mode from outside the manual airspeed pair, so a
prior MAV_CMD_DO_CHANGE_SPEED does not silently anchor the manual
airspeed setpoint after the pilot has left and re-entered manual
airspeed control. Toggling between Position and Altitude preserves
the commanded value since both modes share the same airspeed mechanic.
Also fold in a make-format whitespace fix in get_manual_airspeed_setpoint.
* docs(flight_modes_fw): document DO_CHANGE_SPEED in manual airspeed modes
Describe how MAV_CMD_DO_CHANGE_SPEED re-anchors the throttle-stick cruise
airspeed in Position and Altitude mode, matching the new behavior in the
fw_mode_manager. Covers the centered-stick anchor, deflection scaling
between FW_AIRSPD_MIN/MAX, the shared setpoint across both modes, and the
reset to trim when entering from any other mode.
Signed-off-by: Gregor Hohl <gregor.hohl@auterion.com>
* Subedit
* fix(fw_mode_manager): reset DO_CHANGE_SPEED override on any mode change
Reset _commanded_manual_airspeed_setpoint to NaN whenever the position
control mode changes, instead of only when entering manual airspeed
control from outside the Position/Altitude pair. This makes the manual
airspeed setpoint revert to FW_AIRSPD_TRIM on every mode change,
including toggling between Position and Altitude, for predictable
behavior.
Signed-off-by: Gregor Hohl <gregor.hohl@auterion.com>
* docs(flight_modes_fw): note manual airspeed resets on mode change
Clarify that the commanded airspeed defaults to FW_AIRSPD_TRIM when no
airspeed has been commanded, and document that the commanded airspeed
resets on every flight mode change.
Signed-off-by: Gregor Hohl <gregor.hohl@auterion.com>
* docs(flight_modes_fw): clarify DO_CHANGE_SPEED param1/param2 handling
Signed-off-by: Gregor Hohl <gregor.hohl@auterion.com>
---------
Signed-off-by: Gregor Hohl <gregor.hohl@auterion.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
