rroche
January 5, 2022, 6:00pm
1
January 12, 2022
Join us
Agenda
Community Q&A
Project Updates
High priority queue
Release
In-Depth discussions
Community Q&A
Project Updates
Farhang was assembling, documenting and configuring the Holybro X500 V2 Kit
Airframe configuration: Holybro X500 v2 airframe addition by farhangnaderi · Pull Request #18997 · PX4/PX4-Autopilot · GitHub
Documentation for the build: X500 v2 Assembly docs by farhangnaderi · Pull Request #1729 · PX4/PX4-user_guide · GitHub
Let’s review and get the support in.
He needs some help with building QGC using docker. Must be something local since CI uses the same environment.
When switching to control allocation as default we have the opportunity to revise airframes to only set the parameters that are really necessary instead of also covering some opinionated configuration that was once used.
Thomas Stastny is contributing improved guidance for fixed-wing flying which (for now optionally) replaces the existing L1. It requires a wind estimate to unfold its advantage over L1. If the wind estimate gets lost or invalid during a mission it can still be used e.g. to not switch controller mid-flight.
PX4:master
← ethz-asl:pr-npfg
opened 10:35PM - 07 Dec 21 UTC
**Describe problem solved by this pull request**
High winds can degrade positio… n tracking performance of slow-flying fixed-wing vehicles (or VTOL platforms in transitional states). Current mitigation logic in the fixed-wing position controller is based on an arbitrary threshold leading to jumpy behavior when winds rise close to the vehicle's nominal airspeed, see
https://github.com/PX4/PX4-Autopilot/blob/495f1c916564c867bc216ccd0ef28361fea341e3/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp#L2113-L2116
and inefficient (w.r.t. energy demands.. see similar discussion on ground speed undershoot / air-ground angle in #10219), see
https://github.com/PX4/PX4-Autopilot/blob/495f1c916564c867bc216ccd0ef28361fea341e3/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp#L384-L395
Further, wind is currently estimated onboard, but not used to aid any higher level control loops.
**Describe your solution**
This PR adds an optional new library with an implementation of a more generalized Nonlinear Path Following Guidance (NPFG) logic with excess wind handing derived for minimum energy usage (*endurance* optimal behavior). If enabled (via parameter), the logic replaces L1 and the current ground speed undershoot logic.
NOTE: this PR does **not** replace any legacy functionality by default. The intention here is to make the logic available for users comfortable with a more advanced technique, get flight feedback, suggestions, end-user experiences, and hopefully encourage the restructuring of fixed-wing guidance handling to be more modular (see later notes on repeat code!). Attempted to make a minimally invasive addition.
Primary references:
- T. Stastny and R. Siegwart. "On Flying Backwards: Preventing Run-away of Small, Low-speed, Fixed-wing UAVs in Strong Winds". IEEE International Conference on Intelligent Robots and Systems (IROS). 2019. https://arxiv.org/pdf/1908.01381.pdf
- T. Stastny. "Low-Altitude Control and Local Re-Planning Strategies for Small Fixed-Wing UAVs". Doctoral Thesis, ETH Zürich. 2020. https://tstastny.github.io/pdf/tstastny_phd_thesis_wcover.pdf (Paper III)
- TODO: still wrapping up documentation for current implementation + stability analysis (done, not prettified)
Available wind handling modes:
1) *Wind excess mitigation*: reduce *rate* of run-away from track at the trim airspeed.
2) *Wind excess regulation*: adjust the airspeed setpoint to match the wind speed if it exceeds the airspeed.
3) *Minimum forward ground speed maintenance*: adjust the airspeed setpoint to maintain a minimum forward ground speed along the current bearing vector.
4) *Track keeping*: adjust the airspeed setpoint to return to the path until resting on track at zero ground speed until wind subsides.
The higher modes fall back into the lower ones when the required airspeed setpoint is not available (max airspeed exceeded). See the following video documentation and animation of the various modes and performance in flight tests for a general / layman's recounting of the logic (more details in the above paper references)
[![NPFG video](https://img.youtube.com/vi/oM690LO29kM/0.jpg)](https://youtu.be/oM690LO29kM)
![snowman_animation_compressed](https://user-images.githubusercontent.com/8026163/145060130-eca6dce3-e61c-4040-9cb7-abb45d405928.gif)
Other features:
- period and damping can be set just as in the L1 controller, so no change in tuning is necessary from legacy setups
- optional (advanced) period lower bounds (based on knowledge of the roll time constant) will automatically adapt the period and guard against possibly unstable tunings
- optional (advanced) upper period bounds, if enabled, will adapt the period to better track the given path
Gotchas:
- this controller will NOT work properly without sufficiently dynamic (and good) wind estimates. Flight experience has shown that estimating 1-2 second length gusts should be sufficient for good performance. With EKF2 - this translates to tuning up the EKF2_WIND_NOISE parameter to 1m/s/s.
- the controller will get disabled if the wind estimate is invalid -- however, current "invalid" is only defined here as having a finite value. E.g. covariance considerations would likely be better.
- the wind estimate will not converge immediately on take-off (initialized at 0m/s), so performance will lag a bit until the estimator catches up.
- I had to disable the "load factor" airspeed check in high winds.. otherwise it invalidates the airspeed for some reason.
Possible future strategies for the above points:
- use an instance of the stand alone wind estimator, tuned specifically for this guidance law.
- consider an optionally set wind speed and direction initialization before takeoff (e.g. measured on ground with anemometer)
*Why* should one use this logic?
- deterministic behavior in inclement conditions is desirable for an aircraft. Aside from the logic's endurance optimal properties, removing thresholding mitigation strategies means we have continuous acceleration commands while following a given path, no jumpy behavior, and the path following behavior is *repeatable*.
- as the logic is based on a generalized path following form - following future paths other than circles or lines require no additional augmentation to the guidance logic (assuming one has the closest point, and tangent vector available), something not easily doable with L1.
- no need for arbitrary minimum speed constraints, progressions through zero airspeed and zero ground speed are mapped to output controls continuously in the logic.
- no need for switching logic on circle tracking. stability bounds remain for any curvature, and there is a smooth bearing transition when transiting from far off the track until following on track.
DISCLAIMER: the controller will behave almost identically to L1 in the vast majority of cases. There isn't really a need to improve nominal performance. The gains come from the wind handling logic, and the future possibility to generalize to different path shapes.
Future recommendations:
There is a lot of copied over interfacing code from the L1 controller to keep the same functionalities available while using either guidance law (e.g. the roll slew limits). Also there is a mess of if conditions throughout the already somewhat hard to read fixed-wing position controller module. Would be good to perhaps design a guidance class, where the standard desired output methods can be available in any derived class. Further.. we should separate and encapsulate navigation logic, from guidance logic, and command output filtering. For example.. everything below the this line in both the header and cpp should ideally not be part of this library..
https://github.com/PX4/PX4-Autopilot/blob/ea7a56290ad38a320ece772711e94752b7d5c40d/src/lib/npfg/npfg.cpp#L517-L519
**Test data / coverage**
A few simulations to more easily reproduce specific cases --
Comparison L1 + current wind mitigation logic vs wind-aware NPFG:
L1 14 m/s log: https://review.px4.io/plot_app?log=e752d5ff-4250-4d33-a0fa-48259ca71966
NPFG 14 m/s log: https://review.px4.io/plot_app?log=da1455d4-4358-4540-9845-9a848d426952
Same tuning - period = 10s, damping = 0.7, same conditions - airspeed trim = 15 m/s, wind speed = 14 m/s north.
![l1_w14_states](https://user-images.githubusercontent.com/8026163/145113835-e2d4d41f-0e96-4b2c-a849-bb5451e6d54a.png)
![npfg_w14_states](https://user-images.githubusercontent.com/8026163/145112780-156af34d-d7f8-495f-9915-b608d13fb195.png)
![l1_npfg_pos](https://user-images.githubusercontent.com/8026163/145112799-c28aee00-0a88-4296-9637-05c04ce0b44d.png)
Note the jumpy roll commands about the threshold of the air-ground angle and ground speed, and drifting behavior once the threshold is undershot. Further the objective 5m/s minimum ground speed setting is not maintained. NPFG keeps the circle, maintaining the 5m/s *forward*, in this case, minimum ground speed, and roll commands are continuous.
Example in SITL with wind speed (17m/s) exceeding the vehicle's trim airspeed:
L1 17 m/s log: https://review.px4.io/plot_app?log=c90a1c7c-34d3-4691-8e67-71729cc354e1
NPFG 17 m/s log: https://review.px4.io/plot_app?log=ac88c8f2-844b-4519-9031-f6d262abdce3
![speed_plot_npfg_w17](https://user-images.githubusercontent.com/8026163/145072161-ad687162-02fa-4740-973b-8be368e8f994.png)
NPFG is shown in this log using the minimum forward ground speed mode. Keeping forward ground speed of 5m/s when the max airspeed allows, and reducing airspeed to the trim value when no additional airspeed is needed (e.g. down wind legs). Further, the end of the log has a track keeping mode demonstration (with min. gsp turned off) - where it ends up returning to the track.. and sitting at very near zero ground speed. Current L1 + ground speed undershoot gets stuck in place never reaching the first loiter (but this behavior will vary depending on the side from which it approached the loiter)
Flight testing --
The logic of the controller has been flight tested quite extensively in its various iterations (see some examples in https://arxiv.org/pdf/1908.01381.pdf and https://youtu.be/oM690LO29kM of flight in very strong winds). However, this new firmware (cleaned up, rebased, etc) still should need some new flight testing validation. Also checking behavior in other modes.. hold, landing, etc.
Happy for comments, concerns, and windy flight results :) @sfuhrer @Jaeyoung-Lim @acfloria @CarlOlsson @sverling (and anyone else!)
@Jaeyoung-Lim has a draft pr to support local coordinate guidance for fixed-wing. It simplifies adjustments to the controller by quite a bit. To support accurate guidance above 100km distance between waypoints we need different calculations than now in any case.
PX4:master
← PX4:pr-fw-l1-local-coordinates
opened 09:27PM - 09 Jan 22 UTC
**Describe problem solved by this pull request**
Previously the L1 guidance for… Fixedwing/VTOL vehicles have been using global coordinates.
- None of the other controllers that are used by multicopters work directly on global coordinates.
- When passing position setpoints with offboard, the setpoints were converted into global coordinates just so that it can be used by L1. This results in redundant conversions(local->global->local) internally in the controller
- This prevents from using the L1 controller without the global position being initialized, such as using external vision based position estimation. Such use case is particularly useful for rovers that operate indoors
**Describe your solution**
This PR changes the input of the `ECL_L1_PosController` to use local coordinates instead of global coordinates(WGS84)
While this PR includes transition of the coordinates of L1 from global to local for the `ECL_L1_PosController`, the integration into the fixedwing position controller is still relying on projecting waypoints into the local frame. This is due to the fact that a lot of the control logic in the fw position control is using the `pos_sp_triplet` directly.
For example,
https://github.com/PX4/PX4-Autopilot/blob/0b1402afe2a214dcfbd0d6f8f10b6a1041067ca9/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp#L1074-L1078
I have left this PR as a draft since I am not sure what would be a good direction for the fw pos controller since the pos_sp_triplet is used throughout the controller
**Test data / coverage**
- Tested in SITL Gazebo with `plane` model
```
make px4_sitl gazebo_plane
```
**Additional context**
- Related to https://github.com/PX4/PX4-Autopilot/issues/5123
High priority queue
Discussion based on board: High-Priority Queue · GitHub
Release
In-Depth discussions
For smaller groups expanding technical discussions, stay until the end and follow up.
If you have any feedback or corrections please comment on this post.