homemade autopilot

Understood. Although this will be the first autopilot I will design, I've got several tens of thousands of miles experience using them. In addition to set caused by the wind, there's also current, etc. to think about. I'll eventually have to factor all this in and go the route you suggested, but for now it's all a bit over my head... that is, unless you happen to have a Vbasic autopilot app laying around?

 

There are a few Open-source autopilots around. Notably, YBWOpenPilot. This has nothing to do with my OpenPilot project, but may be worth looking into. You might also want to consider my OP work as a starting point (C++ & QT4). I have recently picked up a VIA EPIA 5000 board, so at some point I will be developing a chart plotter using that, however, OP should run on pretty much anything that supports QT4.

I would suggest a simple heading-hold system would be a good starting point.

Best of luck,

Tim B.

 

Thanks for your input Tim, that's exactly what I plan on doing.

 

Bigkahuna: I might be able to help you in what you need. A simple way of correcting for xte is to calculate the amount of xte, is the xte error increasing or decreasing, and what side of the line do we have the error.

The side of the line is to work out if we should rudder left or right to fix the error.

The amount of error determines how much we should change the angle of rudder.

Is the xte increasing (getting worse) or decreasing (getting better), if its getting worse we need to feed in more rudder angle change to quickly correct it. If its decreasing we need to stop inputting change, or even take some off.

So basically what i'm trying to say is, you use your amount of xte to change your rudder angle and you use the rate of change of xte to control the gain of how much you change the rate of rudder angle corrections. IE if your xte is increasing you want to put in bigger adjustments to get the boat heading back onto track quicker, also if the xte is falling just as fast, you will want to block or lessen the rudder angle change inputs as to prevent hunting and make the track of the boat back onto its intended track smoother.

Notice i haven't used a sensor to measure rudder angle, i don't care what angle the rudder is on, i only care about the effect it has on the boat. This means with a single error that comes from your GPS/chartplotter in the form of a XTE you can compsensate for wind and tide drift, as well as course change in the chartplotter when it changes over from one nav point to another.

Hope this helps.

 

I think what I will do for the first iteration will be similar to how the tiller pilot on my last sailboat worked:

1. I will use a 3 axis, tilt compensated compass to determine the boat's current heading.

2. Desired rudder angle will be determined by number of degrees boat's heading differs from desired heading times some variable up to a preset maximum angle.

3. The servo I will be using will give me rudder angle.

4. The desired heading to steer will come from the GPS + charting program.

5. When the boat comes within "x" meters of a waypoint, the system will drop the old waypoint and then calculate based on the next waypoint.

I'm pretty clear on how to do numbers 1 through 3. I have an idea how I'll do number 4, I believe this can be had from a simple NMEA sentence. I'm not sure about number 5 yet, whether it's something included in charting apps or GPS's. The GPS I have at the moment doesn't include support for waypoints or tracks, so it'll either have to come from the charting software or I will have to calculate it separately.

 

What you described here is the PID controller. The heading error (the P term), the increasing/decreasing the angle for the rudder angle is the D term, an the I term is the rate of change described in your last paragraph.

Let me know if you need any help, designing and writing control systems for vessels (big and small) is what I do for a living.

 

OpenPilot could be extended to handle 4 & 5 quite easily. However, I cannot do it due to time constraints. Feel free to download the source and have a play. It requires the latest GDAL libraries (for S-57 charts and grib only) and QT4.

Cheers,

Tim B.

 

Thanks Tim. One of the things I did before posting here was to look at your project and to be honest it's way over my head. I will probably do something really simple in Vbasic that reads the NMEA stream and then sends simple ASCII control code to a serial servo controller.

I also considered using ArduPilot, similar to what Harald Molle did here: http://www.diydrones.com/profiles/blogs/ardupilot-goes-into-the-water.

He's already posted a fairly complete solution, but I would rather drive everything directly from my netbook instead.

 

Ah, sorry to hear that. OpenPilot is written in a very modular manner, so it should be a case of "plugging" the bits together. For this you need to understand how QT4's signals and slots work. There are some very good sources for this (not least the QT4 documentation). The presentations in the source-tree should give you a good idea of how it goes together. Looking at the bits in isolation could be quite confusing.

Tim B.

 

Good idea. You'd want a heading-command loop as the basic function of the autopilot. An inner heading rate loop would be a good idea, too, to give you better damping and bandwidth.

Then you can wrap other loops around your heading loop to navigate waypoints, etc. A change of heading corresponds to the rate of change of cross-track error, so a heading loop has the effect of adding damping to your waypoint tracking.

When you do get to waypoint tracking, don't just use a heading command that is proportional to cross-track error. Instead, think of a greyhound running after the mechanical bunny on a race track. You want to have a virtual bunny that is a fixed amount of time ahead of the boat on the desired track, and continuously aim the heading for that point. The shorter the time interval, the higher the effective waypoint tracking gain will be, with the attendant issues of over-controlling, etc., if the time is too short. If the time is too large, you'll have sluggish response.

Chasing after the virtual rabbit is especially useful for large cross-track errors. A pure proportional system can get into the situation where it just circles continuously if it doesn't intercept the path right away. It only knows to turn if there is an error, and as long as the error persists, it keeps turning. So if the boat is more than the turning diameter from the track, it's hosed.

With the virtual rabbit approach, if the boat is a long way from the track, the along-track lead of the rabbit is negligible and the boat will come in at 90 degrees to the track from a along way out. As it gets close, the lead becomes apparent, and it makes a nice exponential capture of the track, with no need to have a separate mode for capture vs tracking. You also don't need turning circles for turn-short waypoint sequencing because you can just switch to the new waypoint and the transient response of tracking the virtual rabbit does it all for you.

The waypoints themselves are always the eternal trilogy of past, current, and next. When the boat passes (fly-over waypoint) or approaches (turn-short waypoint), the current waypoint becomes the past, the old next waypoint becomes the current, and a new next waypoint is fetched from the planned route. If the boat passes directly over a waypoint before it sequences, then there will be overshoot when progressing to the next. The turn-short waypoints avoid this by turning early so as to straighten out on the new course.

Spend a lot of time working out how to detect failures in the equipment. This accounts for the majority of the software in a safe and available control system. If you don't have physical redundancy, you can still take advantage of analytical redundancy. For example, rates can be integrated to get angles and angles can be differentiated (or filtered) to get rates. So if you have both heading and a rate gyro, for example, you have redundant information that can be used to detect when one of the sensors has gone bad. You may not be able to isolate it to the specific piece of hardware, but at least you'll know to stop using suspect information and get human assistance.

Bad sensors can be especially invidious because they can really drive the system into la-la land. Communication errors you can detect with parity bits, checksums and wrap-around words. Actuators can be compared with models of their response to commands to see if they are working as intended. Computers tend to work or not work at all. But unless you have either physical or analytical redundancy, you don't know if a sensor is lying to you or not. Sensors are getting cheaper and lighter all the time, so physical redundancy is more and more attractive. Parity checks can both detect problems and isolate them to the right hardware.

 

Thanks Tom, you've given me quite a lot to think about.

 

I am joining late to this discussion. I programmed an AP years ago (VB6); it works very well but I am still not done! My approach was to convert the rudder readout into digital data and to process those data along with compass course and rate of turn, both NMEA 183, 10 readings/second. The rudder actuator is then controlled by two digital ports.
Another approach is to use an analog sine/cosine output of a compass and cross link it directly to the rudder follower and the actuator. This requires some good electronic knowledge and (in my opinion) it is a lot more difficult to let the AP "learn" about the environmental conditions such like wind drift, current, waves etc.etc.
The way I choose to go fully digital works for me but I faced problems I was never aware off, such like the unpredictable behavior of timers under windows not to talk about the "preemptive" operating system which does not allow to set task priorities. To overcome this problem I am using Labjack's U3 analog / digital processor board to collect data streams, average them and feed the processing software. Bottom line: good programming knowledge is not sufficient, good electronic skills are needed as well. If you write your software don't run just one .exe file! Split into two applications, data acquisition and data processing. Else you may find your rudder all over sudden "hard over" because your trigger signal to stop the actuator was delayed or the actuator can't find rudder mid ship. As usual in software development: 10% functionality coding and 90% control and safety algorithms.
Ulrich

 

Interesting post Ulrich, especially your advice on separating the application into different pieces. In my case I plan on using a heavy duty RC servo such as this one:

http://www.servocity.com/html/hs-805bb_mega_power.html

Which is like combining the rudder sensor and drive motors into one, thus simplifying the hardware side substantially.

 

bigkahuna:
sorry, I may have missed something. I am talking about an autopilot to steer a displacement hull vessel of 80t where hydraulic actuators are needed. For a small craft an electric actuator might work well to position the rudder provided it can deliver the torque continuously i.e. 100% duty cycle. The servo you are pointing to stalls at a torque of about 25KG.cm so what is the application you have in mind?

 

Ulrich,

Whether you need to split up the software or not depends on where the feedback loop in your control system resides. In bigkahuna's case that feedback loop is in hardware, so there is no issue. If you bring the feedback loop into software, then there may be cause to run the "Servo" algorithm in a separate thread or even program.

Bigkahuna:
Can you give any dimensions for this vessel? Particularly on rudder geometry, stock location and operating speed? For any significant size of vessel I'd be surprised if an RC servo would be sufficient. Some of the linear servos they have look quite good, though. There are a lot of industrial linear servos which you can pick up for pretty much any task you need.

Cheers,

Tim B.