Skunk works

[banaari 27]

First update from a project I have underway.

 

Genesis: I have a Raymarine ST2000+ tillerpilot on the boat. Due to other interests, the house is also riddled with a number of GPS receivers of varying form-factor and usefulness, from a bare board through to stand-alone handhelds, the phone and the iPad. Also a heap of related cabling. It slowly dawned on me that one of those receivers, a Garmin eTrexH, emits enough NMEA data for the pilot's track mode to operate.

 

Actual problem: My mooring's about 3 miles away from freely navigable water (more or less depending on tide). I sail singlehanded... so on return to base, sails come down for a long chug up the channel, followed by half an hour's tidying the boat prior to getting in the dinghy and going home. I would LIKE the vessel to navigate herself as far up the channel as possible, freeing me to scuttle around the deck putting things away, en-route. (Which I more or less do anyway, but only in 20-second bursts or so between adjusting the pilot heading).

 

Known issue: The tillerpilot will explicitly and deliberately NOT advance waypoints without user intervention.

[ Before I get inundated with abuse for trying to override this obvious safety precaution, the intended use for this setup has me on deck, heads-up, and no more than a few seconds away from the tiller to intervene. ]

 

On my side: The love object draws 0.6 metres, so I have considerable latitude to play with in terms of channel-keeping, disregarding such hazards as mooring piles and other people's boats.

 

So far: Visited Dick Smith to acquire some 9-pin D connectors only to discover the emasculation of that chain is complete, to the point where not only do they not stock anything useful, they are also staffed by monkeys. Fortunately the Betta Electrical two doors down carries a very small range of Jaycar product and even they are in end-of-line mode. D-connectors of varying gender acquired; one such has been wired to the tillerpilot's NMEA input.

 

Total hardware thus consists of the pilot, the GPS receiver, an old Acer netbook, a USB-to-serial adaptor and a splitter box.

 

Realising the pilot won't advance waypoints automatically, I decided to munge the NMEA information being sent, and simply re-write the waypoint names in the $GPRMB sentence with STRT and FNSH; (and suppress all the other sentences being sent) thus hopefully preventing the pilot spitting the dummy. Friday night spent on the couch re-acquainting myself with the delights of driving a serial port from C.

 

Outcome, after testing yesteday:

(a) Just munging $GPRMB isn't enough; the pilot doesn't complain about the waypoint changes, but it doesn't accept the new headings either.

( Disregarding (a), the pilot's track-keeping ability is truly AWFUL. Not sure how much of this is due to the limitations of the NMEA protocol.. (cross-track error has a limited precision of 0.01 nautical mile), the algorithms embedded in the pilot, or pilot calibration.

© No problem with actual GPS accuracy; the electronics are more than capable of keeping the beast in the channel; just being let down by the pilot.

 

Next steps:

Investigate just how well the pilot is calibrated - rudder gain, variation etc. (Am not hopeful here).

Am going to ditch NMEA in favour of building a SeaTalk interface which I am led to believe will provide more-or-less direct control over the pilot.

[idlerboat 116]

...I spent some time on that one.

It got way to difficult for me.

Short of spending big bucks for a fully intergrated "one brand system" with a radio remote.

 

As far as I can understand you would have to completely rewrite a lower level softwear system. ....and that cause heaps more problems.

 

I went sideways, and tried to find a way to remotley "push the button when the way point alarm sounded. Again that was way to difficult. The remote part is easy but the intergration was not.

Even cutting across contacts with a cheap relay and remote was just too messy. (..and unreliable).....and that of course wouldnt work in a lap top based nav system.

 

I finaly accepted that if I didnt have enough time to do it manualy, due to very short course changers then I probably should be watching the channel, relaxing and do all the other sh*t when I get back in.

[rigger 47]

lots of dollars

http://www.furuno.com/special/en/navpilot/about/

 

 

 

lots of info...

http://www.billdietrich.me/GPSAutopilot.html

[Island Time 1,235]

keen guys! lots of time, sometimes no results!

even the commercial wireless units require a button press to advance to the next waypoint. my PC would advance to the next waypoint, but the (simrad) ap would not change until a button was pressed.

I use the ap a lot, but I would not use it in a narrow channel without the remote in hand...

[idlerboat 116]

...yep and some of the not so old systems remotes are IR....

sort of defeats the purpose when you have to be within a metre to press the button...

 

Quick edit...

Have you put it out to the open CPN guys ?

They are absoulutely on top of the game ....not for proffit solutions by some very clever people....

[banaari 27]

sort of defeats the purpose when you have to be within a metre to press the button...

Will happily admit we're in the realms of "do it to see if it can be done", not for any great pressing need.

*IF* it can be persuaded to work, it will still be used with a very beady eye on it and a twitchy tiller arm...

 

Half the fun is to see if it can be done with bits lying around the house from previous activities... the SeaTalk RS232 interface takes only a couple of garden-variety transistors which I'll probably have in some obscure box somewhere.

 

The _real_ mission will be in modelling the response of the pilot and tuning the code appropriately.

[Norwegian Blue 10]

I am busy with a similar project using an Arduino and Raspberry Pi and my Raymarine kit. I have a 3 axis accelerometer as well to try and stabilise the autopilot downwind to stop the wild rounding up when a swell is running.

 

Essentially the Arduino is a multi source input/output mux for SeaTalk and NMEA and use the Pi instead of a laptop (low power and dirt cheap). The Arduino also gives you a cheap extra instrument repeater for down below. It is relatively easy to write code to mimic the Raymarine tillerpilot remote, so if you can do a “key press” to change course +/- 1 or 10, then some clever code taking GPS data should be able to cope with the same.

 

In the future I want to attempt an Android app to talk to the Pi and act as the tiller pilot remote, start watch and extra display.

 

A lot of inspiration taken from here http://www.42.co.nz/freeboard/ and elsewhere on the web.

[Kaihe Atamai 2]

I am busy with a similar project using an Arduino and Raspberry Pi and my Raymarine kit. I have a 3 axis accelerometer as well to try and stabilise the autopilot downwind to stop the wild rounding up when a swell is running.

 

Essentially the Arduino is a multi source input/output mux for SeaTalk and NMEA and use the Pi instead of a laptop (low power and dirt cheap). The Arduino also gives you a cheap extra instrument repeater for down below. It is relatively easy to write code to mimic the Raymarine tillerpilot remote, so if you can do a “key press” to change course +/- 1 or 10, then some clever code taking GPS data should be able to cope with the same.

 

In the future I want to attempt an Android app to talk to the Pi and act as the tiller pilot remote, start watch and extra display.

 

A lot of inspiration taken from here http://www.42.co.nz/freeboard/ and elsewhere on the web.

 

IMHO a combined open source effort with the IOIO (https://www.sparkfun.com/products/retired/10748), a cheap gyro and an android app would be a good way way to go - solves a host of interface problems and you get a built in entertainment system / GPS / plotter / BT / etc by using a pad. I'm on this route my self but can't program in Java to save my life, yet!

[banaari 27]

This evening I breadboarded up a SeaTalk RS232 interface as documented here: http://www.thomasknauf.de/rap/seatalk3.htm

Took longer than it should have because I first had to repair my old multimeter... the 9V battery had corroded in-situ taking the snap-connector and wiring with it.

Electrically it works; tomorrow comes the fun of writing the code to drive the evil thing.

There doesn't seem to be a SeaTalk datagram which will explicitly set a locked heading, so the current rationale is to use the information broadcast _from_ the autopilot to read its _existing_ locked heading, and then send incremental adjustments to it, as if from a remote.

[banaari 27]

I should not be this excited by a blinking green light... but it has taken two consecutive evenings to get the Seatalk code working.

Reading data off the bus was operational in about the first 5 minutes last night.

Sending commands, on the other hand finally came right when I spotted the typo. GetCommState() does not have quite the same effect as SetCommState().

Suffice to say we can now turn the autopilot lighting on and off, and other more useful stuff.

Upshot: A PC Seatalk interface for (so far) just the cost of the USBSerial adapter plus a tiny handful of components, say $70 all up.

[Absolution 7]

Just a thought... Rather than sending headings to the pilot why don't you set your pilot to use an external compass and then emulate a seatalk compass heading? That way you can just adjust the "fake" compass heading to minimize cross track error and then you'll also be able to control the way the pilot responds by sending a larger or smaller compass offset.

[banaari 27]

Rather than sending headings to the pilot why don't you set your pilot to use an external compass and then emulate a seatalk compass heading?

Now that's devious, and sounds like a good idea. I see on the web the beast will accept external compass data but nowhere is it mentioned in the manual for the a/p. Thanks for the tip

[banaari 27]

"Marinised" the Seatalk RS232 interface by rebuilding it on stripboard and in a nice little box.

Then lost an entire day when for some reason communication _TO_ the pilot stopped working again.

It seems there are undocumented differences in the serial driver code between Windows XP and Windows7. Under XP it is possible to toggle the port's Parity setting on the fly (required because Seatalk uses the 9th bit of each "byte" transmitted as a command flag). The same code driving the same USB serial adapter running on a Windows7 box produces no errors, but doesn't set the necessary bits in the output stream. You have to close the port and reopen it again.

"Grrrrrrgh"

[Grinna 2]

OK .... I understood the word "marinised" but after that .....

[SloopJohnB 322]

OK .... I understood the word "marinised" but after that .....

 

 

must be a big boat its got 7 windows.

[banaari 27]

Took the setup down-channel and back this afternoon; results were mixed but extremely promising.

 

The current software operates as follows: Use selected information from the GPS about the current route leg, and current position, and disregard the rest. Compute cross track error ourselves, correction to be applied and hence instantaneous heading required. Read the autopilot's locked heading and send plus or minus 1 or 10 degree commands as needed to keep locked heading the same as heading required.

 

Technical digression: For the purposes of computing heading correction, the boat is kept aimed straight at a notional, continuously shifting point which is always "K" metres along the track from current position. The smaller the value of K, the tigher the track keeping, but the more squirrely the behaviour. If we are perfectly on track, then K is dead ahead and no correction is applied. If K is 20 metres, and we're twenty metres off track to port, then a starboard correction of 45 degrees would result.

 

Results in calm(ish) conditions are impressive: Boat position consistently within a couple of metres of where the GPS thinks it ought to be. (This compares favourably with the 300 feet apparently achieved by the tillerpilot's native Track mode).

 

Wind on the other hand SERIOUSLY peturbs the system, resulting in some interesting and alarming S-curves , especially with K set low.

 

Issues also with waypoint changeover; it takes a complete cycle for all the received NMEA sentences to correspond for the same track leg, so some fun had using destination B together with heading for destination C. Also, the abrupt change of heading causes a dramatic increase in cross-track error as the boat takes time to turn away from the previous heading.

 

Next steps... see what might be achievable using the GPS heading and velocity information to allow for wind (maybe feed GPS heading straight to the pilot as if from am external fluxgate)... and do some work around waypoint changeover.

[rigger 47]

Consider having a wheel over before reaching the waypoint, think about the turning circle of the yacht. Might reduce error on next leg.

[banaari 27]

Consider having a wheel over before reaching the waypoint, think about the turning circle of the yacht. Might reduce error on next leg.

Great minds, etc. Fun bit is that while the GPS eventually broadcasts the entire route, it does it one waypoint per cycle... so you have to accumulate the information needed. Have been thinking about internally converting the route from a set of waypoints to something more like a a single continuous spline curve, and working with that.

[DrWatson 375]

loving this thread

[Island Time 1,235]

For stability and accuracy of course, I've found that my GPS gives ok performance controlling the AP, but the laptop is better. Analysis of this came down to the difference in accuracy of the XTE NMEA sentences. The GPS gives only 2 decimal points, the laptop gives 3. That means that "on course" is much more accurate and course corrections are correspondingly much narrower angles (to your point "k", out in front)...

 

This is certainly an interesting project, and I've often wondered what code is in mine... (a Simrad AP24). They can be frustrating when they don't do what YOU would do!