Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plane: L1 Control for Straight and Curved Path Following #101

Closed
wants to merge 3 commits into from

Conversation

brnjones
Copy link
Contributor

This is an implementation of a guidance algorithm described in A New Nonlinear Guidance Logic for Trajectory Tracking (AIAA 2004-4900). This provides controlled path following around curves and straight lines, simplified user setup, and architecture extensible to future higher level path generation algorithms.

The control law consists of 2 parts, 1) Calculation of a reference waypoint (L1_ref) along the trajectory to be followed, and 2) Calculation of a lateral acceleration command that intercepts the calculated L1 reference point. For aircraft, this lateral acceleration command is equivalent to a bank angle command.

Major advantages to the L1 control law are:

  • Reduction of number of configurable gains: Nav_Roll PID and xtrack error gain are replaced with an insensitive L1 reference distance. This largely eliminates tuning for path following.
  • Improved disturbance rejection and circular path tracking in wind
  • Extensible to future higher level trajectory generation algorithms, follow-me, 4DT, vector fields, obstacle avoidance, formation flight, etc. Behavior can be updated by introducing another L1 reference point calculation function.

Implementation

First, a reference waypoint called “L1_ref”, is calculated within the navigation control loop. L1_ref is placed differently depending on straight line or circular following. Furthermore, L1_ref is placed differently depending on which region the aircraft is located. Once the L1_ref point is calculated, the angle between the velocity vector and desired path is calculated. This is performed at 10Hz in navigation.pde. In attitude.pde, a bank angle command is calculated to put the aircraft on a circular path to intercept the L1_ref point.

In essence, the aircraft follows a reference point that constantly slides along the desired path. The method for calculating L1_ref for straight line and circular path following are shown below:

Waypoint_diagrams1

Waypoint_diagrams2

How to Use

To enable L1_Control for loiter and straight line following add the following to APM_Config.h:

define L1_CONTROL ENABLED

define L1_REFERENCE_LENGTH [length (meters)]

With the APM1 or 2 on a Skyfun at ~20 meters/sec, a L1 reference length of 40 meters works well.

@rmackay9
Copy link
Contributor

This is similar in some ways to the way we're doing waypoints for arducopter now. leonard hall designed all that code for AC.

@brnjones
Copy link
Contributor Author

@rmackay9 Yes, it definitely shares the concept of navigating to a point moving in a way that places the vehicle on the desired path. I did review Leonard's code in Arducopter, cool stuff is happening!

@tridge
Copy link
Contributor

tridge commented Mar 10, 2013

Hi Brandon,
I think this is very interesting! I like the structure a lot, although I think I'd like it to be selectable at runtime, so we get more people using it.
I'd like to start a discussion on this on the drones-discuss list, and get Paul Riseborough involved. He's been experimenting with some similar ideas.
I'll start a discussion and see how it goes.
Cheers, Tridge

@arthurbenemann
Copy link
Contributor

I have implemented the run-time selection, I'm finishing a simulation as we speak.

arthurbenemann added a commit to arthurbenemann/ardupilot that referenced this pull request Mar 11, 2013
arthurbenemann added a commit to arthurbenemann/ardupilot that referenced this pull request Mar 11, 2013
…the L1 navigation controller.

This way the L1 controller can be switched on and modified in flight, setting the paramter L1_dist to zero disables the controller and uses the old PID for navigation. This commit is part of issue ArduPilot#101
@arthurbenemann
Copy link
Contributor

I added a parameter to enable and configure the L1 controller on the commit: 5a016bd

I added some simulations at: drones-discuss. Here is one of the results:

Flight 2 - 8 m/s wind from north (Blue is L1, Yellow is PID)

Teste 2

… for L1 Control.

calc_L1_circ: generates L1 reference point on circle
calc_L1_line: generates L1 reference point on line
…ation. L1_Control is a non-linear navigation controller that does not require tuning and provides curved path following.

To enable L1_Control for loiter and straight line following add the following to your APM_Config.h:
#define L1_CONTROL ENABLED
#define L1_REFERENCE_LENGTH [length]
where [length] is a reference length in meters.  The smaller the value the higher gain.  Try 2*groundspeed.
@tridge
Copy link
Contributor

tridge commented Apr 16, 2013

This is merged in master now - thanks for a fantastic contribution!

@tridge tridge closed this Apr 16, 2013
@cheslee-z
Copy link

How can the L1 controller eliminate errors?I found that arthurbenemann's simulation results still have errors between the actual flight trajectory and planning track of the aircraft

@magicrub
Copy link
Contributor

@chesily is that statement based on the latest release.. or the 7 year old code referred to in this PR?

@cheslee-z
Copy link

@chesily is that statement based on the latest release.. or the 7 year old code referred to in this PR?

the latest release

@magicrub
Copy link
Contributor

I added an integrator a few years ago.. but there is still a small rare bug that causes an offset that we haven't tracked down.

@liamclarkza
Copy link

I added an integrator a few years ago.. but there is still a small rare bug that causes an offset that we haven't tracked down.

@magicrub - Any updates on this? I am finding that an aircraft I use seems to suffer from this.

In a scenario where an aircraft is following a line between waypoints that are far apart (>1000m), I find that the aircraft converges towards the line but often will remain offset with an xtrack error of anywhere up to roughly 3m. In the case of flying a grid, we find that this offset is roughly the same in magnitude and direction regardless of the direction we are flying (i.e. the aircraft will usually have to an offset to the left or right of the flight path for the whole flight) which rules out being blown downwind. The plane has been tuned according to the docs and the NAVL1_XTRACK_I parameter is 0.02 (so it should reduce the steady-state xtrack error to zero - even if this takes a long time).

I am happy to look into this further so ideas about what to start with would be helpful. Interestingly, I seem to be able to counteract this offset by trimming the aircraft every flight over a long line. Once the aircraft is trimmed it usually remains on track for that flight. However, I would expect the integrator to take care of this and I feel that trimming the plane to account for the xtrack error is not a proper solution to the problem.

@Linjieqiang
Copy link
Contributor

Any update?

@ahelten
Copy link

ahelten commented Apr 7, 2021

I am seeing this problem with a skid-steer rover that I'm attempting to steer centimeter precision. I see this problem with a dev version from only a few weeks ago (commit 526065a).

The offset in my case can be several centimeters (as bad as 60cm at times) which is very problematic when trying to avoid obstacles that are only a few centimeters from the track. In my case, the rover follows the track perfectly at times but other times it follows an offset line perfectly but this offset results in collisions with obstacles!

I have not tried trimming but agree this is not an acceptable solution given it must apparently be repeated with each mission.

@magicrub
Copy link
Contributor

magicrub commented Apr 7, 2021

Folks, please open up a new issue instead of commenting on an 8 year old PR.

@ahelten
Copy link

ahelten commented Apr 7, 2021

Point taken. Found a 6 year old issue #2650 about xtrack error not always converging to zero (which results in what I've been calling a "navigation offset").

shellixyz added a commit to shellixyz/ardupilot that referenced this pull request Jul 5, 2022
magicrub added a commit to magicrub/ardupilot that referenced this pull request Oct 26, 2022
…aram_audit

vtol_param_audit.lua: This param is learned after every flight
shellixyz added a commit to shellixyz/ardupilot that referenced this pull request Apr 20, 2023
@congkhanhlck
Copy link

I've consulted the paper at https://doi.org/10.2514/6.2004-4900, but when comparing the source code and some information on the guidance page at https://ardupilot.org/dev/_images/rover-L1.png, I don't understand why there are formulas for calculating L1_dist and latAccDem like that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants