Autopilot Control

[Paul Elliott]

And then some systems also have dynamic inputs (pitch, roll, yaw, heave, etc) that come from accelerometers. These are used to create feed-forward or derivative inputs to the control system, usually as part of a learning process that compensates for the effect of seas on the boat heading. I wish I knew more about how this is done.

[seandepagnier]

Originally Posted by Paul Elliott

And then some systems also have dynamic inputs (pitch, roll, yaw, heave, etc) that come from accelerometers. These are used to create feed-forward or derivative inputs to the control system, usually as part of a learning process that compensates for the effect of seas on the boat heading. I wish I knew more about how this is done.

I have heave sway and surge available as well as pitch roll and rates... but I haven't incorporated them... Initial efforts didn't have much success. pypilot is a free autopilot, so it is easy for anyone to change the motor drive equation.

My feed-forward gain is based on changing heading commands which works well.


I wanted to discuss improvements to opencpn for all autopilots.

I think the most obvious improvement is an alternative route/waypoint algorithm that commands bearing directly rather than XTE. I described the logic above.

[rgleason]

My feed-forward gain is based on changing heading commands which works well.

So your input is what? Some averaged heading over some shorter time period (less than 20 minutes, say 1 minute) - the ideal heading 20 minutes away?

I think the most obvious improvement is an alternative route/waypoint algorithm that commands bearing directly rather than XTE. I described the logic above.

Sean, why not? I saw your pypilot video and I think the control works nicely and does not waste much energy. It would be interesting to see it's approach when the seas get more wild, but it looked pretty solid to me.

Users could have a choice of which one to use. I don't think it would hurt and who knows, users might find they preferred your heading approach.

This reminds me of the SweepPlot Speed Histograms Position Determined Speed PDS finds the speed of the vessel by comparing current position to the position from the past. For example PDS10 (10 seconds) takes the position 10 seconds before and determines the vessel speed by taking the distance from where it was then.

[transmitterdan]

Originally Posted by Paul Elliott

And then some systems also have dynamic inputs (pitch, roll, yaw, heave, etc) that come from accelerometers. These are used to create feed-forward or derivative inputs to the control system, usually as part of a learning process that compensates for the effect of seas on the boat heading. I wish I knew more about how this is done.

Accelerometers produce an output proportional to the rate of change in velocity. By the process of integration of the acceleration vector and last known speed vector a new position and speed vector (which necessarily includes course) can be quickly computed. Thus a new course can be nearly instantly computed rather than waiting for a flux gate to swing to a new heading. The magnitude of the acceleration tells something about the forces being applied (F=MA) and thus can guide the right algorithm to make rapid but usually smaller steering changes in the face of forces trying to turn the ship away from the desired course. This is how a real helms person does it without really thinking. Based on the direction and size of the waves they know what is happening to the heading and before it has fully changed they can turn the wheel to counteract. if they turn the wheel soon enough it takes less rudder to hold the course. The longer they wait the more rudder is needed to get back on course and the more energy wasted.

[transmitterdan]

Originally Posted by boat_alexandra

I wanted to discuss improvements to opencpn for all autopilots.

I think the most obvious improvement is an alternative route/waypoint algorithm that commands bearing directly rather than XTE. I described the logic above.

Doesn't OpenCPN give bearing to waypoint along with XTE? It would seem the bearing is what you are after. I though BTW was part of a standard NMEA message to the AP?

[Paul Elliott]

Originally Posted by transmitterdan

Accelerometers produce an output proportional to the rate of change in velocity. By the process of integration of the acceleration vector and last known speed vector a new position and speed vector (which necessarily includes course) can be quickly computed. Thus a new course can be nearly instantly computed rather than waiting for a flux gate to swing to a new heading. The magnitude of the acceleration tells something about the forces being applied (F=MA) and thus can guide the right algorithm to make rapid but usually smaller steering changes in the face of forces trying to turn the ship away from the desired course. This is how a real helms person does it without really thinking. Based on the direction and size of the waves they know what is happening to the heading and before it has fully changed they can turn the wheel to counteract. if they turn the wheel soon enough it takes less rudder to hold the course. The longer they wait the more rudder is needed to get back on course and the more energy wasted.

I actually do understand it as far as you have described it. What I don't understand is how the system "learns" the boat's native response to the sea state. When I am at the helm in following seas, I feel the stern start to rise, I feel the pressure on the wheel change, and the heel angle changes. In addition to all that, how the boat responds depends on which sails I have up and how they are trimmed. It takes trial and error and time and experience to steer well. As you pointed out, you can't wait until the boat is off course or on the way to a broach. It takes early reaction to these stimuli, long before the heading changes significantly. If you wait for that, it's often too late (especially with a symmetrical spinnaker flying).

The autopilot gets these same inputs (except probably not the helm pressure, which can be a very important clue), and that's got to be a pretty complicated algorithm to make good sense of it all. How does it learn?

BTW, this is why high-end autopilots have tightly-coupled accelerometers and fluxgates. Typical NMEA update rates are way too slow for this type of control loop.

[seandepagnier]

Originally Posted by transmitterdan

Accelerometers produce an output proportional to the rate of change in velocity. By the process of integration of the acceleration vector and last known speed vector a new position and speed vector (which necessarily includes course) can be quickly computed. Thus a new course can be nearly instantly computed rather than waiting for a flux gate to swing to a new heading.

No one uses Flux gate anymore.

magneto resistors don't swing and have fast bandwidth (up to 500hz or more) I am sampling mine at only 100hz, and averaging to 10hz.

I will begin trials with a 20hz autopilot to compare.

The autopilot basically steers off gyro which is compensated for integration drift from the compass and accelerometers by the kalman filter. The gyro has the best signal for the autopilot to use.

The magnitude of the acceleration tells something about the forces being applied (F=MA) and thus can guide the right algorithm to make rapid but usually smaller steering changes in the face of forces trying to turn the ship away from the desired course. This is how a

The accelerometers could be used in conjunction with gps and compass to produce a reasonably good autopilot... but it's much better with gyroscopes. Maybe this method could be used to compensate non-linearity from the gyroscope and calibrate them better over time.

With waves, the accelerometers could help more. I tried some basic tests with pid filters, and didn't find much improvement sailing off shore. The gains would have to be completely changed for each condition, and also the dynamics are probably very different for a faster boat.


It could be interesting to use the intertial sensors to greatly improve the gps position, as well as remove lag from gps position... but this doesn't help the autopilot much.

real helms person does it without really thinking. Based on the direction and size of the waves they know what is happening to the heading and before it has fully changed they can turn the wheel to counteract. if they turn the wheel soon enough it takes less rudder to hold the course. The longer they wait the more rudder is needed to get back on course and the more energy wasted.

This is typically true, although it still depends. If the boat will return to course naturally by the forces on the sails, it can save power to correct less.. or to not move at all.

Correcting too much will consume more power, and can even be unstable. The optimal steering varies, and can't actually be achieved by a PID filter if there are waves.

[seandepagnier]

Originally Posted by transmitterdan

Doesn't OpenCPN give bearing to waypoint along with XTE? It would seem the bearing is what you are after. I though BTW was part of a standard NMEA message to the AP?

It gives the bearing of the route segment which never changes. This requires using nested control loops which means extra tuning parameters that the user typically does not tune, so sub-optimal performance. Even if the loops could be perfectly tuned somehow, it is not a good way to implement route following logic. Consider this:


You have a route that goes N to the first waypoint, then NW to the next waypoint.
You are nearly at the first waypoint and you are heading exactly N, but have a cross track error as you are slightly too far to the W.

The current logic with XTE would "correct" you by turning E just before you hit the waypoint. Now you are aiming NNE, and the goal is _suddenly_ NW. Now you are going to have a big cross track error as you cross over the route and head NNE, N, NNW, NW, WNW, and finally NW (if no more gusts of wind cause any more problems) but you did sail close to the waypoint.

When all you really needed to do was hold course a bit longer, and then turn to port.


To put it another way:

The current logic tries to get the boat as close to the waypoint as possible until you are within the arrival radius.

My concept tries to keep the boat as close to the route line as possible regardless of the waypoints.

Smaller time constants keep the boat closer to the route with less cutting corners. A 20 minute time constant is huge for channels, I think 20 seconds or less would work.

If the constant is less than the maneuverability of the boat, it could overshoot. It does this now if the arrival radius is too small, I think it can even "miss" waypoints which would not be an issue anymore.

[transmitterdan]

Then there may be a bug in OpenCPN. The BTW should the computed from the current own ship position. At least that is my opinion.

[transmitterdan]

Sean,

I had a quick look at the code. It appears that OpenCPN computes the bearing and range to waypoint from the real time boat position. Bearing is in "CurrentBrgToActivePoint" which should be sent to the AP. So if you are not seeing a change in this value at your AP something is not right. If you confirm the constant bearing I can have a look at why it isn't working.

[seandepagnier]

Originally Posted by transmitterdan

Sean,

I had a quick look at the code. It appears that OpenCPN computes the bearing and range to waypoint from the real time boat position. Bearing is in "CurrentBrgToActivePoint" which should be sent to the AP. So if you are not seeing a change in this value at your AP something is not right. If you confirm the constant bearing I can have a look at why it isn't working.

I was using the wrong field for bearing (the first of 3) from the apb message. I changed that in my autopilot so this should help, but it still doesn't change my opinion that the current system of waypoints, with "arrival radius" is sub-optimal and a simpler alternative makes more logical sense.

I also notice from the code, that it is using mercator transforms to calculate the bearings which is technically incorrect. It would probably not be noticed unless very long route legs, or extreme latitudes, but it should probably be changed.

There are also a lot of redundant calculations and excess nmea traffic because only one message is actually needed, not all 4, and unfortunately that message has a lot of useless fields.

[Paul Elliott]

Originally Posted by boat_alexandra

No one uses Flux gate anymore.

Of course they do. These days autopilots use fluxgate or GPS compasses for heading information. They don't use fluxgates as the sole input anymore (at least not the high-end APs) but in the new units a three-axis fluxgate magnetometer is combined with multi-axis accelerometers / gyro sensors.

[Clarification: I am lumping Hall-effect fluxgates and magneto resistor sensors together in the same category. However, they aren't exactly the same.]

[Douwe Fokkema]

When setting my Raymarine pilot (Evolution) to steer to a waypoint it will at first take the BTW as heading. In case of a leeway or cross current, it will build up a XTE for about 1 - 2 minutes. After that it will start to correct its heading, first to get the XTE to around 0 and after that to keep the XTE at about 0. This is very irritating, the ship might get up to 20 degrees off course before it all settles down. A considerable improvement could be made by not sending the real BTW to the autopilot, but cheat the pilot with a fake one that is still labeled BTW but is the heading to steer to get a COG that is equal to the real BTW. This Course To Steer could be calculated in O from COG, SOG and heading.

I am not so much worried about the behavior around the waypoints, for safety human attention is required here anyway.

Douwe Fokkema

[transmitterdan]

I think some “new” autopilots are not as good as the “old” ones. My old Raymarine does pretty much exactly what i would do. It makes the turns right and gets on course quickly without overshoot or S tracks.

[seandepagnier]

I have been researching this problem and it appears there is more to this, as there are many use cases:


Interesting reading:

https://www.panbo.com/archives/2011/...s_dollars.html


Suggest to keep the current logic in place (so as not to break anyone) but add new optional configurable logic (like adding opengl support)

If we do have an XTE PID loop (one option of several which is not always the best), it should be calculated from within OpenCPN, not the autopilot. This is because routes and cross track error, or navigation within boundaries, and avoiding obstacles, are all chart issues. This would allow for much better tuning and control of how opencpn commands the autopilot to follow routes.

The nmea sentences are a mess because they contain references to gps positions, route names, cross track errors etc... none of which the autopilot needs to know about. The autopilot doesn't have the chart information which is critical to making the best decisions.

The autopilot is meant to steer to a course. I have no intention to allow it to "read" charts to avoid obstacles. My autopilot reacts not just to the bearing, but the rate that you change the bearing. For this reason, you can put the XTE loop (or any other algorithm) outside of the autopilot and there is no disadvantage.