Autopilot Control

[Hakan]

And - It's impractical to let the AP circle around a buoy. When you turn at a WP you do one course change i.e. one new navigation for the AP.
To let an AP do a sector-turn you have to send several new "course to steer" and confirm every change on the WP. The same as surrounding the buoy with several WPs. You'll have no time to look around.

[Hakan]

Rick...
re: "2) max xte allowed, or how aggressively to correct for XTE"
I'm not sure I understand when this will be needed. Please explain.
A big XTE is probably caused by wind and/or current leeway. Why not compensate for that?

[seandepagnier]

Originally Posted by DotDun

Commercial APs work hard to maintain a XTE of only a few feet.

You mean they physically work hard and consume a lot of power?
In rough weather with sea room, it's a waste of power.

In light air when the wind arrives in puffs from different directions, it is not easy or desirable.

In real world cruising, automatic turning at a waypoint change to continue the route isn't a highly used feature since in such close quarters the one on watch can handle the turn. Too much automation can be a bad thing.

It can be bad, or good, but it gives the user more freedom to choose if they want automatic or not. It is not for autopilot systems to make these decisions, but up to the user.

The waypoint change could be confirmed in OpenCPN if enabled, otherwise the change should be automatic.

All APs I know offer this feature under their own control interface.

Again, my point is, a generic way to set steering to wind would be nice. This allows other plugins like tactics to integrate properly. Plugins like watchdog or future features could actually change course to avoid collision like ais, or rocks.

Don't bother saying that this is dangerous/impractical. At this point it could be a last resort if the helmsman is not capable. They are already doing it with cars, and that case has much more danger.

Again, too much automation causes more problems than it's worth. The one on watch needs to understand the boat is in shallow water. If the AP raises the centerboard, it won't be very long until the boat in grounded.

The AP knows it can raise the centerboard, then lower it after it passes the shallow water, for example.

You say it makes more problems than it's worth, then you wouldn't have to use these features. Other people would use them.

"GPS" and waypoints are the same thing.

In my autopilot "GPS" mode is a gps course which doesn't require a waypoint.

I seriously doubt the OCPN community will be able to drive features back into commercial APs.

Not at all what I suggest. I am suggesting that we provide more controls to set all autopilots.

Yes, that is normal. A chartplotter can be set to goto a waypoint while the AP remains on standby. An integrated chartplotter and AP controller will ask to confirm engaging the AP when a 'goto' command is entered.

So, we have an extra step for the user. They have to activate the waypoint then engauge the autopilot rather than just one step. I should be able to work around this limitation from my plugin with an enhanced API.

It's much safer to ask the helmsman to confirm rather than allowing the AP to drive the

"safety" or what is claimed to be safe, but isn't, mostly always directly violates freedom.

It is up to the user to decide what is safe, not the autopilot. It is only important that they have the freedom to do what they want to.

boat 'blind'. Most hazards on the water are not on charts, they are other boats which OCPN/AP can't see.

Unless the autopilot has a video and night vision camera, which it will soon, and in this case, the AP driving "blind" will be better than many helmsman (like volvo)

Originally Posted by Hakan

Sean..
I do agree to all DotDun's answers. They are important and more or less exactly my reactions.

I have an ongoing test on my own, dated, AP. That is to in O use a factor multiplying the XTE value sent to the AP. The test was performed since the AP didn't come to the course line but stayed offset more than I like. It works rather good. I can as you see turn it on/off from the consol window. The value is set in boat options.

A multiplier for XTE could be interesting. What value did you use that worked better than 1.0?

The multiplier might need to be higher in tighter waters, and it could be reduced with more space.

AP's produced in the last five years are better then my dated AP. The regulator algorithms are much more efficient to adapt for both a new course and maintain a course line. But they are still reading course to steer only once and then take care of leeway by the XTE.

Mine was working pretty well, and without taking care of leeway at all... the XTE remained constant the whole time, which is why I said opencpn changes waypoints at the wrong time.

And independent if O or a plotter of the same make is setting the course you've to accept a new course for every WP in a route.

So my conclusion is the same as DotDun's: There is not much to develop in what's sent from O to the AP, it works fine.

Yes, and the guy using opencpn 1.3 said it worked fine too.

But if you make your own AP regulator you can maybe do it in another way.
Håkan

I will... but there are some basic issues with all autopilots that can be improved/enhanced.

Originally Posted by rgleason

Hakan I am in the other camp and happen to agree with Sean about navigation around bouys.

He suggests hese two common values:
1) turn radius.
2) max xte allowed, or how aggressively to correct for XTE

Maybe the first thing to do is to get in the boat and test the buoy rounding settings that we have now and report back on the results?

Of course I always put in my own buoy offset by where I place the waypoint, but perhaps there should be a buoy offset value too.

Originally Posted by DotDun

How would OCPN/AP measure turn radius in real time? GPS lags up to a second behind realtime. Currently, ROT measures are crude and not fit for close quarter turns in a channel around a buoy.

There are a few ways to smooth out position, if there is a compass and gyro input.. but I am not talking about a few meters turn radius difference anyway, but larger amounts.

Maybe all we really need is a feature to "smooth" a route, to break it into more segments in this case (based on wind direction as well etc...) This would improve things without forcing the user to click 100 times to make a route.

[transmitterdan]

Sean,

When steering to a waypoint XTE is always used by the AP to generate a desired magnetic heading. The mag heading is computed to bring the boat onto the track as smoothly and quickly as possible. Tracks are often laid out to avoid obstacles. A max XTE could be useful to avoid unnecessary steering but that cannot be a global setting. It would need to be part of the route leg data.

The AP steer to heading function actually drives the boat. So at all times the AP is steering to a magnetic heading, the same is true for wind angle steering. The AP (or AP plugin) calculates the magnetic heading needed to hold the apparent wind at a preset angle. It would be pretty trivial to put all the AP calculations into O except the part about steering to magnetic heading. That needs to be done by the AP. An AP plugin for O could do all the other computations. The workload for the CPU is quite trivial.

So a really useful AP would be one that only steers to a magnetic heading. Said heading provided either by hardware connected to the AP or from messages provided by O. All other AP functionality can be had through a relatively simple O plugin.

[seandepagnier]

Thanks for all the replies and explanations. To summarize, I think the following could improve AP control in OpenCPN in a generic way:

1) adjustable XTE multiplier. Perhaps it can be automatically adjusted depending on how far from the arrival point?
2) possible smoothing of routes to set turn radius by making more segments based on parameters (like obsticles or depending on wind direction). This could be a separate plugin.
3) Much smarter arrival detection...


The arrival "radius" being a circle around the waypoint is not optimal.

It would do better to be an ellipse with the longer axis along the path of the next route segment. The center of this ellipse should not be on the waypoint either, but a bit closer. This introduces a lot more parameters, and even this isn't optimal. We might consider something to do with "crossing" the next segment (if it were extended to infinity) as well.


So, it's working now in flat water with steady wind. With difficult conditions/currents, and limited wind power, it can't steer as accurately, not with the autopilot, or even a human. Sometimes I steer from a very small motor via the pendulum oar rather than the main rudder which has additional lag. Adding extra errors for the autopilot to compensate is not good if we can avoid it by some simple calculations.


I don't think steering from XTE is smart. Correcting for XTE error just before an arrival point, only to turn back the other way for the next waypoint is clearly suboptimal. Consider an alternative mode:

In this mode, opencpn finds the closest point from the boat to the route, then moves forward on the route a certain amount. The autopilot is commanded to steer to this point all the time varying the gps heading as needed.

[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'.

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.

[seandepagnier]

Originally Posted by transmitterdan

Sean,

So a really useful AP would be one that only steers to a magnetic heading. Said heading provided either by hardware connected to the AP or from messages provided by O. All other AP functionality can be had through a relatively simple O plugin.

Except, that steering to wind now:
1) requires opencpn to be running and not ever crash. This uses more power too.
2) ap cannot react as quickly to gusts as having the wind sensors wired directly to it
3) ap is aware of how wind affects sails and what angles. It knows that on broad reach it is more critical to avoid jibe than rounding up. The sailing performance, and wind inputs are part of how the autopilot learns. I don't know how you are going to duplicate this from a plugin in a reasonable way.

[transmitterdan]

A RPi running O is a minuscule power draw.

I agree that the wind sensor interfaced direct to the AP is best. But speed of response to wind isn’t a big issue. Most wind sensors are severely damped anyway.

Avoiding a crash jibe is a worthy goal but difficult to achieve in every case. Good preventer setup is important.

[seandepagnier]

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'.

So yet another setting just for XTE? Or is it the same responsiveness setting for course change?

It makes more sense to command the autopilot directly by heading then by XTE.

The responsiveness setting varies depending on where on the route you are.

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.

By changing the commanded bearing to the AP all the time and not using XTE at all. This gives opencpn much greater control over the autopilot than before.

[bdbcat]

Sean...

In the language of traditional control system engineering:

When following a route, common (commercial, e.g. Raymarine) A/P is running two control loops.

1. Inner loop: Given a compass heading (not a course), call this the HEADING goal. The control loop works to adjust the rudder to maintain that HEADING goal. This loop runs at about 1-2 second time constant, adjustable by "response" setting. Note that this control loop almost exactly emulates a human helmsman steering by compass alone.

2. Outer loop: Strive to minimize XTE by adjusting HEADING goal of the inner loop. The outer loop runs at a slower time constant compared to the inner loop. Seems to be about 2-4 minutes, by simple observation. Heading goal is changed by usually two degrees at a time, allowing some minutes for the effect to be detected, and continually adjusted. Eventually the outer loop goal is satisfied. It has found a HEADING that will hold the XTE to near zero. As conditions change (current, sea state), the outer loop continues to run, tweaking the HEADING goal of the inner loop.

Pilots will recognize this outer loop as exactly what a human does when performing an ILS landing approach.

On common Raymarine based logic, there are three levels of responsiveness, affecting only the inner loop. The highest level uses a gyroscope to measure rate of turn, if available. In the most responsive mode, the heading is maintained very precisely, with lots of rudder action. Very busy, high power consumption. Not really very useful on a sailboat at sea, but great for a powerboat in inland canals.

Hope this helps
Dave

[DotDun]

Originally Posted by boat_alexandra

So yet another setting just for XTE? Or is it the same responsiveness setting for course change?

It makes more sense to command the autopilot directly by heading then by XTE.

The responsiveness setting varies depending on where on the route you are.



By changing the commanded bearing to the AP all the time and not using XTE at all. This gives opencpn much greater control over the autopilot than before.

Commercial APs will require acknowledgment for each BTW change.

[transmitterdan]

Actually there is a third innermost loop on most commercial AP units. This loop is a rudder servo. It strives to hold the rudder at a given angle. That angle is provided by the mag heading control loop Dave mentioned. The mag heading loop produces a desired rudder angle and the innermost loop servos the rudder to this angle. This loop typically has user adjustable damping and gain settings. These settings are what helps improve downwind sailing. So some sophisticated AP algorithms have different rudder gain and damping for various points of sail.

All of these (including XTE loop) are relatively simple PID loops with only 3 variables each. If you get all the loops “tuned” right for your boat it can steer better than 99% of human helms persons.

[seandepagnier]

Originally Posted by bdbcat

Dave..

This really clears things up a lot, thanks.

As it is, my inner loop maintains a compass heading, and an outer loop maintains the gps heading (adjusts compass course to follow the gps course).. so yet another loop to reduce xte.. maybe.

2. Outer loop: Strive to minimize XTE by adjusting HEADING goal of the inner loop. The outer loop runs at a slower time constant compared to the inner loop. Seems to be about 2-4 minutes,

2-4 minutes? This will have serious implications, especially for routes that quickly change.

I was routing around bends in rivers, and 2-4 minutes won't work well.

Pilots will recognize this outer loop as exactly what a human does when performing an ILS landing approach.

It makes sense, but it clearly is not optimal. We could simply adjust the heading goal from opencpn, and leave xte at zero. This would give us more control over the autopilot.

It seems like the whole XTE thing was devised by someone with aircraft training. Adding another loop here, takes away from the performance of the autopilot, especially if we can't tune the XTE time constant, or gains.

Sailboats can naturally correct course in one, both or neither directions depending on the situation. This factor is critical in reducing autopilot power consumption, but completely ignored by these nmea sentences. It is important for OpenCPN to be aware of this as well, because sometimes there is space to sail off course, and other times not.

A boundary with a route in it makes more sense.

On common Raymarine based logic, there are three levels of responsiveness, affecting only the inner loop. The highest level uses a gyroscope to measure rate of turn, if available. In the most responsive mode, the heading is maintained very precisely, with lots of rudder action. Very busy, high power consumption. Not really very useful on a

I can maintain a precise heading within 3 degrees in flat water, but with waves or wind gusts it is basically impossible because my drive motor is too slow.

I tend to want to follow wind gusts as the wind shifts, while maintaining an overall course down the river. I don't know how we can deal with this when following routes.

sailboat at sea, but great for a powerboat in inland canals.

Don't forget sailboats in inland canals. I sailed from norfolk to oriental on the ICW, also breaking ice (which the autopilot also had difficulty)

Hope this helps
Dave

It does help, but I think we should command autopilots directly on bearing as an optional alternative to the current system. I think it would work better, give better performance and control and be simpler to understand and use.

[bdbcat]

TDan...

Thanks for the fill on the rudder servo loop. Forgot about that one, since it "just works". For humans, that is analogous to the tiller force-feedback loop we do naturally.

Dave

[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