homemade autopilot

As admirable as the "let's develop the ultimate" approach is, I have worked on too many projects that have failed because of it. If the goal is to develop an autopilot, I strongly suggest that you start simply, then add functionality as it is required.

Tim B.

 

An autopilot that does what they do now is not a necessary project. One that would be using new technology is likely in the design stage in more than one AP house. We don't need to make hydraulic pumps, solenoid valves, piston or anything like that. Likely there is no room for significant improvement. So really it is simple circuitry with complicated software dealing with input that did not exist in previous models.

The challange is can we take that input and control the boat in a way that is better, hopefully much better than what is available now. Any $60 rabbit board with a few SSR's will handle the I/O. So again, it really is a software project. Can there be real innovation in software design? If there couldn't be, one would not be changing your cell phone, iPod or whatever every year or so. As every good software project starts with a flow diagram, it seems that a written flow diagram with pie in the sky parameters would be a good start. Subsets can come, but starting with a subset is just as likely to fail.

My $.02.

Ted

 

As technology increased, it allowed software developers to come up with better ways with manipulating the data. Like Ted mention, just look at the range of mobile phones and what they can achieve today compared to 5 years ago.

With all projects there should be a research and planing phase, where you develope goals and milestones. For each milestone you map out a parth to achieve each milestone, remembering that each milestone must be achieveable. If the milestone is difficult, break it down into achieable milstones, afterall thats what your doing with the whole project, breaking it down into achievable bites.

Another problem is what we call scope creap, as your developing your project, you think it would be nice to add this feature, and then this feature and so on. It's better to log these new feature as addon's after the original product is working. Its ok to change the design to be able to adapt this new feature down the track if its easy, as they say, fitting for, but not with.

 

Some ideas on a DIY autopilot

I've been thinking about this for a while now, and some projects at work are beginning to have some overlap. I thought I'd share some things I've learned and ideas I've had.

My goal is to build an autopilot for my 24,000 lb sailboat. I've got a wind vane, but it takes too long to setup sometimes, and doesn't like certain points of sail or motoring.

I was able to pick up a Raymarine type2 hydraulic ram and pumpfor a great deal a few years back, and I have it hooked to the rudder shaft. I also have a small linear actuator from an old Autohelm which I will attach to the wind vane. I've heard of people using old outboard rams and non-marine 12v hydraulic pumps. You could probably use the hydraulic helm instead, hooked to a decent gear motor of some sort.

What I lack is the processor, sensors and interface.

To drive the hydraulic pump motor, the best thing I've found is the Roboteq AX1500SC brushed DC motor controller. This motor controller is rated at 40 amps continuous so it should be more than capable of any autopilot motor even under severe duty. It has built in PID control and would require an analog feedback for rudder position. I was going to get some sort of industrial potentiometer off of eBay.
The controller can be commanded several ways, but I was going to use its serial interface. You would send it a desired rudder position, and it moves the rudder there based on how you have the PID tuned.

For sensor inputs, I was going to use the OS4000 digital compass. This tiny device gives heading, pitch, roll, and acceleration in 3 axes. It does this very rapidly with very high accuracy over a TTL level serial connection. You would also of course want a GPS for long term course following, as well as wind information if you want to keep a constant wind angle.

The only thing left is the brain and user interface. Here I have two very different ideas. First would be to use a pair of Arduinos. One would handle the course handling and the other would be hooked up to an LCD and buttons for the user interface. The code would be written in the Arduino's simplified C.
The second idea is to use a PC/104 form factor computer running Linux and write all the code in python. This would be overkill from a processing standpoint, but could do double duty as a navigation/instrumentation computer. Old PC/104 gear is pretty cheap and built to an industrial spec.

The whole thing would be housed in a IP67/IP68/NEMA 6P enclosure (depending on location) with some decent bulkheads (I like Souriau UTS).

I haven't thought much about the display and controls, but this should be easy.

For the software, the most basic implementaion would be a standard PID loop with your desired course being your SV, your rudder angle the MV, and your actual heading the PV.
Once this was working, additional inputs could be tied in to make everything work better.
The heading accelerometer easily be set up to could tweak the PID tuning variables.
A constant roll angle (heel) might indicate sailing, and since most sailboats head up more easily than the fall off, this could be implemented. This effect also increases with heel angle.
A sudden increase in wind speed while sailing would have a similar effect, but with greater delay.

The "ultimate" functionality would be to take a time series of pitch/roll/yaw and acceleration data and put it through some Fourier analysis to get the frequencies and directions of the waves acting on the vessel. This is how the NOAA buoys do it. In theory you should be able to predict the boats motion if the wave trains have any regularity to them. This would be far beyond the Arduino, but not too hard (in theory) for a x86 processor using scipy or matplotlib.

Would it be cheap? No, it would probably be at least US$1000 for the hardware, excluding the drive mechanism. It would be cheaper than the US$2600 Raymarine wants for an X30 + US$660 for the control head. It could also be much more sophisticated. I doubt that X30 actively monitors sea state or dynamically changes it's tuning based on vessel speed.

I'll have to look at the ybwopenpilot to see where they are going with this...

 

>Ryan said: The only thing left is the brain and user interface. Here I have two very different ideas. First would be to use a pair of Arduinos. One would handle the course handling and the other would be hooked up to an LCD and buttons for the user interface. The code would be written in the Arduino's simplified C.

Ryan you have this very thought out and I'd encourage you to go for it! I think you have hit all the major mechanical and systems challenges. Bringing all that together is a problem for many people.

I think Arduino, especially a Mega, is an excellent choice.
(Some pointers, for reference):
http://www.arduino.cc/ - home page
http://arduino.cc/en/Main/ArduinoBoardMega - The Mega

You are talking about a lot of computer power, actually, by any previous standards. And the idea of multiple identical microcomputers handling separate parts of a complex system is an approach that is used successfully in industry. My son has done this in wind energy datalogging systems that have survived pretty difficult environments.

You're talking about multiple processors that run 20 million instructions per second, have hardware multipliers and shifters, and lots of peripheral and I/O choices including 4 hardware UARTS (serial ports). Not long ago this was a high-end desktop machine specification...

And a good development environment that's free, has dozens of talented contributors and lots of successful projects sounds good. Actually you can go at any time from the "simplified C" into the full Atmel-supported language features.

You have some forward looking ideas in the dynamic control area. Being able to continuously improve your software, in stepwise refinement, would make this approachable. Logging all your sensor data at sea might allow you to simulate things at home later. Or, if the system works well enough, you could repair to the chart table to rewrite the next software release level and then try it out

Email me if you want a bunch of Arduino books...

If you do this well enough, maybe you can sell kits and retire to Okracoke

Keep us posted!

 

Sorry, can you back up that statement.

The fact is that modern rate gyro based AP, probably do as good a job as possible. Yes a customised autopilot, with software that is specifically tuned to your boats response and quirks might be better. But on a time or,materials basis, will never be cost effective.

Modern AP like Simrad and raymarine are very sophisicated, dupllicating that effort will not be easy.

 

Exactly. But most of the people here on BoatDesign, given a choice between working elsewhere and then buying a new commercial "cost-effective" boat would rather build or modify one!

As Rat said in "Wind in the Willows", "There's nothing half so much fun as simply messing about with boats."

 

Ryan,

You've got a great project here! There's a lot of scope, but my concern is that you'll be duplicating a lot of work already done, whether that's by me, or by the guys at ybwopenpilot. Have a serious look at the main opensource projects in this field (OpenPilot, YBWOpenPilot and OpenCPN). Then decide whether you really want to start another disparate project, or whether you can take advantage of the work that has already been done.

Tim B.

 

Yep, very easily, first point is that rate gyro's have spinning wheel inside that is resisted to twisting by springs, the amount of deflection is your turn rate. But for good sensativity and quality of these devices the building cost goes up. and they a more prone to errors, if a spring looses its springyness or through wave action the wheel can slow down or spin up also causes errors. Accelerometers are more reliable, cheaper and more accurate.

Second point and i think is the trump card is that which a rate gyo system, with its lack of abilty to measure distance traveled along an axis you get the problem that is drawn in the very bad drawing i've posted. If you look the boat of the left, this boat has the rate gyro system, he wants to head on the course he's going, hits the button and the AP holds the heading, he's traversing his course until a side force acts on the boat, but since its not changing his direction, the AP system does not sence it, even with a compass as the boat is still pointing in the same direction.

Now look at the boat on the right, this has accelerometers in the AP system, he is the same deal, wants to travel in a direction, engages the autopilot system, but notice when a side force acts on it, the acceloremeters sences this, turns the boat into the side force, since it can measure how far it was pushed off track, it can then put the boat back on track and notice it crabs the boat to keep on track, the amount of crabbing can be used to measure the side force. And when the side force is removed the crabbing is removed and the boat traverses in a straight course. Notice, no external inputs are required to keep a track, thats no GPS or any other forms of navigational aid.

So bang for buck, the acclerometer system poo's all over even the best systems that use rate gyros as the major sensor. Even if this system uses GPS to keep the boat on track, because of the problems with rate gyro, these boats tend to hunt around the track course but never really sit on it.

 

More thoughts

Tim, You are correct, I'd rather not do it alone or start something new if there's already something out there which can be built upon. Both OpenPilot and OpenCPN seem to have scope which doesn not overlap with a dedicated autopilot. The YBWOpenPilot looks like a PC based system written in Java. I've asked to be registered, but I think it has to wait for the project owner to approve. I've not programmed in Java, but it doesn't look too hard.
Unfortunately, while I do some programming, that isn't my strength, I'm more of a hardware integrator.
I was working with a serial PID motor controller today, and the hardware capabilities are remarkable for the price. You tell the rudder where you want it to go, and it goes there. It's very easy to tune the acceleration, overshoot, etc.

The more I think about it, the more I tend to think that the Arduino is a better platform choice than the PC. I think that the YBWOpenPilot project is going to use the Arduino for IO, but why not do everything with it?

Although I already have an arduino, I haven't played with it enough. I have found a PID library:
http://www.arduino.cc/playground/Code/PIDLibrary

goboatingnow, I wonder how sophisticated they really are. It's a compromise to develop a one-size fits all product that can handle everything from fast planing craft to displacement sailboats. AFAIK, aside from the solid state rate gyro, there have been few advances in their capabilities. I think Simrad uses a variable speed controller, but Raymarine has on, pulse, and off.
Raymarine has their AutoLearn, but this is probably a simple PID tuning algorithm. I'd be curious to see wat processor runs a corepack. I'd guess it's remarkably primitive.
I think a basic PID controller, tuned correctly, could do as good a job as any commercial product. The user interface may be the hardest part.
From a materials standpoint: The mechanicals will be the same.
Processor: Arduino Mega $56
Motor Controller: MOTM3 w/carrier board. $100
Rudder position potentiometer (Raymarine uses a 5kohm) $10-100
Digital Compass/Rate Gyro: $250.
Enclosures, connectors, wire: $100
Some IP68 buttons and a serial LCD display: $100
Total:$700 max and probably less. vs $3200 for Raymarine.

Time is another matter. I don't have a lot of free time, but I've got a few years until we move back aboard with the kids.

DaveJ, I think that in the context of recreational autopilots (raymarine, simrad, etc), a "gyro" is really a solid state accelerometer. I don't think any of them use spinning gyros as that would be cost prohibitive.

 

Ryan, with reguards to the rate gyro being solid state, i suspected as much. But reguardless whether being solid state or not, you will always the same problem. If the solid state gyro is dual purpose ie. not only does it give you rate of turn but also velocity along an axis would be a more flexiable sensor, allowing more complex programming when time permits.

 

If you search sparkfun or farnell (other distributors are available) that most common rate gyros are indeed MEMS system, not quite solid state, but pretty close. There is a device called a "Ring Laser Gyro", but these would cost the same as a small yacht. The MEMS gyros are not affected by linear motion to any great degree, however accelerometers will be sensitive to tilt-angles.

OpenPilot does not yet have any autopilot capability, however, it does have Serial IO, NMEA parsing and analogue input support, all of which may be of interest to you. It should also provide a way to manage the user interface.

If I were doing this project, I think I'd start with an ARM9 PC104 board running Linux, and build on top of an existing project.

But then, I would say that!

Tim B.

 

I had that in mind myself Tim, there are plenty of ARM7 or ARM9 boards that would be plug and play so to speak, i've been told the Atmel's cut down version of linux for their boards is quite solid and feature rich.

Yes, the accel's would sence tiltangle, but the sensors i've in mind are three axis so you can compensate for tilt just through boring ol' vecotrs (going from the top of my head it would be the CoS of Y and Z axis i think)

But the AP system i have in mind would take inputs from the AIS and RADAR to provide a total tactical navigation solution (Hmmm my militry background is coming out with fancy words like that) where all your contacts are stored in a central database where API's/running programs can read/rewite bits and pieces to this database as the need requires, this is alittle over the top but believe it allows flexablity in design and further addon's.

It is then possible to transmit this database to another station, be it land or sea and recieve databases from those other station and get a greater pitcure of the traffic in the area (aswell as other data like wind and sea state). I see the potental benifits for the coast guard and air sea rescue more than anything else with this concept. Safety, safety, safety, you can never be too safe.

As you can see, i've done alot of thinking about what i want in a AP system and trying to hurd people in what i think is the right direction, and hopefully make a system that will be in a price range for the average sailor.

Tim: I have ideas of using Openpilot or other opensource software as the user interface but wanted to get my stuff in a pile before i troubled you.

 

PC/104 boards.

I had to do a comparison of some PC104 boards recently and at first our top choice was a TS-7800 from technologic systems. While it will run Linux fine, other software (python, MySQL) will have to be compiled for it, and sometimes it isn't so easy on account of the ARM processor. Boards based on x86 processors were a better value in the long run for us based on perceived development time. In the end we went with a Advanced Digital Logic ADLS15PC which has a 1.6 GHZ atom processor. It supports hardware virtualization too, so we hope to use Xen to run Debian and winXP at the same time. Unfortunately, this board costs 3x the TS-7800. For personal use, I think I'd choose the Win Enterprises MB-73200 which has about the same specs at under $300.

On the control front, I've read a few papers on autopilot control using Fuzzy Logic control instead of a PID loop. I'm still trying to get me head around all the concepts and how they translate to code, but It looks intriguing.

I can understand the desire for a "total system", but a box which given a heading via RS232, takes care of the sensors and rudder control takes a big chunk out of the project. I still think there's an advantage to doing the low level control with a micro-controller rather than a PC.

While the interface could be very sophisticated, in practice, I usually just push the Auto button when we are on a good course. If we are deviating from our desired course I adjust the course manually. At sea there's lots of time to push buttons and at 6 knots, you don't have to be exact. In my estimation, performance is more important than features, I would like to trust the system not to gybe while I'm on the foredeck.

I see the cockpit interface being a 4 line LCD, two buttons (Auto, Stby), and a course adjustment knob. This would be housed in a clear otterbox type enclosure. The LCD would display current heading, desired heading, rudder angle, and mode. Setup and tuning could be done via a PC interface when I have the time. With some sysem of "hold sown auto for 5 seconds to enter programming mode", you could tune the autopilot with this basic interface as well.


It is also important that the autopilot is always available. If I need to do a sail change in a hurry, I don't want to have to re-boot the autopilot.

 

Tim and Ryan, I don't think you are necessarily overlapping too much. The architectural question is where function is partitioned.

I think there are some good reasons for having a subsystem which "holds a commanded heading, perhaps damping boat motions in a sophisticated way". That subsystem can then become part of an overall system that knows about charts and waypoints, and "commands" the "auto-helmsman" to take a certain heading.

Hopefully the auto-helmsman can be optimized for low power, applying power to the rudder servo sparingly if necessary. Or it could use more power and do boat-dynamics stuff. Depends on the application, from Power to long-cruise low-power sail. If it's 8 hours between waypoints, the chart/human oriented part of the system can be shut down or put to sleep if the power is an issue.

Ryan knows some servo / mechanical stuff that is an important part of a low-cost working system. Maybe collaborate, divide and conquer??