Autopilot Control

[rgleason]

Sean,
I do not understand all of your most recent post, nor can I anticipate the result, it would take a more detailed explanation of what you are proposing,.

However Bdbcat's parameters for when to turn take into account XTE and NR (normal range) and RNG as shown in Send a Route to the Autopilot, the basics

Having several waypoints to smooth out the turn as you suggest might also help with premature turns that hit the buoy. The ellipse idea is interesting, does it need to be so involved though?

I like to think of XTE +/- max as that "runway" concept. Sometimes it needs to be tight and sometimes loose. When sailing it often needs to be very loose and flexible.

I do think we need more feedback and understanding about how the current parameters work when turning at a mark, however I do think their may be ways to improve the AP interface.

[rgleason]

So that rudder feedback loop is essential, and that is why Raymarine told me the first thing to do is to get a rudder indicator, rather than upgrade my 24 year old AP system. The tech advised that the rudder indicator would improve steering more than an upgrade!

So does OpenCPN currently use the rudder indicator and a feedback loop too or is this for some future version?

It seems to me like there is the steering machine, an electric motor & rudder, or whatever, then there is a program calculator for AP that does all the calculations, that has normally been a separate computer from the navigation computer.

Is it possible we are talking about a plugin? It could be as simple as the Raymarine Autopilot interface that is in Mike's ShipDriver plugin, but with a heck of a lot more smarts built in?

[rgleason]

Two A/P Requests from Tracker (Thanks for the new Tracker, Dave!)

FS#2131 - A/P Splitting large A/P course change commands into smaller segments to minimize oversteer

FS#2155 - A/P Provide wind vane like autopilot output option

[Hakan]

Originally Posted by DotDun

1) Your XTE multiplier is handled in commercial APs via the 'responsiveness' setting, i.e. how aggressive do you want the APs to 'get back on track'.

Not really, as I sees it:
In the AP regulator we've two or three parameters depending when it's constructed. My dated one seems to have a PI-regulator while never have certainly added a derivation, the PID-regulator.
On my AP the P-value is called gain and can be directly adjusted.
The I-value is called sea filter but it's certainly a normal integrator, that is a time factor and tell the regulator to add more gain if a deviation persists after a certain time. The "Sea filter" or the integration time can be adjusted on my AP as well.
The XTE is handled by the AP as a change of the set point, course to steer. What I do when the XTE value is increased is to make the deviation bigger and force the AP to steer closer to set point.
Never APs have better regulators and don't need my XTE factor.

2) How would you convey your new information to the AP? The NMEA protocol set is well established and I doubt you'll garner much interest in that forum to change it.

My XTE factor is used very simple, I change the routeman's XTE value before transferred to the AP:
In routeman.cpp (In my personal branch only.)

bool Routeman::UpdateAutopilot()
{
    //Send all known Autopilot messages upstream
    
    //RMB
        {

            m_NMEA0183.TalkerID = _T("EC");
            
            if (g_bXTEFactor) {
                static time_t TimerNewLeg;
                if (m_bArrival) TimerNewLeg = time(0);
                if ((time(0) - TimerNewLeg) > 30)
                    CurrentXTEToActivePoint *= gXTEMultiplicator;
            }

As you may see I add the factor a certain time after the change to a new route leg. That is to not oversteer the AP when a new navigation is accepted.
And, no, I don't think many others would be interested in this. Most have never APs I suppose.
Håkan

[Hakan]

Originally Posted by rgleason

So does OpenCPN currently use the rudder indicator and a feedback loop too or is this for some future version?
......

Rick.. The APs are doing this very well and we, O, don't need to interact in the steering. We would stick to tell the AP where we want to go, = course to steer, how we're doing it, = XTE and if it's important to be aggressive or more calm. The latter is when you set the regulation mode on the AP.

If Sean is designing a new own AP then it's another thing, but not for OCPN core.

Håkan

[seandepagnier]

Originally Posted by bdbcat

Sean...

It may help to back up a bit, and define the goal of the "new" A/P when following a route.

The commercial A/P logic says:
"Q: What is the goal? A: Follow the route as closely as possible".
"Q: What is the best available error signal, (preferably linear)? A: XTE"

So, build a simple control loop using this error signal.

What is the primary goal for your "new" A/P?

Dave

Consider this logic instead:
"Q: Where should I be in 20 minutes? A: As far along the route as possible at this speed."
"Q: What is the course to steer? A: The course that takes us to that calculated position."

This is simplified.

This would work better because there is no "arrival radius" or "abrupt change of course"

The error is more continuous because it is always optimizing the best path to make it furthest along. The main tuning parameter would be the "20 minutes" which you might adjust to various time constants along the route.

[transmitterdan]

Sean,

You are thinking of an optimum course to steer (CTS) algorithm. This is another valid AP algorithm. I think it is only available for high end racing. But such a mode has little in common with navigating a series of route legs. About the only thing in common is the end point of the leg. An optimal CTS requires lots of inputs such as boat polars, true wind vector and true current vector. Such an AP feature in open source would be welcome for racers and cruisers I should think. There are text books on estimating the optimal CTS.

I think "most" cruisers who wish to auto pilot against a list of route segments are desirous to stay "close" to each leg's track. That's because they most likely want to avoid obstacles either naturally occurring or man made. Else why have multiple legs at all? Just steer for the last waypooint and go. The technical term for an allowable XTE is called a dead band. So long as the XTE is less than the max allowed the AP assumes the XTE is zero (dead band). A more sophisticated algorithm is to turn down the gain of the PID coefficients when XTE is less than the minumim and hopefully reducing rudder activity but still gently steering toward the leg end point.

[transmitterdan]

It is a never ending debate about automatically advancing the waypoint when near the end of a route leg. I suspect commercial APs for recreational markets do not auto advance the waypoint on advice of corporate attorneys. I believe this advice is "bad" but it may get them off the hook for liability in collisions resulting from inattentive pilotage. One valid risk is that a sudden turn may result in a collision with an overtaking boat.

[rgleason]

Originally Posted by Hakan

I change the routeman's XTE value before transferred to the AP:
In routeman.cpp (In my personal branch only.)

bool Routeman::UpdateAutopilot()
{
    //Send all known Autopilot messages upstream
    
    //RMB
        {

            m_NMEA0183.TalkerID = _T("EC");
            
            if (g_bXTEFactor) {
                static time_t TimerNewLeg;
                if (m_bArrival) TimerNewLeg = time(0);
                if ((time(0) - TimerNewLeg) > 30)
                    CurrentXTEToActivePoint *= gXTEMultiplicator;
            }

Håkan

Could this or something similar be done with NmeaConverter? Perhaps we could add it as an example in that documentation?

[seandepagnier]

Originally Posted by transmitterdan

Sean,

You are thinking of an optimum course to steer (CTS) algorithm. This is another valid AP algorithm. I think it is only available for high end racing. But such a mode has little in common with navigating a series of route legs. About the only thing in common is the end point of the leg. An optimal CTS requires lots of inputs such as boat polars, true wind vector and true current vector. Such an AP feature in open source would be welcome for racers and cruisers I should think. There are text books on estimating the optimal CTS.

We can use weather routing to generate the optimum course to steer route. This could be continuous while sailing, to update the route.

I think "most" cruisers who wish to auto pilot against a list of route segments are desirous to stay "close" to each leg's track. That's because they most likely want to avoid obstacles either naturally occurring or man made. Else why have multiple legs at all? Just steer for the last waypooint and go. The technical term for an allowable XTE is called a dead band.

This is not what I described. My algorithm will stay very close to the route in most cases. If it is knocked off course, it will go back on course more efficiently. I have a time constant. It could be a distance constant instead.

There are not discontinuities at waypoints, and the turn radius _and_ track error constant is set by the same time constant.

This eliminates the extra xte loop which degrades performance anyway. Extra loops are bad. they slow the autopilot down, or make it work harder, or require extra tuning all the time.

So long as the XTE is less than the max allowed the AP assumes the XTE is zero (dead band). A more sophisticated algorithm is to turn down the gain of the PID coefficients when XTE is less than the minumim and hopefully reducing rudder activity but still gently steering toward the leg end point.

I want to make a clear point that the PID filter is sub-optimal for boat autopilots. Especially wind powered, and especially with significant wave motions.

You are proving my point by describing more complications needed because of them. I have added additional non-linear gains to improve performance, but this is really just a hack. The stable/unstable nature of sailing is non-linear and not correctly modeled by a PID filter.

So while gains can be set that make the autopilot work in all cases, it will not be efficient. The most efficient (least power consumption) gains in other cases, will not steer correctly in other cases.

I intend to use a neural network instead to steer the boat. This is difficult to implement, but if done correctly, would be much better than any PID filter, even if it was magically self tuning.

[seandepagnier]

Originally Posted by transmitterdan

It is a never ending debate about automatically advancing the waypoint when near the end of a route leg. I suspect commercial APs for recreational markets do not auto advance the waypoint on advice of corporate attorneys. I believe this advice is "bad" but it may get them off the hook for liability in collisions resulting from inattentive pilotage. One valid risk is that a sudden turn may result in a collision with an overtaking boat.

We seek to maximize the freedom of the user, so we should implement this as an optional feature to be enabled or disabled.

[rgleason]

TDan wrote:

You are thinking of an optimum course to steer (CTS) algorithm. This is another valid AP algorithm. I think it is only available for high end racing. But such a mode has little in common with navigating a series of route legs. About the only thing in common is the end point of the leg. An optimal CTS requires lots of inputs such as boat polars, true wind vector and true current vector. Such an AP feature in open source would be welcome for racers and cruisers I should think. There are text books on estimating the optimal CTS.

For this we also have an excellent plugin by Thomas Rausch [Tom_BigSpeedy] called Tactics_pi with some great documentation. Which is all about getting the most speed out of your boat to a certain point.

The technical term for an allowable XTE is called a dead band. So long as the XTE is less than the max allowed the AP assumes the XTE is zero (dead band). A more sophisticated algorithm is to turn down the gain of the PID coefficients when XTE is less than the minumim and hopefully reducing rudder activity but still gently steering toward the leg end point.

Some very interesting discussion in this thread. What is a PID? This is about along the track.

For O determining when to turn, as designed by Bdbcat there are other parameters such as "normal range" and in the end before turning in certain conditions when the range is now increasing, a 2 second wait before turning.

[rgleason]

Sean,
It appears to me that the Commercial A/P Dave described uses XTE by iteration to adjust for outside forces such as Wind and Current, in order to keep the boat on track.

How would you describe the way your 20 minute time constant works in that respect? What are the inputs and calcs being done?

[transmitterdan]

Rick,
PID stands for proportional, integral, derivative feedback system. This is a standard type of servo feedback loop used by most autopilots as well as millions of control products. The most visible PID loop is an automobile cruise control.

[transmitterdan]

XTE is normally not used for iteration. The amount of XTE is the error input to a feedback loop. The output of that is the desired magnetic heading. Then the AP has another feedback loop that drives the rudder proportional to the amount of magnetic heading error. This loop is often nonlinear because rudder reaction is not linearly proportional to rudder angle.