YAPP - autopilot remote

[AngusMcDoon]

Yet Another Pointless Project

Yet more pointless Seatalk buffoonery. This time it's an autopilot remote control, just like you can buy from Raymarauder for a large amount of curry tokens for a plastic box that contains very little. I like to be able to steer my boat while remaining in bed on cold damp days, and now I'll be able to.

Usual thing for followers of YAPP - a cheapo PIC processor (18F26K22), a small colour touch sensitive LCD display, and a whole rat's nest of brown wires. This is the first YAPP that writes to the Seatalk bus rather than just reading from it. The Seatalk interface electronics is ripped straight off Thomas Knauf's website here...

http://www.thomasknauf.de/seatalk.htm

I have emulated on the screen what my ST2000 tillerpilot has - 6 buttons and a small numeric display. Touch the buttons on the screen and it does what you'd expect, but only for single button presses. This display cannot report multiple simultaneous screen touches so I cannot use the tack, track and windvane functions. If I had implemented the buttons using proper hardware ones then I could have done that, but the display was already wired up and I was lazy. It looks prettier too.

Here's the usual brown birdnest. The small Vero board is the Seatalk interface electronics from Thomas' site. The black lozenge is the chip flashing/debug interface and would not be needed if made up properly.

...and here it is in action. Digits without a C means in auto mode, with a C means standby, all just like the real thing...

And just to add total pointlessness to the whole thing, if the instrument lights are switched on anywhere in the system, my display updates its appearance too...

How trivial is that?

Sauce code and schematic to anyone who is interested, which gets less as the pointlessness increases.

As an aside, this is probably my last PIC based YAPP. I am moving up to STM32 ARM processor based boards. A few more £$€, but a whole load more oomph.

 

[Conachair]

We should all bow down before the godlike YAPPmiester!

Do you have a raspberry pi on order?

 

[AngusMcDoon]

I've considered the RP, but have decided against it, because...

- You can't get them.
- It's way too powerful for my feeble circuits. I don't need Ethernet, file system, bloated OS, windowing system etc
- It doesn't have many I/O brought out on its pins
- It's cheap for what it is, but expensive for a YAPP.

The STM32 boards from ST are half the price, don't need a memory card for a file system, have loads of pins brought out, and can run small tight OS's if I need one like FreeRTOS.

The RP will be great for more complex projects though, like OpenCPN when it's ported.

 

[eastlaked]

Radio link ??

How about adding some 433 Mhz radio data modules (Radiometrix??). So you can steer from the bow when trying to pick up a mooring ?

David.

 

[AngusMcDoon]

How about adding some 433 Mhz radio data modules (Radiometrix??). So you can steer from the bow when trying to pick up a mooring ?

David.

I've thought about that. Unfortunately the autopilot interface only lets you change the heading being followed in auto mode. It won't let you steer manually remotely as you can in standby mode on my ST2000+ using the +/- buttons.

I'm also thinking about linking it to a GSM module so that in really ropey weather I don't have to leave the house at all.

 

[laika]

Out of curiosity...what are the 3 "additional" brown wires leading out of the picture from the seatalk interface?

Without disagreeing with anything Angus says regarding over-specing the hardware, the Raspberry Pi does allegedly have general purpose I/O pins which some people are exploiting (add-on boards, including an rs232 breakout board, listed here)

Also using a usb to serial adapter should be possible, although this is a bit of a minefield with seatalk: with no direct access to the UART the obvious way to deal with seatalk's command bit is to set space parity and rely on getting a parity error when the command bit is set. Unfortunately not all of these adapters are reliable at reporting any types of parity errors (let alone mark/space, and this is not just an OS driver issue): I know from bitter experience with a keyspan adapter. I gather the FTDI-based adapters are your best bet.

 

[AntarcticPilot]

I've thought about that. Unfortunately the autopilot interface only lets you change the heading being followed in auto mode. It won't let you steer manually remotely as you can in standby mode on my ST2000+ using the +/- buttons.

I'm also thinking about linking it to a GSM module so that in really ropey weather I don't have to leave the house at all.

I don't see the problem. You line up from the cockpit as best you can, then put the autopilot on "Auto". You then fine-tune from the foredeck. My only worry would be that the ST2000 has a slight lag in the response to the buttons; but I often steer under engine using exactly that technique with the autopilot buttons.

Main problem would be judging when to kill the engine so she stops in the right place!

More seriously, I'd be interested in this if I could get a kit of parts including a circuit board and enclosure; I'm not up to building something like this without that sort of help.

 

[AngusMcDoon]

Out of curiosity...what are the 3 "additional" brown wires leading out of the picture from the seatalk interface?

The wires on the Seatalk interface are...

Black/Red/Yellow are the standard Seatalk stuff.

3 Browns going to the main circuit board are ground/data in/data out

3 additional Browns not connected are 12V, 5V and 3.3V (regulators also can be seen on the small interface board). These are so that I can run the whole thing off Seatalk power rather than the programmer power. The same interface board was used for my pressure logging project and that needed 12V as well for the pressure transducer.

Without disagreeing with anything Angus says regarding over-specing the hardware, the Raspberry Pi does allegedly have general purpose I/O pins.

It does, but not many of them. The STM Discovery boards have a lot more.

Also using a usb to serial adapter should be possible, although this is a bit of a minefield with seatalk.

All your Seatalk to USB conversion problems solved here

http://www.ybw.com/forums/showthread.php?t=278332&highlight=yapp

With no direct access to the UART the obvious way to deal with seatalk's command bit is to set space parity and rely on getting a parity error when the command bit is set.

I bit bash my Seatalk. It's only slow and the 18F26K22 at 64MHz has no problem. Receive is all buffered interrupt based. Send just bangs it out with appropriate delays. I was going to make send buffered interrupt driven, but it works fine the way it is.

I expect that processors like the one I am using are way more powerful than those used when Seatalk was invented so I can bit-bash away and not have to do anything clever with UARTs and parity bits.

 

[aluijten]

Excellent project once more. Nice to see people are still PBO-ing in electronics

One suggestion would be to increase the size of the box and font of the course display. It seems quite small in relation to the virtual buttons. But you may be constrained by the build in character generator of the display/cpu board.

 

[AngusMcDoon]

More seriously, I'd be interested in this if I could get a kit of parts including a circuit board and enclosure; I'm not up to building something like this without that sort of help.

I could supply pre-programmed processors at cost price. When I am next an unemployed feckless doley and have some time I could have a go at making some PCB's as they can be got cheaply now. The enclosure is the difficult bit.

 

[AngusMcDoon]

One suggestion would be to increase the size of the box and font of the course display. It seems quite small in relation to the virtual buttons. But you may be constrained by the build in character generator of the display/cpu board.

I agree that the course display is too small, but there are no built in character generators on either the display or CPU. It's all done from low level device driver level writing individual pixels to the display from the processor. I have 2 sizes of bitmapped fonts - a small proportional and a larger non-proportional. The font code looks like lots of this...

const far rom unsigned char large_font_pro[]={249, 39, 255, 159, 31, 7, 60, 159, 255, 255, 255, 255, 230, 15, 176, 112, 126, 96...

If anyone wants to create a larger one I'll gladly use it. Only digits needed.

 

[AntarcticPilot]

I agree that the course display is too small, but there are no built in character generators on either the display or CPU. It's all done from low level device driver level writing individual pixels to the display from the processor. I have 2 sizes of bitmapped fonts - a small proportional and a larger non-proportional. The font code looks like lots of this...

const far rom unsigned char large_font_pro[]={249, 39, 255, 159, 31, 7, 60, 159, 255, 255, 255, 255, 230, 15, 176, 112, 126, 96...

If anyone wants to create a larger one I'll gladly use it. Only digits needed.

Not volunteering, but I remember programming something like that about 30 years ago on a Z80 based S-100 bus "single card computer" - with about 2k of RAM and 4k of EPROM! Given that background, you'll understand why I regard modern OS as being incredibly bloated - I know exactly how little code you need for things like I/O routines! My character generator looked very like that - but the display was a tiny CRT; no flat screens in those days.