Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release
Specify what you are trying to achieve
Specify what environment / platform you are using
Prepare a Link or Document to help understand if possible
First, ask the question on the Slack or create a Github Issue !
If you take over 5 minutes for the question, please continue in Slack or a Github Issue.
Patrick had a quadrotor tiltrotor working with some customizations for it to run as a VTOL tiltrotor and take advantage of the existing tilt rotor logic. The last experimental state is on a GitHub branch here: Commits · PX4/PX4-Autopilot · GitHub We can help with build issues offline of the call.
He’s interested because it’s supported by MAVSDK and the tests with the 1.13 release should not run through follow me yet because it was merged soon after. Users who plan to test the new follow me use px4 main. Discussion about version sync between PX4 and MAVSDK. It would be good to query the capability instead of relying on a version tag because e.g. it’s currently not available on flash-constrained targets. The PX4 parameter of the new follow me could be used to detect it.
If the entire interface would be very strictly defined in MAVLink it could be done with a capability flag but that discussion applies to other functionality like should there be standardized parameters or getters for all strictly defined properties that are set through MAVLink? e.g. DO_CHANGE_SPEED
There’s an open discussion for this here: common: Set mission yaw mode command by hamishwillee · Pull Request #1297 · mavlink/mavlink · GitHub
During the development of fixed-wing landing with nudging he came across the RC override option that just switches mode upon stick movement (not enabled for fixed-wing by default):
PX4:main ← PX4:fw-landing-refactor
opened 03:40PM - 04 Jul 22 UTC
follows #19869
## Describe problem solved by this pull request
Fixed-wing a… uto land issues:
- the logic is very convoluted / hard to understand what will happen given the many different parameters to set
- the altitude setpoints output from the flare curve are not well tracked (and likely *cannot be while using a feedback scheme with with TECS); further they are being ignored by open-loop maneuvers anyway
## Describe your solution
- landing logic simplified to commanding a constant glide slope to the ground from the approach entrance, and commanding a constant (small) sink rate `FW_LND_FL_SINK` once below flaring alt
- flare start is triggered by the maximum of:
- a flare *time* based altitude, `FW_LND_FL_TIME` * descent rate, used to account for differing descent rates (e.g. due to wind)
- OR triggered by the `FW_LND_FLALT`, if it is larger
- flare pitch limits and height rate commands are ramped in from the previous iteration's values at flare onset to avoid jumpy commands
- TECS controls all aspects of the auto landing airspeed and altitude/height rate, and is only constrained by pitch and throttle limits (lessening unintuitive open loop maneuver overrides)
- throttle is killed on flare, full stop.
- flare is the singular point of no return during landing
- lateral-directional guidance is active the full time, roll is only constrained by "near ground" limits given the airframe's geometry `FW_WING_SPAN`, `FW_WING_HEIGHT`
- lateral manual nudging of the touchdown point is configurable via `FW_LND_NUDGE`, allowing the operator to nudge (via remote) either the touchdown point itself (adjusting approach vector) or shifting the entire approach path to the left or right. this helps when GCS map or GNSS uncertainties set the aircraft on a slightly offset approach"
- mission feasibility only checks to make sure the glide slope less than that corresponding to `FW_LND_ANG`. Only land waypoints with a previous waypoint type of `LOITER_TO_ALT` and `WAYPOINT` are accepted. (though the fw pos ctrl internal logic is a bit more agnostic to this).
- Desired max sink rate `FW_T_SINK_R_SP` is overridden, up to the physical limits set by `FW_T_SINK_MAX`, to accommodate the commanded glide slope (according to `FW_LND_ANG`)
- negative relative glide slope altitude now allowed to make sure that the altitude tracking outerloop continues the same descent rate even when the relative slope altitude is below the terrain. this is necessary because the vehicle (with current trajectory generation logic) will smoothly try to intersect the otherwise flattened altitude setpoint and throttle up just before flaring, which is undesirable. now the glide down will be unaffected and only the flare will cause the vehicle to disrupt the approach.
- Abort status unified into a bitmasked field `FW_LND_ABORT`
- Optional terrain following behavior during landing approach by setting `FW_LND_USETER=2`. Default is now `FW_LND_USETER=1`, sticking to a fixed glide slope reference altitude and only use the terrain estimate to detect when to flare. Results in more stable/steady landing approaches and resolves the problem of e.g. high trees below the vehicle's glide slope disrupting the glide. May still be disabled with `FW_LND_USETER=0`
## What else is missing (for another day, another PR)?:
- The glide slope will not be properly tracked (always a bit above the slope at steady state). This be due to the altitude outer loop used in TECS currently which has a feedforward *gain* on the glide slope, instead of feedforward command. Another issue is that the glide slope tracking is not speed independent. Neither of these issues are trivial to change at the moment due to the use of the trajectory generator and velocity smoother (which send state feedback independent height and height rate commands from the integrated reference trajectory). IMHO - a simple feedback based path following law for the altitude outer loop would do much better here, and make it simpler. The trajectory generator could still be used to set the "turn in" point (i.e. the height error boundary at which we stop commanding "full" down or up, and start blending in the actual glide slope of the path. But this would be recalculated each time based on current **ground speed** (or a filtered version of it, if necessary). The only issue this approach would not cover, is discrete setpoint changes on altitude (which the current velocity smoother does). However this can easily be smoothed in a slew-ish approach.
- Another smaller issue is the logic found here: https://github.com/PX4/PX4-Autopilot/blob/61cdd315a6be28981fd7a4b54d7b3ad85ba6f027/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp#L1700-L1707
This has a *cusp* on the setpoint exactly at the point we want to track, which could lead to some small jittery setpoints. Using the path following approach outlined in the last bullet, this could be avoided, and still achieve the desired behavior by simply limiting the approach vector below the path to horizontal.
## Test data / coverage
**Landing**
- [x] demonstrate nudging in approach angle mode
- [x] demonstrate nudging in approach path mode
- [x] demonstrate landing
https://review.px4.io/plot_app?log=e45b9dfe-7483-4b66-80fc-2218d9bfd639
Video with nudging to avoid cornfield and land center on a 2m wide "runway": https://drive.google.com/file/d/1mzqC2vivPBiAp2-Ci-lTnpoCzb3lMtdH/view?usp=sharing
**VTOL**
- [x] check nothing breaks on VTOL ops
We need to make sure that RC override never kicks in while sticks are in use by the mode because e.g. nudging is available. The mode should in any case be able to decide if override is allowed. Discussion about the user experience with RC override vs enable nudging in all situations and making sure the UX is good in all situations you want to push the drone and evolve away from stick-triggered mode switches.
During development of fixed-wing takeoff improvements he came across the takeoff command requiring an explicit takeoff position. Wouldn’t it be useful to specify the possibility to just command a takeoff with a certain altitude and the vehicle would decide for the loiter position that best suits the vehicle position, orientation, … before takeoff and when it reaches the altitude.
PX4:main ← PX4:fw-takeoff-refactor
opened 10:57AM - 04 Jul 22 UTC
## Describe problem solved by this pull request
Issues:
- takeoff is currently… defined by a waypoint, but should really be seen as an action or procedure
- many entanglements with TECS and other fixed-wing modes
- many hardcoded limits (magic numbers!) and open-loop behaviors
## Describe your solution
### Summary
- takeoff behavior now defined by a **course** (ground-relative direction) to takeoff in, and **clearance altitude** to "clear" before proceeding with the mission.
- takeoff mainly just concerns getting to a specific airspeed and altitude, let TECS control this (in a constrained manner)
- some incremental work on disentangling things
- NOTE: this is mainly a runway takeoff refactor, so the launch detection method is untouched, except for also adhering to the new course-based takeoff logic.
### Commit-by-commit
[fw pos ctrl: handle takeoff detection when switching to takeoff mode while in air](https://github.com/PX4/PX4-Autopilot/commit/62c51a25247484623de95595f9f1727c14aebd34)
attempt to disentangle / consolidate reset logic a bit.
[remove in air vs landed knowledge from TECS](https://github.com/PX4/PX4-Autopilot/commit/f3cfe217877938d083e2934c49776f3b2c8fec7d)
TECS is doing too much internally. It should not need to care whether we are landed or not. That's the job of the outer loops using it. This commit shifts the responsibility of integral reset handling outside. TECS is now running in all cases except during rotary wing or transitioning flight modes (the latter still something to be discussed), and during landed state, the integrals and trajectory generator are constantly reset.
[TECS: speed (only) -based underspeed detection](https://github.com/PX4/PX4-Autopilot/commit/ba289a3403f9ebbba7c77477a6a01317abba25f2)
- underspeed condition changed to only tell us whether or not we are under the desired speed
- airspeed min is a bit conservative as an underspeed detection metric, as we can even command minimum airspeed
- instead of arbitrary scale on min airspeed, use an expected TAS error bound to mark the start of underspeed detection. Even when TECS is tuned well, we can expect up to 2m/s airspeed tracking error which should not be fully penalized. This value is hardcoded for the moment, but could be changed or parameterized if necessary.
- change underspeed condition from binary to continuous and ramp in mitigation effects to avoid jumpy setpoints within soft bound range
- allow the airspeed filter to reach zero, see the following figure showing the 3m/s cap is now gone ([this script](https://colab.research.google.com/drive/1ebFC5OshLoS_vj1gjhg2FGLiVfG6LUbq?usp=sharing) was used to generate the plots)
- NOTE: this filter should ideally not be inside TECS either. But .. for another PR.
[fw pos ctrl: rework manual takeoff aid](https://github.com/PX4/PX4-Autopilot/commit/25e1897186c0bb52d50461d7bfee5582022b5d9c)
- takeoff situational knowledge removed from all other modes except manual (or actual takeoff mode). why? IMHO we should only allow takeoff when it has been commanded, and handle it explicitly. If we are in other modes (e.g. loiter..) the expectation should not be that we are possibly taking off. Flight condition protections should be handled independently, and near-ground states should also be handled independently. The latter especially requires a bit more consideration if already in other mission modes.
- manual takeoff is marked complete if at a **controllable airspeed** - this is a *manual* mode, so we give as much authority to the operator as possible while helping just a bit in the beginning to get the aircraft in the air, so altitude or time are not considered here.
- minimum pitch bounds TECS until manual takeoff complete
- remove individual roll constraints during manual takeoff (ground proximity constraints coming in subsequent commit)
[fw pos ctrl: encapsulate wing tip strike constraint for roll angle](https://github.com/PX4/PX4-Autopilot/commit/ce8162573caee1a3e0decfd79529af711bf41ecf)
- consolidate near ground roll limiting using a conservative approximation of aircraft geometry constraints
- two new parameters `FW_WING_SPAN` and `FW_WING_HEIGHT` for the general wing strike limiting case
$\phi_\text{strike} = \sin^{-1}\left( 2 h / b \right)$
$\frac{ \partial\phi_\text{strike} }{ \partial h } = \frac{2}{b \cos\left( 2 h / b \right)}$
$\frac{ \partial\phi_\text{strike} }{ \partial h } \left(h=0\right) = 2 / b$
$\phi_\text{strike} \approx 2 h / b$
Where $\phi_\text{strike}$ is the roll angle where a strike would occur, $h$ is the height above ground, $b$ is the wing span (tip to tip). [This script](https://colab.research.google.com/drive/1gLUxiXC8j7jMP53AgQo7isaKdTJgN1at?usp=sharing) was used to generate the plot below.
[fw pos ctrl: refactor takeoff mode](https://github.com/PX4/PX4-Autopilot/commit/461dcbf22839b348cdd8040bb9264285efd2f6db)
This is the actual refactor of the takeoff logic after all the preliminaries in previous commits were taken care of.
New state machine:
1. **throttle ramp**: throttle is ramped from zero to `RWTO_MAX_THR` over `RWTO_RAMP_TIME`. throttle ramp must complete before switching to next state to avoid a jump in throttle setpoint just after takeoff if the takeoff airspeed is reached before the ramp is complete
2. **clamped to runway**: continue at `RWTO_MAX_THR` until the takeoff airspeed is reached
3. **climbout**: climbout until clearance altitude is reached. `RWTO_MAX_THR` is blended back into TECS commanded throttle with some small time hysteresis to avoid throttle cuts directly after lift off.
4. **fly**: once clearance altitude is reached, proceed with the mission.
Other changes:
- takeoff waypoint altitude is used as a clearance altitude, set such that once above, the aircraft has cleared all ground occlusions and may proceed with the mission. **IDEALLY** this would be a new takeoff mav cmd. But for now we can bootstrap by using the existing waypoint until we're comfortable with the approach.
- post takeoff, the aircraft follows the infinite line sourced from the launch point in the direction of the takeoff waypoint
- `RWTO_L1_PERIOD` added to allow setting a more aggressive L1 or NPFG tuning during ground roll
[fw att ctrl: log the yaw rate command controlled by the wheel](https://github.com/PX4/PX4-Autopilot/commit/c6096e99b546903c0f1b84727365b356958df41f)
Wheel and yaw rate are controlled separately (with two separate gain sets). This just logs the wheel controller output which wasnt done before. NOTE: a separate discussion to have would be changing the wheel logic in general, e.g. separating it from the rudder, but this can be left to another PR.
[fw pos/att ctrl: pass manual nose wheel increments during takeoff ground roll](https://github.com/PX4/PX4-Autopilot/commit/0a7ed345102cdc885c320ac00e8474de99185f89)
Allows "nudging" the vehicle on the runway (if `RWTO_NUDGE` enabled) by directly passing through the yaw stick input to the wheel. This is useful when map, GNSS, or yaw errors on ground are misaligned with what the operator intends for takeoff course. Particularly useful for skinny runways or if the wheel servo is a bit off trim.
[fw pos ctrl: head straight for next waypoint after takeoff](https://github.com/PX4/PX4-Autopilot/commit/6adea1d52cc2f0bf67a1acf2cc55242f011aed19)
Dont follow the line between takeoff "waypoint" and next point, just go directly to the next point. We are moving towards not having a takeoff "waypoint".
[fw pos ctrl: organize state variables](https://github.com/PX4/PX4-Autopilot/commit/5d722114781e2397fd69c0e1c443775f07b242ee)
Just organizes the header a bit to make it easier to find variable related to a specific group or mode. Also will help when we hopefully start splitting this mega class into small classes.
## Describe possible alternatives
**Throttle max used until climbout**
Ideally.. TECS would control the airspeed even on the ground instead of hard-coding the takeoff throttle. The param itself `RWTO_THR_MAX` even specifies a maximum, so could be used only as constraint (similar for the throttle ramp). However, one concern would be that on lift-off there may still be some jump in setpoint due to the instantaneously changing conditions. This could be handled by possibly freezing (and putting some hysteresis) on the throttle setting that achieved the airspeed necessary for takeoff, but then would probably need to be filtered. Further, at the beginning of the throttle ramp, the aircraft is in a "landed" state, so the TECS integrators are getting reset constantly. If the ramp is only set as constraint, it could be that there is some weird behavior where the time based ramp constraint is satisfied, but the throttle setpoint itself does whatever it likes underneath this constraint (possibly pulsing, possibly taking a non-linear, non-gradual trajectory).
**Launch logic (e.g. catapult or hand)**
Likely we need to revisit this logic -- it is currently not regressed in this PR, but has been a bit neglected as this was primarily a runway takeoff refactor. Would leave this for another PR with input from interested parties who use this functionality.
## Test data / coverage
**Manual takeoff aid**:
- [x] make sure throttle does not spool up when "landed" and throttle stick is below deadzone in **position** mode
- [x] make sure throttle does not spool up when "landed" and throttle stick is below deadzone in **altitude** mode
^thanks @sfuhrer
**Auto takeoff**:
- [x] flight test
- [x] check that nudging works
https://review.px4.io/plot_app?log=e45b9dfe-7483-4b66-80fc-2218d9bfd639
Video: https://drive.google.com/file/d/1-j2IDMTEZ5bGhBx-0-I-2tls_cLj5h5k/view?usp=sharing
**VTOL**
- [x] check nothing breaks on VTOL ops
It would be good to discuss this on the MAVLink call because it’s for multicopter and fixed-wing the easiest possible takeoff is starting from the current location reach a certain altitude and stay/loiter there. For the case of a mission the takeoff could be done automatically if not specifically planned.
Discussion about if a takeoff waypoint as such is necessary/useful. E.g. for multirotor the basic takeoff altitude would be enough. For VTOL maybe the steps should be more explicit multicopter takeoff to a certain altitude, transition into a certain direction? For fixed wing there might be the option to plan a runway takeoff but if the vehicle is hand launch that could be left away and it would just continue the direction it was thrown.
The main issue is that the UART pins usually used for serial debug consoles are attached to the ADSB so the console is disabled by default. The MAVLink shell doesn’t work properly when no NuttX level serial console is availble.
Please raise any concerns in:
PX4:main ← PX4:manual-control-setpoint-1to1
opened 06:11PM - 12 Oct 20 UTC
**Describe problem solved by this pull request**
Fixes #9331 and works towards … a solution for part of https://github.com/PX4/Firmware/issues/15874
**Describe your solution**
Rescale `manual_control_setpoint.z` which represents the throttle stick value from a range of [0,1] to [-1,1].
**Describe possible alternatives**
I think for nicer usage in all the different modules it would be helpful to extend the `Sticks` class to provide the common scaling and gestures (is stick below minimum) from one single place.
**Test data / coverage**
Not yet tested.
**Additional context**
This is also useful to be able to convert between RC modes (https://www.rc-airplane-world.com/rc-transmitter-modes.html) on the fly without having to recalibrate everything.
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests Issues
PX4 Dev Call: April 27, 2022
Discussion based on: High-Priority Queue · GitHub
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
Project Updates
General Discussions
Weekly Overview
Github
Slack
Last Dev-Call
Release