Sailboat Autopilot - Control Strategy

Does anyone have any ideas for a control strategy for a sailboat autopilot ?

I have a 28X interfaced to a GPS and can download the yachts track every few seconds (thanks Hippy and others on forum for parsing help). The output system is a reversible DC motor which via a mechanical reduction drives a ballscrew that moves the rudder. If power is applied the rudder moves and stays in that position until the next time the motor is energised. This drive system works well and earlier this year I fixed the mechanical and drive bugs.

The control strategy tried so far is to compute the error between desired and actual track, to multiply this error by a gain factor to give a correction time and then to actuate the drive motor in the correct sense for this time. The cycle is then repeated. The result is a gradually increasing series of oscillations (about the desired heading) and there appears to be no gain factor that will provide stability and control even in calm motoring conditions where little correction should be needed.

Next I tried modifying the correction time by adding a term proportional to how much the error had changed since the last read but this strategy has not helped either. Does anyone have any ideas on how to approach the problem ? I think I will have to incorporate some data logging system to allow proper analysis but still need to come up with a workable control method

Dennis

 

Sounds like you have the Proportional and the Derivative covered and, as you suggested, "data logging" should provide the necesary Integral term for control loop stability.

For example check out the discussion here:

<A href='http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=2455&amp;forum_id=15&amp;Topic_Title=PID%2BController%2Bin%2Ba%2BPICAXE%253F&amp;forum_title=No+new+posts+please%21+9
' Target=_Blank>External Web Link</a>

If it is necesary to increase bandwidth try adding some external analog processing.




Edited by - wilf_nv on 26/12/2006 22:21:05

If the oscillations are getting bigger, this could indicate the gain factor is far to large. Rather than try to compute the perfect course correction with one big change that possibly over corrects, I wonder if a much smaller change might work.
Eg I'm heading NNE and trying to head N, so turn the rudder L a bit for two seconds then back straight for at least 20 seconds. This will almost certainly under correct the error, but then can work up from this under corrected error, rather than working down from an over corrected high gain situation.
I'm just thinking of my sailing days - frequent changes to the rudder should not be needed and this was the key to winning races, as turning the rudder a lot slowed the boat down.

I didn't quite understand your system, but I think there should be a constant pause between samples, so you've got a constant sampling rate (e.g once every 20 seconds) and just start off by having a low gain factor:

1. Sample target and actual course
2. Calculate Error
3. Apply gain factor to calculate rudder offset
4. Adjust rudder
5. Pause until next sample (which also gives time for the change in rudder position to take effect)
6. Goto 1

You haven't posted any code, but there's also the possibility of integer maths issues (e.g rounding to zero) , especially with low error values.

Edited by - Jeremy Leach on 27/12/2006 00:49:30

This is a classic PID problem.
The oscillations are certainly caused by having the gain too high. A lower gain will leave you slightly off course which is where the integral part comes in. Having the derivative term will help to eliminate sudden changes caused by gusts but is of far more use in damping down over corrections.
It will be very difficult to try to to explain this with just text but a google for PID should show enough to give you the general idea. If not, come back and I'll try to explain in more detail.
It might also be worth considering doing the error correction as vectors but this could lead to problems with the limited PICAXE maths ability.

First let me say thank you to all who responded, it has encouraged me to keep on trying. Actually even if I can't make it work the learning has given me a great deal of pleasure anyway.

I realise I failed to describe the system properly, in my first message but my first attempt works more or less exactly as surmised by Jeremy. After a correction there is a constant wait time (typically 10 seconds) and then 5 track angles are downloaded in quick succession which are then averaged and compared to the set point to generate the error. Actually I calculate the size of the error in tenths of a degree and also the sense of the error (ie left or right of desired track). Calculating the sense is not quite as simple as first appears due to the 360 degree system) Fortunately the GPS has a simulation mode (for training, in which a course and speed can be input, so with a home based set up I have tried various course deviations and made sure the correction is in the right direction.

The comment from Dr_Acula about making a rudder correction and then returning to the straight on position made me think.
After the initial problems I found details of a home made PIC based system used for model aircraft. Basically the aircraft would follow a series of GPS waypoints until it came under radio control range. This system simply actuated a rudder servo for a time proportional to the course error and worked well. From my understanding of servos when de energised they simply offer no resistance so after the correction the rudder would return to straight and the plane would fly on in a straight line on a new course that would not change until the next correction.

This is not the case with my system since once the rudder has been moved it stays locked in that position until the next correction. In my case a correction sets up a turning rate (ie a number of degrees per minute) that is maintained until the rudder position is changed again (BeanieBots - is this an integral or proportional term ?). I fear that this is the basic cause of the instability experienced with my system irrespective of gain size or waiting time between corrections. I explored a wide variety of combinations of wait time and gain and although the frequency of the swings can be altered the amplitude gets bigger and bigger. I think that is because any time an error exists more and more rudder is applied as the yacht returns towards the desired course, the increment added gets smaller but each correction is piled on top of the previous one so that the yacht is bound to overshoot the desired course. To try and deal with this I attempted to introduce a term which looks at the difference between the current error and the error last time round and if the error is decreasing a correction in the opposite sense is applied. (BeanieBots is this an example of a derivate term ?). This did not work but I have only explored a limited matrix of wait time, error gain and error difference gain. So to continue some data logging system is probably needed. Dr_Aculas idea to apply a correction wait a few seconds and then remove it is interesting but probably not the whole solution since the straight on position of the rudder varies a lot depending on wind strength (the pressure on the sails and the angle of heel tend to steer the yacht).

I will follow up with another session with Google since so far I have not really been able to get to grips with PID control.

Best Regards
Dennis

 

Dennis, the way your rudder works means that you are applying an integral term and then integrating again. This will always be inherently unstable. Adding in the bit which is a function of the difference between current and previous error is indeed a derivative term, but again, the rudder action integrates this into a proportional term. Unfortunatley, integrating a derivative term (which in theory gives proportional) tends to suffer from accumulated errors and is not a good idea in practice.
Things would be much easier if you had a way of setting the rudder to a known position rather than just increasing or decreasing the angle. You could then apply an amount of added absolute angle proprtional to the error plus an accumulated amount of angle over time which will apply the angle required to go in a straight line for any given wind strength (the integral term). Adding the extra derivative term (based on difference between previous errors) will damp out any overshoot.
It sounds like you have almost created a PID controller but it is the way the rudder movement control works that is actually applying further integration to the output of your &quot;PID&quot; signal.
If you were to use a &quot;standard&quot; servo, then I think you are almost there.
By the way, a servo does 'relax' when not activated, but the gearboxes are very high ratio and it is unlikely that the forces applied would return it to the neutral position. It may go back a little at very high speeds but not all the way.

Your understanding of PID is sound. Stick with it.

Commercial sailing boat autopilots use a fluxgate compass as the primary input. At least, the ones I am familiar with work that way. Could it be that there's too much lag using GPS to supply the heading data?
The commercial models can connect to GPS but they let the GPS work out the required course, then the autopilot follows the course by the compass, I think.
Good luck,
Derek.

Some of the latest GPS receivers now update at 5Hz, rather than the standard once per second.

The GPS method will be fast enough if it really can produce several readings per second. The bigger concern would be position resolution. GPS cannot produce better than 10m or so resolution. This in itself may well cause 'hunting' if attempts are made to keep within closer limits than several times the resolution.
Whatever the input source, supplying an integrating rudder movement with an integrated error signal is always going to oscillate. One or other of the integration terms will always saturate which results in a time delayed infinite error gain. The worst possible thing for smooth control!

Is there a way of returning the rudder to the centre position? Eg, a reed switch or something that detects that the rudder is totally centred. I'm thinking that if the system is constantly hunting for the perfect course, it may never return to the centre position.
Even with the rudder totally centred the boat may still not go straight but it might be a start.

it would be good to know typically how much effect how much rudder causes - how fast - with a smaller boat I would think you'd need close watch on rotation of the bearing - fluxgate compass as mentioned above perhaps added GPS correction to an 'absolute' value.

In any case it doesn't make sense to keep the rudder turned without knowing what your new heading is and also doesn't make sense to always come back to straight... you might get a better feel for this if you consider what you do _manually_ when accomplishing the same task... watch yourself carefully and enjoy the trip as well...

Thanks to all who replied, there are a lot of leads to follow up and thinking to do. The PID thread started by Hippy has also supplied some useful explantions of PID control that I can understand. BeanieBots explanation makes sense and I understand that I really need to know where the rudder actually is to properly use a PID control. I wonder if I could simply keep track of all the correction times applied, and use this information to deduce a rudder position, although it would rapidly become inaccurate.
In the past I have repaired a few sailboat autopilots and they all appear to use a simple DC motor with no position feedback and I am using one of these motors for my experiments. This suggests that some control strategy should be possible without position feedback, at least to work in non demanding conditions where headings change slowly.
My understanding is the same as Derek's (Cpedw) in that all autopiolots I have seen always have a fluxgate compass and some also have the ability to
interface to the GPS. The question of whether a fluxgate compass is essential has been raised a few times by sailng friends as well as by Derek. I had assumed that a course update from the GPS every few seconds would be good enough for calm conditions but to explore this a friend and I escaped from the festivities and had a couple of 6 hour sails, the first at night motoring in calm conditions. The helmsman was only allowed to see the track on the GPS screen (magnetic compass was covered and looking at surrounding lights or the rudder position not allowed) and attempted to steer by pushing one of a pair of buttons. Each button operated the rudder drive in one direction for as long as it was held down, so the human had the same input data as the Picaxe and the same possibilities to respond. After a bit of practice we found it pretty simple to keep a decent course though the ability to update every 5 seconds made for a much smoother course than with a 30 second wait time. However even with the long wait time we could produce a course that wavered somewhat but was not unstable. We found that when the error was first apparent we applied some rudder movement very approximately proportional to the error but then waited to see if the error decreased and if it did so then did nothing until the error was near zero at which point a little opposite rudder movement was applied. This experiment might be worth repeating with some datalogging so that the human performance and strategy could be better understood. I am not too sure how the GPS produces a track reading every second or so and assume that there must be some damping present, even when the user selected damping is set to zero. The yacht speed was about 2 m/s and given an assumed position accuracy of 10m the GPS accuracy as BeanieBots points out could become a problem. We made the return passage, in much windier conditions using a commercial autopilot and the performance was impressive and impossible for either of us to analyse, the rudder being moved in a continual series of erratic movements some small and some large.
My conclusion is that it is worth continuing to explore control strategies, maybe using some rule based system, and that there is a good chance that the Picaxe system can work in calm conditions.

Dennis

 

Cue Dippy with paragraph comment <img src="wink.gif" width=15 height=15 align=middle> Sorry Dennis, just a little joke ...we find it easier to read if there are some paragraphs ! (it's been said a number of times).

Edited by - Jeremy Leach on 31/12/2006 20:07:29

just an observation: fluxgate compass works when there is failure of GPS for whatever reason and is a relatively cheap device... I'd leave it in the mix - and keep magnets away from it Happy New Year...

Trying to control a rudder with no position feedback is possible in THEORY but in practice it will be almost impossible. The reason is that it still equates to differentiating an integral to determine position. Any error will eventually accumulate. Although this accumulation is taken care of in the arrithmatic, it tends towards infinity after infinite time (or very large after a certain amaount of time).

For those who understand op-amps, consider making a unity gain amplifier from an integrator followed by a differentiator. With zero input, the integrator output (after a power up reset) will be zero and not moving. Hence the differentiator output will be zero. Now, apply an input voltage so that say the integrator starts to increase in voltage at a rate of 1v/sec. The differentiator will detect this voltage rise and if designed properly will faithfully reproduce the voltage that is applied to the integrator. Great, a unity gain amplifier. However, to maintain the differentiator output voltage, the integrator must continue to ramp up in voltage. After about 10 seconds, the integrator will approach its maximum possible output voltage and fail.

This an obvious failing when using op-amps to solve the problem but the same problem exists with all other solutions. The internal calculation numbers simply keep getting bigger and bigger. Thus, works in theory, but not in practice.

There may be some really clever tricks that could be done but I'm sure that fitting position feedback to the rudder would be much easier both to implememt and to understand.

I'm not quite following this - IF rate of change of bearing and rudder postion are related and monotonic you could always correct one way or the other. IF rudder position no longer influences change of bearing and/or rate of bearing change you either have it jammed on the stop or better get away from the whirlpool - just kidding but you get the idea. If the bearing and rudder still are 'coupled' in the direction you need to control it's possible.

premelec, you are quite right (but how?). Assuming a &quot;standard&quot; rudder arragement, it should be monotonic but specialist boats such as tugs are usually not monotonic.

The problem described comes from the limitation of not having position feedback on the rudder. It is suggested that PID should be used for control.
Incremental steps of rudder position would only give the &quot;I&quot; term and will ALWAYS result in oscillation.
Differentiating a PID control output to feed into an integrating control mechanism is possible in THEORY but NOT (in my experience) in practice.
I guess it would be possible to feed the rudder motor with &quot;Proportionl&quot;, &quot;derivative&quot; and &quot;Derivative of derivative&quot; but you're not going to find any readily available texts on how to generate such an algorythm. Hence the suggestion of making life easy and adding rudder position feedback.

I can see the advantage of a fluxgate compass but shrink away from the complexity at present. It's very convenient to use the GPS which is anyway needed for navigation. If the autopilot works then I might investigate adding one later to iprove performance.

Unfortunately to add rudder position feedback will be awkward because the drive consists of a dc motor and several geared reduction stages to a ballscrew ram all mounted in a sealed container. Maybe a stepper motor could be used instead and the pulses counted, though since the motor would only be powered when movement is required it might easily get a few pulses out of step with long term errors. It takes a lot of turns of the motor to go from rudder centred to one extreme of movement so speed of stepping could also be an issue.

I am working on a spreadsheet type simulation to investigate various strategies and hope this might result in something useful, because maybe I can stumble across some suitable method that would be worth a try.

 

I'm not saying this is the solution but with moving things and steppers staying in sync one common solution [e.g. printer carriages ] has been to reset as a particular point is sensed [an optical interrupter in the printer case].

Sometimes an end point can be sensed by a sharp increase in motor drive current [we hit the wall!] with DC motors -

In your case with a stepper it would depend on what access you have to the rudder shaft - you could put a strong magnet on it and use a sealed reed or hall switch to sense that place as it goes by... so many wonderful things to try!

I may be entirely off the mark, but I'd like to offer some input from an operator's perspective.

1. I don't think you need accurate positional feedback for the rudder position, but an approximate &quot;center&quot; sensor might be useful unless you can keep track of offset in software. A &quot;straight back&quot; rudder does NOT equal straight ahead. Sail trim, hull irregularities, prevailing wind and seas will cause heading to drift and a slightly offset rudder may be required to equal zero rate of turn which is what you are really looking for. I believe you want to position your rudder based upon rate-of-turn information, and for straight ahead, you can servo the rudder to approximate center and then make minor servo adjustments to keep the heading steady.

2. Your compass can be useful not only to measure magnetic heading but also to monitor rate of turn. For this purpose, you want rate-of-turn to be deliberate and well-controlled. Gradually input rudder until you establish the desired small rate of turn then, as you approach the new desired heading, return rudder to &quot;approximately centered&quot; and then servo to maintain heading.

3. If I understand your description of the current software correctly, the craft is constantly turning. I would suggest that to make a correction, calculate craft's track and magnetic heading and compare to desired track. Calculate an appropriate correction magnetic heading (drift angle plus desired intercept angle) and turn the craft to that new heading then sail straight ahead for an appropriate time. Remeasure intercept track and correct again as needed. Make fairly small corrections. You should be sailing in a straight line most of the time, not turning.

My experience is in aircraft, but I suppose the principles must be similar.

Hope this is useful.

If rudder position feedback is not an option, then you will have to use the &#8220;proportional&#8221;, &#8220;Derivative&#8221; and &#8220;2nd derivative&#8221; option.
This will produce a value that can be used to pulse the rudder motor.
Each pulse to the rudder motor will be integrated by the mechanics resulting in a conversion to PID.
You MIGHT get away without needing the &#8220;2nd derivative&#8221; but you will not get away without the &#8220;Derivative&#8221;.

For each fixed time period:-
Calculate the error. (E)
Calculate the change in error since the previous calculation. (D)
Calculate the change in (D) since the previous calculation. (G)

E,D and G will need to be scaled accordingly and then summed together. I have absolutely no idea what sort of scaling values will be required but you could use different time values for each term to help keep the scaling values within reasonable constraints. If you do use different times for each, make each time difference an exact multiple of each other and only sum after the final time constant has elapsed.
Eg if G is calculated every T and D is calculated every T/10, then accumulate D until the full T has elapsed.

The resultant value should then be used to create a pulse that is sent to the rudder motor. It should be easy to see that if there is a constant error, pulses will continue to be sent which will keep moving the rudder. This is the integral term.
If the error keeps getting larger, (D) will have a value that gets added to the integrated error. This is the proportional term. If the RATE of change of the RATE of change of the error increases, (G) will also be included in the integrated pulses resulting in the derivative term of rudder position.

As mentioned by premelec, you could detect rudder end stop by sensing motor current. If you are off course but stationary, the integral will continue to wind up trying to get you back but it will never happen and the rudder will eventually hit its end limit.



Edited by - beaniebots on 02/01/2007 10:12:16

BeanieBots your suggestion (E) and (D) are in my second control strategy but I did not explore many combinations. I will add (G) and give this scheme a try. My experience is also that the &quot;Derivative&quot; is needed

For the next trials I plan to have a laptop connected to allow data logging which should help control tuning.

wapo54001 suggestions made me think of an alternative approach in which the rate of turn only is controlled to a target that depends on the track error. In pseudo code it would look like this :-

1. retrieve new track from GPS
2 calculate actual rate of turn = new track &#8211; old track
3 calculate track error = desired track (set point) &#8211; new track
4 calculate target rate of turn = track error x constant &quot;C&quot;(maybe 0,25 or 0,125)
5 send pulse to rudder proportional (constant &quot;K&quot to difference between target and actual turn rates.

My hope is that by reducing the target rate of turn as the desired track is approached that the troublesome overshoot can be avoided. Instinctively (and maybe wrongly!) I think that since the rudder position is closely linked to a given rate of turn that the control, despite the moving target will be easier. Control tuning would be a matter of adjusting K and C.
Does anyone think this scheme is worth a try ?

It's worth a go but you still seem to be missing the point that your rudder mechanism integrates. When you send &quot;pulses&quot; to the motor, they will be integrated (the rudder moves a bit each time).
You will need to differentiate the signal first and then send it as pulses.
That's what I was trying to point out in my previous post.
I think we've thrashed the theory enough now. It's time to try things. Your idea of getting data is a good one. That will give you a good idea of real values and will help with tricky task of scaling things into integer values that can be handled by the PICAXE.
Good luck, and keep us posted on your progress.