Jump to content

Open Source Marine Linux for Raspberry Pi


Recommended Posts

Open Source BBN Marine Linux Free OS for Raspberry Pi
2021-10-04-Release-Stable (Long Term Support 2)

Notes: This release is the second Stable Long Term Support

More was done for offshore sailors and live-aboard. All touchscreen issues including OpenCPN were resolved even in previous release.
 

  • Firewall added
  • Recognize Shipmodul
  • Magnetic variation fix in SignalK
  • Improved performance and usability of Stellarium
  • Fixed conflict of pypilot and bluetooth
  • Polars added
  • Add-ons Maritime Library
  • More SignalK plugins
  • Better winlink support (2 apps pat-winlink and jpskmail)
  • Gribs dir location fix in OpenCPN
  • Harder limits for rsyslog
  • Allow updates via apt even if cloudsmith is out of bandwidth
  • Added rpiboot for CM4 support
  • Documentation improvements. Better hardware support section and more.
  • A separate image is available for Waveshare CM4 IoT board/box
  • Mirrored release image. 2 locations to download from (cloudsmith and archive.org)


Download at


Getting Started Guide at


Project Home at github

  • Like 3
Link to post
Share on other sites

Interesting. Can you share the specifics of your setup? What do you use for displays. Do you have AIS, do you use GRIBs?

 

 

Link to post
Share on other sites

I have dAISy AIS USB and Argonaut m7 screen a cockpit.

I do download GRIBs and use them. My boat has an LTE router (Spitz)

 

Link to post
Share on other sites

I've also have speakers connected to Pi and use touchscreen both as a chartplotter/dashboard and music player.

LTE modem has GPS built-in and I use it as well.

 

 

Link to post
Share on other sites

Also wind speed/direction is fed via NMEA into Pi with FTDI USB stick from wireless masthead transducer

and compass is via IMU on pi.

 

Link to post
Share on other sites
3 hours ago, mgrouch said:

Also wind speed/direction is fed via NMEA into Pi with FTDI USB stick from wireless masthead transducer

and compass is via IMU on pi.

 

Which IMU? There are lots. Some even work...

FKT

Link to post
Share on other sites

They are described in Hardware section of Getting Started Guide.

There are industrial options with CM4 as well.

You can put the whole system into weather proof enclosure and use cable glands for exits

(the way telecom providers put their equipment outside).

 

  • Like 1
Link to post
Share on other sites
On 10/11/2021 at 9:59 AM, mgrouch said:

The list of supported IMUs is in Getting Started (Hardware) section. The support is via PyPilot.

https://bareboat-necessities.github.io/my-bareboat/bareboat-os.html#_imu_compass_accelerometer_gyroscope

 

And how many of them are commercially available as 'plug and play' items? Which ones? from whom/where?

I've *been* down this rabbit hole. I never did find an IMU that worked without extensive fucking about with Arduino code or similar when what I wanted was basically a black box that got power in and engineering magic numbers out. Such as ships heading in degrees.

There's a fair bit of stuff that works but as I said, it's a rabbit hole of arbitrary depth/branch counts, a lof of them ending in a dead end. I hit one the other day with a Bosch IMU that turns out to be buggy as hell and obsolete to boot yet it's on that list you provided.

FWIW I like, use and recommend Raspberry Pi's but you're trivialising the problems the moment you do more than load up OpenCPN - and I'm a software developer.

FKT

Link to post
Share on other sites
45 minutes ago, kent_island_sailor said:

I keep *wanting to do this* and I keep not doing it because the power and cash numbers never add up once I get into a nice display.

You can simply start with below deck system and use a regular consumer monitor in a dry place in your nav station.

Link to post
Share on other sites
4 hours ago, Fah Kiew Tu said:

And how many of them are commercially available as 'plug and play' items? Which ones? from whom/where?

I've *been* down this rabbit hole. I never did find an IMU that worked without extensive fucking about with Arduino code or similar when what I wanted was basically a black box that got power in and engineering magic numbers out. Such as ships heading in degrees.

There's a fair bit of stuff that works but as I said, it's a rabbit hole of arbitrary depth/branch counts, a lof of them ending in a dead end. I hit one the other day with a Bosch IMU that turns out to be buggy as hell and obsolete to boot yet it's on that list you provided.

FWIW I like, use and recommend Raspberry Pi's but you're trivialising the problems the moment you do more than load up OpenCPN - and I'm a software developer.

FKT

Sorry to hear about your IMU issues. If you looked at the list provided Bosch IMU is specifically mentioned as experimental and unreliable on pi. So your issues with Bosch just confirm accuracy of the list.

IMUs are key component in drones and they somehow fly. You can check PyPilot documentation / forums and find IMU that works without going into Arduino code.

Link to post
Share on other sites
53 minutes ago, mgrouch said:

You can simply start with below deck system and use a regular consumer monitor in a dry place in your nav station.

I could, but my power consumption would then go up. I have been chasing it the other way. I started with an ordinary old laptop, which worked well but used about 3 amps. Then I hacked a small Dell Chromebook to accept Mint and started using that. It draws under an amp and works pretty well. My latest tech is an Ipad running SeaIQ on a mount. It draws even less than the Chromebook and can be carried around the boat. If under power or otherwise not needing the last bit of battery I run both and if I am really wanting to save amps I run just the iPad.

I may set up a rig-pi for the ham radio duties, but for a nav system I can't seem find any kind of monitor that won't draw a lot more power than what I have now. maybe I am looking in the wrong places??

I love SeaIQ btw, it looks like OpenCPN so it works well looking from one display to the other. http://seaiq.com/

 

Link to post
Share on other sites
25 minutes ago, kent_island_sailor said:

I could, but my power consumption would then go up. I have been chasing it the other way. I started with an ordinary old laptop, which worked well but used about 3 amps. Then I hacked a small Dell Chromebook to accept Mint and started using that. It draws under an amp and works pretty well. My latest tech is an Ipad running SeaIQ on a mount. It draws even less than the Chromebook and can be carried around the boat. If under power or otherwise not needing the last bit of battery I run both and if I am really wanting to save amps I run just the iPad.

I may set up a rig-pi for the ham radio duties, but for a nav system I can't seem find any kind of monitor that won't draw a lot more power than what I have now. maybe I am looking in the wrong places??

I love SeaIQ btw, it looks like OpenCPN so it works well looking from one display to the other. http://seaiq.com/

 

For power usage you need to be specific. 3 amps at what voltage? Power is watts. Monitor power usage depends on size and backlight brightness.

It shouldn't be an issue to find low power consumption monitor for nav station, with the power usage less than iPad of comparable size.

 

Link to post
Share on other sites
21 minutes ago, mgrouch said:

For power usage you need to be specific. 3 amps at what voltage? Power is watts. Monitor power usage depends on size and backlight brightness.

It shouldn't be an issue to find low power consumption monitor for nav station, with the power usage less than iPad of comparable size.

 

My boat is a 12 volt boat. Is it possible to have a Pi and 10" monitor come in under 1/2 amp at 12 volts?

 

Link to post
Share on other sites
5 minutes ago, kent_island_sailor said:

My boat is a 12 volt boat. Is it possible to have a Pi and 10" monitor come in under 1/2 amp at 12 volts?

 

for pi4 and 10" you will be around 15 watts.

pi4 itself is about 5 watts

 

 

Link to post
Share on other sites
4 minutes ago, mgrouch said:

for pi4 and 10" you will be around 15 watts.

pi4 itself is about 5 watts

 

 

This more than double my power consumption now. I probably will combine a rig-pi and OpenCPN at some point, but I'll still need something else for low power nav.

Link to post
Share on other sites
On 10/10/2021 at 5:45 PM, mgrouch said:

Open Source BBN Marine Linux Free OS for Raspberry Pi
2021-10-04-Release-Stable (Long Term Support 2)

Notes: This release is the second Stable Long Term Support

More was done for offshore sailors and live-aboard. All touchscreen issues including OpenCPN were resolved even in previous release.
 

  • Firewall added
  • Recognize Shipmodul
  • Magnetic variation fix in SignalK
  • Improved performance and usability of Stellarium
  • Fixed conflict of pypilot and bluetooth
  • Polars added
  • Add-ons Maritime Library
  • More SignalK plugins
  • Better winlink support (2 apps pat-winlink and jpskmail)
  • Gribs dir location fix in OpenCPN
  • Harder limits for rsyslog
  • Allow updates via apt even if cloudsmith is out of bandwidth
  • Added rpiboot for CM4 support
  • Documentation improvements. Better hardware support section and more.
  • A separate image is available for Waveshare CM4 IoT board/box
  • Mirrored release image. 2 locations to download from (cloudsmith and archive.org)


Download at


Getting Started Guide at


Project Home at github

Thank you, that looks really good!

  • Like 1
Link to post
Share on other sites
9 hours ago, mgrouch said:

Sorry to hear about your IMU issues. If you looked at the list provided Bosch IMU is specifically mentioned as experimental and unreliable on pi. So your issues with Bosch just confirm accuracy of the list.

IMUs are key component in drones and they somehow fly. You can check PyPilot documentation / forums and find IMU that works without going into Arduino code.

I've been down that rabbit hole too. Frankly the PyPilot documentation sucks. I did find one useful reference doc done by a 3rd party but not sure I saved the link.

I'm a mostly retired software developer. I wrote big marine datalogging and display systems. I WANT to see the code and documentation.

I've no doubt that some IMU's will work. I just don't feel like re-running every experiment out there to determine it. Exact model number and supplier with reference/test code and I'll buy one or 2. Don't know if you're aware but just swapping from an Arduino Uno to a Nano can cause - issues. The details are vital. I wasted a lot of time trying to get Ethernet shields working properly with Nanos. Gave up. Bought a different board that worked AS IT WAS SUPPOSED TO out of the box. Alas that one is now out of production and I have ONE spare to hand.

Not interested in an endless rabbit hole of libraries & patches that never *quite* work.

Recently I hacked together a JSON decoder in Java so I could do something nice & simple like get the GPS data from gpsd onto a tcp/ip socket. There is no native way of doing this if you want to feed NMEA0183 strings to legacy applications that get their data via tcp/ip or udp/ip. I originally solved it with a python hack, didn't like that, then used gpspipe sending its output to netcat because gpspipe ALSO wouldn't send NMEA0183 data to a socket though it would to stdout or a serial port. So 3 different solutions to what should be dead simple for the original developers.

And I didn't like any of those solutions - too many things in the stack to go wrong - so bought a Garmin serial GPS and fed it into a single port terminal server. No coding at all, NMEA0183 data on a tcp/ip socket. Problem solved with a bit of hardware. But as a programmer I was looking at the code out there for an existing solution and - down another fucking rabbit hole.

I don't feel like replicating shit like this all the time. Life's too short.

It took me less than 30 minutes to get a cheap-arse AIS/GPS receiver (no xmit) outputting RS232/485 serial data working on my Ethernet network because I decided to avoid all the shit and just wired it to a single port terminal server. Want to see if the data are coming through? Just open a telnet session to the IP address/port and see the NMEA strings on your screen. And I can do that from anywhere on the network.

And the hand-waving bit about "Oh just run OpenCPN on a laptop down below not at the helm" is someone telling ME what I need to do on MY boat. I don't drive my boat from the cabin.

I bought a Simrad plotter. It works. It's waterproof. It's readable in bright sunlight. It wasn't cheap but - it works.

In fact I do have OpenCPN running on a Pi. It's a play toy for me because KIS is right - by the time you buy all the robust deck/salt water resistant bits, you might as well buy a dedicated plotter.

As a second, below decks plotter/display it works great. I've got it installed on a Pi 4 with an 18" display on the bulkhead in the main cabin. It's connected to the boat Ethernet system by cable. It's one of the reasons why I wanted a Ethernet GPS.

And yes I could export the below-decks display via VNC Server to a tablet at the wheel, but I could also install Navionics or similar on the tablet and not need OpenCPN too.

I think OpenCPN is a brilliant bit of software, actually, but the hardware side in open deck situations simply isn't there for me. PyPilot, I've my doubts about due to poor documentation. It may well be very good but every time I look closely I kind of walk away shaking my head. That might be on me of course but - shrug. Only so much time to play.

There are a lot more branches of this marine electronic rabbit hole I've been down too but enough for now....

FKT

  • Like 1
Link to post
Share on other sites
2 hours ago, Fah Kiew Tu said:

I've been down that rabbit hole too. Frankly the PyPilot documentation sucks. I did find one useful reference doc done by a 3rd party but not sure I saved the link.

I'm a mostly retired software developer. I wrote big marine datalogging and display systems. I WANT to see the code and documentation.

I've no doubt that some IMU's will work. I just don't feel like re-running every experiment out there to determine it. Exact model number and supplier with reference/test code and I'll buy one or 2. Don't know if you're aware but just swapping from an Arduino Uno to a Nano can cause - issues. The details are vital. I wasted a lot of time trying to get Ethernet shields working properly with Nanos. Gave up. Bought a different board that worked AS IT WAS SUPPOSED TO out of the box. Alas that one is now out of production and I have ONE spare to hand.

Not interested in an endless rabbit hole of libraries & patches that never *quite* work.

Recently I hacked together a JSON decoder in Java so I could do something nice & simple like get the GPS data from gpsd onto a tcp/ip socket. There is no native way of doing this if you want to feed NMEA0183 strings to legacy applications that get their data via tcp/ip or udp/ip. I originally solved it with a python hack, didn't like that, then used gpspipe sending its output to netcat because gpspipe ALSO wouldn't send NMEA0183 data to a socket though it would to stdout or a serial port. So 3 different solutions to what should be dead simple for the original developers.

And I didn't like any of those solutions - too many things in the stack to go wrong - so bought a Garmin serial GPS and fed it into a single port terminal server. No coding at all, NMEA0183 data on a tcp/ip socket. Problem solved with a bit of hardware. But as a programmer I was looking at the code out there for an existing solution and - down another fucking rabbit hole.

I don't feel like replicating shit like this all the time. Life's too short.

It took me less than 30 minutes to get a cheap-arse AIS/GPS receiver (no xmit) outputting RS232/485 serial data working on my Ethernet network because I decided to avoid all the shit and just wired it to a single port terminal server. Want to see if the data are coming through? Just open a telnet session to the IP address/port and see the NMEA strings on your screen. And I can do that from anywhere on the network.

And the hand-waving bit about "Oh just run OpenCPN on a laptop down below not at the helm" is someone telling ME what I need to do on MY boat. I don't drive my boat from the cabin.

I bought a Simrad plotter. It works. It's waterproof. It's readable in bright sunlight. It wasn't cheap but - it works.

In fact I do have OpenCPN running on a Pi. It's a play toy for me because KIS is right - by the time you buy all the robust deck/salt water resistant bits, you might as well buy a dedicated plotter.

As a second, below decks plotter/display it works great. I've got it installed on a Pi 4 with an 18" display on the bulkhead in the main cabin. It's connected to the boat Ethernet system by cable. It's one of the reasons why I wanted a Ethernet GPS.

And yes I could export the below-decks display via VNC Server to a tablet at the wheel, but I could also install Navionics or similar on the tablet and not need OpenCPN too.

I think OpenCPN is a brilliant bit of software, actually, but the hardware side in open deck situations simply isn't there for me. PyPilot, I've my doubts about due to poor documentation. It may well be very good but every time I look closely I kind of walk away shaking my head. That might be on me of course but - shrug. Only so much time to play.

There are a lot more branches of this marine electronic rabbit hole I've been down too but enough for now....

FKT

I have a Standard-Horizon plotter at the helm and all my toys at the chart table. the S-H is waterproof, sunlight readable, reliable as a rock, barely uses any power, and does not ever need screwing with. I have a cheap Yakker by Yakbitz on my NMEA 0183 line that sends UDP over wifi to whatever I want to connect to it and that mostly works well, it can have issues with too many devices on at once.

 

 

Link to post
Share on other sites
4 hours ago, Fah Kiew Tu said:

I've been down that rabbit hole too.[...] Not interested in an endless rabbit hole of libraries & patches that never *quite* work.[...] down another fucking rabbit hole. [....]There are a lot more branches of this marine electronic rabbit hole I've been down too but enough for now....

I was thinking about this for the last few days before I saw your post because I was thinking about using pypilot on my next boat and was pondering the deficiencies of the documentation, enclosures, and overall integration/packaging of what could be an extraordinarily successful solution.  And yes, the lack of a clearly defined integrated system that has been tested together is a major frustration.  (Though I will note that for pypilot in particular, its author (Sean) has tried to address this by packaging and selling the major components himself)

The trad marine electronics vendors do a remarkably good job on the chartplotters IMO, sunshine readable displays, good environmental design overall including quality enclosures and connectors that do not waste valuable space, low power consumption, and reasonable prices given the component costs.

Then on the other hand they want $600 for a wireless wind instrument that doesn't work very well and is made out of $75 of parts, or $1000 for an autopilot controller that doesn't do much that's made out of $100 of parts.

I am thinking of running some CANbus/NMEA2000 experiments over the winter.  One of the deficiencies of the open source marine electronics movement IMO is that they are on strike against NMEA2000 which limits interoperability with other systems.  These are solvable problems.

 

On 10/11/2021 at 6:58 PM, mgrouch said:

You can put the whole system into weather proof enclosure and use cable glands for exits

(the way telecom providers put their equipment outside).

Cable glands use up far more space than properly designed IP67 connectors and don't usually seal very well (the main problems being that most techs don't torque them tight enough and mismatches between cable diameter and what the gland is capable of sealing).  Telecom providers do use them but only on non-critical short-lifespan components typically serving only one or a handful of subscribers.  In most cases the glands have to be applied before the connector is attached to the cable which means some combination of lower reliability, more installation effort, and greater bulk.  They also presume that installation and maintenance will take place only on a dry days.

  • Like 1
Link to post
Share on other sites
1 hour ago, 2airishuman said:

I am thinking of running some CANbus/NMEA2000 experiments over the winter.  One of the deficiencies of the open source marine electronics movement IMO is that they are on strike against NMEA2000 which limits interoperability with other systems.  These are solvable problems.

They are solvable problems. Unfortunately and this is just my opinion, they went off with things like Signal K and JSON objects making something quite simple into something complex and a right PITA. There are quite a few good arguments for this approach, but it introduces complexity that detracts from simple useability.

What we did was send NMEA type strings for instruments which weren't in the NMEA0183 book, or actual correctly formatted NMEA0183 strings for defined instruments, over Ethernet.

Each 'talker' had its own IP address and port number. What you got out was a parseable text sentence. For data that was time and delivery critical, tcp/ip. Other data streams, udp/ip.

We had a hell of a lot of instruments on the network and it worked reliably.

As I understand it, one of the problems with NMEA2000 is the companies locked up the IP for the standard quite tightly so it's hard to work with legally unless you spend a shit-ton of money. Some of it has been reverse-engineered but I've not really paid it any attention as my interest has been elsewhere up to now.

I too may have a bit of a play with CANbus to see about sending some subset of data from my Ethernet system to the Simrad plotter. I have a Digital Yacht black box that does the opposite ATM and it works well.

Incidentally I took a look at the URL in the first post WRT software. Fuck me, the only thing that seems to be missing is a virtualised 64 bit kitchen sink! How about the KISS approach first up - an operating system that has OpenCPN loaded and NOTHING ELSE. The very LAST thing I'd ever do is load up a systems critical computer like a chart plotter with shit like a music player or a TV viewer! Come on, exercise some common sense about this.

It's not like Pi computers are expensive or power hogs. ONE Pi running the plotter and maybe PyPilot, a second one with all the extraneous shit including data logging et al. That's why I want to offload as much as possible to the devices themselves. Tell OpenCPN that its GPS data is on a tcp socket on 192.168.1.64 port 2002. AIS on 192.168.1.65 port 2002. Etc Etc.

Oh well I've a bunch of new SD cards and some SSD's doing nothing. Might see how I go this time around using a Pi 4 and running it along with the 3B I've currently got loaded with OpenCPN.

FKT

Link to post
Share on other sites
9 hours ago, Fah Kiew Tu said:

I've been down that rabbit hole too. Frankly the PyPilot documentation sucks. I did find one useful reference doc done by a 3rd party but not sure I saved the link.

I'm a mostly retired software developer. I wrote big marine datalogging and display systems. I WANT to see the code and documentation.

I've no doubt that some IMU's will work. I just don't feel like re-running every experiment out there to determine it. Exact model number and supplier with reference/test code and I'll buy one or 2. Don't know if you're aware but just swapping from an Arduino Uno to a Nano can cause - issues. The details are vital. I wasted a lot of time trying to get Ethernet shields working properly with Nanos. Gave up. Bought a different board that worked AS IT WAS SUPPOSED TO out of the box. Alas that one is now out of production and I have ONE spare to hand.

Not interested in an endless rabbit hole of libraries & patches that never *quite* work.

Recently I hacked together a JSON decoder in Java so I could do something nice & simple like get the GPS data from gpsd onto a tcp/ip socket. There is no native way of doing this if you want to feed NMEA0183 strings to legacy applications that get their data via tcp/ip or udp/ip. I originally solved it with a python hack, didn't like that, then used gpspipe sending its output to netcat because gpspipe ALSO wouldn't send NMEA0183 data to a socket though it would to stdout or a serial port. So 3 different solutions to what should be dead simple for the original developers.

And I didn't like any of those solutions - too many things in the stack to go wrong - so bought a Garmin serial GPS and fed it into a single port terminal server. No coding at all, NMEA0183 data on a tcp/ip socket. Problem solved with a bit of hardware. But as a programmer I was looking at the code out there for an existing solution and - down another fucking rabbit hole.

I don't feel like replicating shit like this all the time. Life's too short.

It took me less than 30 minutes to get a cheap-arse AIS/GPS receiver (no xmit) outputting RS232/485 serial data working on my Ethernet network because I decided to avoid all the shit and just wired it to a single port terminal server. Want to see if the data are coming through? Just open a telnet session to the IP address/port and see the NMEA strings on your screen. And I can do that from anywhere on the network.

And the hand-waving bit about "Oh just run OpenCPN on a laptop down below not at the helm" is someone telling ME what I need to do on MY boat. I don't drive my boat from the cabin.

I bought a Simrad plotter. It works. It's waterproof. It's readable in bright sunlight. It wasn't cheap but - it works.

In fact I do have OpenCPN running on a Pi. It's a play toy for me because KIS is right - by the time you buy all the robust deck/salt water resistant bits, you might as well buy a dedicated plotter.

As a second, below decks plotter/display it works great. I've got it installed on a Pi 4 with an 18" display on the bulkhead in the main cabin. It's connected to the boat Ethernet system by cable. It's one of the reasons why I wanted a Ethernet GPS.

And yes I could export the below-decks display via VNC Server to a tablet at the wheel, but I could also install Navionics or similar on the tablet and not need OpenCPN too.

I think OpenCPN is a brilliant bit of software, actually, but the hardware side in open deck situations simply isn't there for me. PyPilot, I've my doubts about due to poor documentation. It may well be very good but every time I look closely I kind of walk away shaking my head. That might be on me of course but - shrug. Only so much time to play.

There are a lot more branches of this marine electronic rabbit hole I've been down too but enough for now....

FKT

61rL2gW6FGL.jpg

Link to post
Share on other sites
5 hours ago, Panoramix said:

61rL2gW6FGL.jpg

Who and what are you referring to?

Did you make the PyPilot work? Please send details if you did.

I do this kind of thing for a living, at first on boats and now on a bigger scale and think I am a fair judge of what is still fun experiments and what is reliable sailing gear you can trust on a dark and stormy night. I happen to love experiments and have probably a mile of wire running all over the boat, but I also have things I know will work when operated by my salt-water soaked hands in the driving rain ;)

  • Like 1
Link to post
Share on other sites

The CANboat project has a single JSON file that documents NMEA2000 very well. 6 years ago I was able to use that and a little Python to both send and receive traffic from my NMEA2000 bus. 
 

I stopped tinkering with building this stuff because getting the physical design right was hard (especially for anything with a display). The coding is easy by comparison. 

 

  • Like 1
Link to post
Share on other sites
54 minutes ago, kent_island_sailor said:

Who and what are you referring to?

Did you make the PyPilot work? Please send details if you did.

I do this kind of thing for a living, at first on boats and now on a bigger scale and think I am a fair judge of what is still fun experiments and what is reliable sailing gear you can trust on a dark and stormy night. I happen to love experiments and have probably a mile of wire running all over the boat, but I also have things I know will work when operated by my salt-water soaked hands in the driving rain ;)

Giving away code for free for others to use and study is a very generous thing to do.

Moaning that said code does not fit your personal requirements is a very mean thing to do because it wasn't written for you!

I've never used PyPilot so I don't have an opinion on it... I don't know if I could make it work, TBH I see value on not being too dependent on "black boxes" you have no control over (like one's friggin phone which in reality does what Google or Apple wants it to do) so if I had to be really self reliant, I might give it a try, thus I am sympathetic to people who give away code for all of us to use.

Link to post
Share on other sites
13 minutes ago, Panoramix said:

Giving away code for free for others to use and study is a very generous thing to do.

Moaning that said code does not fit your personal requirements is a very mean thing to do because it wasn't written for you!

I've never used PyPilot so I don't have an opinion on it... I don't know if I could make it work, TBH I see value on not being too dependent on "black boxes" you have no control over (like one's friggin phone which in reality does what Google or Apple wants it to do) so if I had to be really self reliant, I might give it a try, thus I am sympathetic to people who give away code for all of us to use.

How much experience do you have with free open-source stuff? Some of it is truly amazing. OpenCPN beats many commercial programs hands-down. I am forever grateful to the people that maintain it.

That said.......you don't have to work in that world for long before you go down a rabbit hole or two. X won't compile because it is missing library Y. Y is no longer available, but maybe Z will work, but that won't work without the XYZ code and that used to be hosted by Bill but he died and his widow threw the computer in the trash. Sure you CAN just write your own code. You also can buy a shitty car and some machine tools and design your own parts to make it work. Most people don't know how to redesign a car or write their own version of a plotter or autopilot and even those that do aren't likely to do it between the time the code crashes and the time you hit the rocks. This isn't even getting into one-off waterproof displays cost MORE than a dedicated marine plotter with a waterproof display :rolleyes:

There is a place for all the free stuff and there is a place for things that just work.

  • Like 1
Link to post
Share on other sites
10 hours ago, Fah Kiew Tu said:

As I understand it, one of the problems with NMEA2000 is the companies locked up the IP for the standard quite tightly so it's hard to work with legally unless you spend a shit-ton of money.

That is the story and I believe that it is probably 99% pure, unadulterated Bunkum.  You can't use the NMEA2000 logo or call your product NMEA2000 approved or compliant or whatever without permission from NMEA but there is ample precedent that you can say factual things like "compatible with most chartplotters that support NMEA2000 signalling" etc.  You can't get the official documentation but there's nothing unlawful about reverse engineering the protocol in order to achieve compatibility.  It's not encrypted.

I think the real reason it isn't widely supported by the open source community is that it's an older technology now and in an all-open-source environment there are better choices.  The problem with that approach is that it inhibits incremental adoption of open-source products because you can't, for example, drop a pypilot in as a replacement for an existing NMEA2000 autopilot from B&G or whoever and compare the performance. 

10 hours ago, Fah Kiew Tu said:

Incidentally I took a look at the URL in the first post WRT software. Fuck me, the only thing that seems to be missing is a virtualised 64 bit kitchen sink! How about the KISS approach first up - an operating system that has OpenCPN loaded and NOTHING ELSE. The very LAST thing I'd ever do is load up a systems critical computer like a chart plotter with shit like a music player or a TV viewer! Come on, exercise some common sense about this.

This is why, in the private sector, there are product managers -- even for major Linux distributions and other more general-interest open source packages.

10 hours ago, Fah Kiew Tu said:

It's not like Pi computers are expensive or power hogs. ONE Pi running the plotter and maybe PyPilot, a second one with all the extraneous shit including data logging et al. That's why I want to offload as much as possible to the devices themselves. Tell OpenCPN that its GPS data is on a tcp socket on 192.168.1.64 port 2002. AIS on 192.168.1.65 port 2002. Etc Etc.

That's the approach that's worked well for Garmin, B&G, etc.

Link to post
Share on other sites
12 hours ago, Fah Kiew Tu said:

Incidentally I took a look at the URL in the first post WRT software. Fuck me, the only thing that seems to be missing is a virtualised 64 bit kitchen sink! How about the KISS approach first up - an operating system that has OpenCPN loaded and NOTHING ELSE. The very LAST thing I'd ever do is load up a systems critical computer like a chart plotter with shit like a music player or a TV viewer! Come on, exercise some common sense about this.

I used a Windows 98 laptop running SeaClear for many years and it was quite reliable. It did NOTHING else and NEVER touched the internet. IMHO a device used for navigation should do nothing else.

 

Link to post
Share on other sites
1 hour ago, kent_island_sailor said:

How much experience do you have with free open-source stuff? Some of it is truly amazing. OpenCPN beats many commercial programs hands-down. I am forever grateful to the people that maintain it.

That said.......you don't have to work in that world for long before you go down a rabbit hole or two. X won't compile because it is missing library Y. Y is no longer available, but maybe Z will work, but that won't work without the XYZ code and that used to be hosted by Bill but he died and his widow threw the computer in the trash. Sure you CAN just write your own code. You also can buy a shitty car and some machine tools and design your own parts to make it work. Most people don't know how to redesign a car or write their own version of a plotter or autopilot and even those that do aren't likely to do it between the time the code crashes and the time you hit the rocks. This isn't even getting into one-off waterproof displays cost MORE than a dedicated marine plotter with a waterproof display :rolleyes:

There is a place for all the free stuff and there is a place for things that just work.

It shouldn't be about cost, I use open source stuff when it works because I dislike that now we don't own our IT stuff anymore. My dad has to change a Simrad system because they've stopped maintaining it and things become flaky and hard to maintain. The boat is hybrid, opencpn under deck (which has been working flawlessly for half a decade! )and something to be defined above. If I was time rich, I would have tried to implement a fully open source solution. In case of success, chances are that the system would have been more robust IMO. On old LandRover they had a small number of parts for repairability, similarly you could imagine having Raspberry Pis everywhere with a few spare SD cards that have been flashed with a copy of the in service ones and 2 spare Raspberry, that should be quite resilient and maintainable at sea.

Professionally I use a mix of opensource and close source stuff. (Python, libre office, Thunderbird, Firefox... ) I briefly tried to switch to Ubuntu 10 years ago but it didn't work as I am dependent on some proprietary windows software and virtual machines or Wine weren't practical...

For ham radio, I am exploring this: https://github.com/km4ack?tab=overview&from=2021-09-01&to=2021-09-30

it keeps me entertained!

When it doesn't work I don't yell at developers, I just tell them politely that there is a bug or a missing feature...

Link to post
Share on other sites
3 hours ago, kent_island_sailor said:

I used a Windows 98 laptop running SeaClear for many years and it was quite reliable. It did NOTHING else and NEVER touched the internet. IMHO a device used for navigation should do nothing else.

 

Exactly.

Panoramix - posting memes. Hah. It's obvious he can't & doesn't write software. I do. I also use a lot of open source stuff, nearly everything in fact.

OpenCPN works well - if you run it below decks. It's really good software. I'm going to d/l the latest version in the near future.

If you want to run it in an exposed position then it's not the software that's the problem (assuming they HAVE fixed the touchscreen issues that is). It's the cost and availability of the hardware. And while I like Raspberry Pi computers, I've my doubts on their longevity in that environment unless very well sealed. On that subject, I've been conducting an experiment that's going into year 2 now - I installed a Pi with 7" touchscreen inside an IP67 plastic box with transparent lid displaying depth data. It's working fine but the screen is a PITA to operate as you have to open the lid and also it's almost impossible to read in bright sunlight. I've a replacement unit on the bench ATM, this one fitted with a 7" very high brightness screen designed for a video camera. The screen cost $300 or more. And it's 7". And it's neither weatherproof nor touch. As a passive data display, it'll be fine. As a chartplotter, no way. And just try looking for a decent weatherproof trackball mouse at a sensible cost. I gave up on that too.

Now on PyPilot I did find my bookmark:

https://github.com/pypilot/workbook/wiki

This is a very good writeup but having re-read it, I see why I kind of went cold on it. Too much of it is tightly coupled and pulling it apart is going to be more work than it's worth.

A simple example of my issues is in this paragraph:

----------------

The Arduino Controller talks to the pypilot raspberry through a bidirectional serial connection. This can either be a serial TTL connection or a USB cable. The protocol that is spoken over this connection is binary, bespoke, and highly optimized. It makes no sense trying to interface at this level, and nobody has ever tried. In one direction, pypilot tells the Arduino controller to move the rudder, how far and how fast. In the other direction, the Arduino controller tells the pypilot various things about the measurements of the sensors that are connected to the Arduino, like rudder angle, and the condition of the controller itself, like voltage, current and temperature.

------------------

Now this states that rudder angle sensor is connected to the Arduino. Nowhere I can find in the docs is WHAT rudder angle sensor(s) work. And more to the point, WHY one needs to be hard-wired to the Arduino anyway. I have a rudder angle sensor, a friend and I wrote the code for it, it uses its own dedicated Arduino and spits out 'proper' NMEA0183 data as a rudder angle indicator is supposed to do. That's all it does; one function, one device, the code is simple, it's a black box swap if it breaks. Mine sends the data over tcp/ip but serial would actually be simpler. Whatever, the point is the way I did it puts the rudder angle data on the network so any interested device can get it. How does PyPilot read and use this data stream? Probably can't unless someone gets deep into the source code. That ties the *function* of an autopilot to the *hardware* of a rudder angle indicator.

No doubt a lot of this is personal philosophy. I've been writing software for over 40 years in scientific & engineering environments. The code in those projects simply *had* to work. Continuous running uptime had to be measured in months to years with well tested failover procedures in the event of a power failure etc.

I learned to keep things as simple and modular as possible. The 'kitchen sink' approach never worked out well. Tightly coupling everything also never worked well.

Writing 'black box' code where there were well defined API's that did not change was the way to robustness. You could change the internals of how something worked, but not it's published communication protocol (always exceptions of course but then you've broken a working system if you're not careful). The rudder angle indicator is a classic example here - it sends NMEA0183 data out. How it gets that data, what hardware is used, anything about its internals is no business of any downstream device. The contract is a parseable NMEA sentence and that's it. The hardware is irrelevant and can be upgraded with zero effect on anything else.

Of course I may well be wrong about this because in the 'Data Connections' section it says you can send RSA messages to port 20220 on the Pi running the software. So maybe you don't need a hard-wired rudder angle indicator at all, might be a documentation issue. Or not. I don't know.

There's a hell of a lot of good stuff and hard work there but I think that unless you do it pretty much exactly the same as the developer did, you'll be pushing shit uphill.

Oh well the more I look the more I think I and a couple of my interested friends might have to go down the DIY path for an autopilot. All I really need is one that holds a heading anyway, following a bunch of waypoints is a good way to run aground IMO.

FKT

Link to post
Share on other sites
22 hours ago, Fah Kiew Tu said:

I've been down that rabbit hole too. Frankly the PyPilot documentation sucks. I did find one useful reference doc done by a 3rd party but not sure I saved the link.

Bareboat Necessities Getting Started Guide has the link to that doc in PyPilot section

https://bareboat-necessities.github.io/my-bareboat/bareboat-os.html#_pypilot

 

22 hours ago, Fah Kiew Tu said:

I've no doubt that some IMU's will work. I just don't feel like re-running every experiment out there to determine it. Exact model number and supplier with reference/test code and I'll buy one or 2. Don't know if you're aware but just swapping from an Arduino Uno to a Nano can cause - issues. The details are vital. I wasted a lot of time trying to get Ethernet shields working properly with Nanos. Gave up. Bought a different board that worked AS IT WAS SUPPOSED TO out of the box. Alas that one is now out of production and I have ONE spare to hand.
 

This is a thread about raspberry Pi OS. It's not really about Arduino. Have you opened bug reports to respective Arduino libraries on github?

Do you have a GitHub account?

 

22 hours ago, Fah Kiew Tu said:

Recently I hacked together a JSON decoder in Java so I could do something nice & simple like get the GPS data from gpsd onto a tcp/ip socket. There is no native way of doing this if you want to feed NMEA0183 strings to legacy applications that get their data via tcp/ip or udp/ip. I originally solved it with a python hack, didn't like that, then used gpspipe sending its output to netcat because gpspipe ALSO wouldn't send NMEA0183 data to a socket though it would to stdout or a serial port. So 3 different solutions to what should be dead simple for the original developers.

That was unnecessary effort. GPSd can perfectly stream NMEA 0183 over TCP or UDP with simple configuration. You might need to switch GPS from binary to NMEA mode though per vendor instructions.

 

22 hours ago, Fah Kiew Tu said:

I don't feel like replicating shit like this all the time. Life's too short.
 

That's why scripting it and sharing it on github with others would have been better.

 

16 hours ago, Fah Kiew Tu said:

As I understand it, one of the problems with NMEA2000 is the companies locked up the IP for the standard quite tightly so it's hard to work with legally unless you spend a shit-ton of money. Some of it has been reverse-engineered but I've not really paid it any attention as my interest has been elsewhere up to now.

SignalK works with NMEA 2000 nowadays.

 

5 hours ago, kent_island_sailor said:

How much experience do you have with free open-source stuff? Some of it is truly amazing. OpenCPN beats many commercial programs hands-down. I am forever grateful to the people that maintain it.

That said.......you don't have to work in that world for long before you go down a rabbit hole or two. X won't compile because it is missing library Y. Y is no longer available, but maybe Z will work, but that won't work without the XYZ code and that used to be hosted by Bill but he died and his widow threw the computer in the trash.

That's an issue with proprietary software. Open source software has code available and anyone can continue the project or fork it at any time.

Proprietary software (SeaClear, QtVLM, SeaIQ, etc) always a risk of losing support. Maintainer or company supporting it can stop it.

Company can go out of business or discontinue the product and declare it EOL. You end up with no support and no source code. Not an issue with Open Source.

BBN OS is open source and it is build in a way that normally you wouldn't need to compile anything yourself. (However you wouldn't know that unless you tried it for yourself). It's built not just for software developers. It's built and documented for regular users too.

 

16 hours ago, Fah Kiew Tu said:

Incidentally I took a look at the URL in the first post WRT software. Fuck me, the only thing that seems to be missing is a virtualised 64 bit kitchen sink! How about the KISS approach first up - an operating system that has OpenCPN loaded and NOTHING ELSE. The very LAST thing I'd ever do is load up a systems critical computer like a chart plotter with shit like a music player or a TV viewer! Come on, exercise some common sense about this.

Are you familiar that Raymarine LightHouse OS includes these features too? The features you prefer not to have. Will you ask Raymarine to remove them too?

 

22 hours ago, Fah Kiew Tu said:

And the hand-waving bit about "Oh just run OpenCPN on a laptop down below not at the helm" is someone telling ME what I need to do on MY boat. I don't drive my boat from the cabin.

As a second, below decks plotter/display it works great.

Two sentences just contradict each other. 2 paragraphs apart. :)

4 hours ago, kent_island_sailor said:

I used a Windows 98 laptop running SeaClear for many years and it was quite reliable. It did NOTHING else and NEVER touched the internet. IMHO a device used for navigation should do nothing else.

Weather information is important function of navigation. Internet is very valuable for getting up to date weather and charts. After all the main function of a skipper is safety. So obviously having internet access is a big plus.

Windows laptop is Intel based. Consumes too much power on a boat.

 

 

 

Link to post
Share on other sites
26 minutes ago, Fah Kiew Tu said:

Now this states that rudder angle sensor is connected to the Arduino. Nowhere I can find in the docs is WHAT rudder angle sensor(s) work. And more to the point, WHY one needs to be hard-wired to the Arduino anyway. I have a rudder angle sensor, a friend and I wrote the code for it, it uses its own dedicated Arduino and spits out 'proper' NMEA0183 data as a rudder angle indicator is supposed to do. That's all it does; one function, one device, the code is simple, it's a black box swap if it breaks. Mine sends the data over tcp/ip but serial would actually be simpler. Whatever, the point is the way I did it puts the rudder angle data on the network so any interested device can get it. How does PyPilot read and use this data stream? Probably can't unless someone gets deep into the source code. That ties the *function* of an autopilot to the *hardware* of a rudder angle indicator.

I think it's due to the fact that autopilot needs to have rudder angle available at anytime. NMEA 0183 would be too slow for that. But it's better to check on PyPilot forums. Dedicated device sending angle via NMEA to autopilot to be used for rudder control is probably not feasible (too slow).

 

Link to post
Share on other sites
1 hour ago, Fah Kiew Tu said:

I learned to keep things as simple and modular as possible. The 'kitchen sink' approach never worked out well. Tightly coupling everything also never worked well.

Writing 'black box' code where there were well defined API's that did not change was the way to robustness.

As hardware becomes more capable and economics and market will dictate vendors to put more functionality into one box they sell.

They are going to be multi-functional devices. It will help reduce wiring on a boat which improves reliability and power efficiency,

and help to keep cost of overall system down.

 

Just as with smart phones. It's very multi-functional device. You have clock, GPS, compass, camera, media player in it. Chartplotters are going similar path.

A bee is a small thing. It can fly and see and get directions. I can see that future boat computer which controls most aspects of the boat

can be packed into match box size device. Cheap and very low power consuming.

Link to post
Share on other sites
1 hour ago, Fah Kiew Tu said:

Now this states that rudder angle sensor is connected to the Arduino. Nowhere I can find in the docs is WHAT rudder angle sensor(s) work.

A potentiometer.  If memory serves 20k ohms is recommended.

 

1 hour ago, Fah Kiew Tu said:

And more to the point, WHY one needs to be hard-wired to the Arduino anyway. I have a rudder angle sensor, a friend and I wrote the code for it, it uses its own dedicated Arduino and spits out 'proper' NMEA0183 data as a rudder angle indicator is supposed to do. That's all it does; one function, one device, the code is simple, it's a black box swap if it breaks. Mine sends the data over tcp/ip but serial would actually be simpler. Whatever, the point is the way I did it puts the rudder angle data on the network so any interested device can get it. How does PyPilot read and use this data stream? Probably can't unless someone gets deep into the source code. That ties the *function* of an autopilot to the *hardware* of a rudder angle indicator.

::shrug:: Pypilot can't deal with rudder sensors that emit NMEA0183 or NMEA2000.  I don't think that's necessarily the end of the world.  The pypilot approach is that there is a rudder control subsystem made up of the drive motor and associated gearing or hydraulics, the motor controller, and the rudder sensor.  I don't think that's unreasonable.

 

1 hour ago, Fah Kiew Tu said:

Oh well the more I look the more I think I and a couple of my interested friends might have to go down the DIY path for an autopilot. All I really need is one that holds a heading anyway, following a bunch of waypoints is a good way to run aground IMO.

FKT

Sean has figured out how to integrate a 9 axis compass/gyro/accelerometer, a motor controller, and a rudder position sensor together to make an ap.  And he's done it in a way that reportedly tracks better and uses less power than anything you can buy for money.  That's no small thing.  Whether or not you hook up bearing to waypoint, distance to waypoint, and crosstrack error to all that is a comparatively trivial matter of personal taste.

Link to post
Share on other sites
13 minutes ago, 2airishuman said:

Sean has figured out how to integrate a 9 axis compass/gyro/accelerometer, a motor controller, and a rudder position sensor together to make an ap.  And he's done it in a way that reportedly tracks better and uses less power than anything you can buy for money.  That's no small thing.  Whether or not you hook up bearing to waypoint, distance to waypoint, and crosstrack error to all that is a comparatively trivial matter of personal taste.

Even more. I've seen temperature of motor drive being reported/monitored. I do not know though how it is used in the AP code.

Link to post
Share on other sites
1 hour ago, 2airishuman said:

A potentiometer.  If memory serves 20k ohms is recommended.

 

::shrug:: Pypilot can't deal with rudder sensors that emit NMEA0183 or NMEA2000.  I don't think that's necessarily the end of the world.  The pypilot approach is that there is a rudder control subsystem made up of the drive motor and associated gearing or hydraulics, the motor controller, and the rudder sensorI don't think that's unreasonable.

 

Sean has figured out how to integrate a 9 axis compass/gyro/accelerometer, a motor controller, and a rudder position sensor together to make an ap.  And he's done it in a way that reportedly tracks better and uses less power than anything you can buy for money.  That's no small thing.  Whether or not you hook up bearing to waypoint, distance to waypoint, and crosstrack error to all that is a comparatively trivial matter of personal taste.

I don't think it's unreasonable either. It's a design decision. It's quite justifiable. I simply don't like it because it tightly couples hardware that IMO doesn't need to be tightly coupled. The data rate demands aren't that high.

I also am not too happy with IMU hats on a Pi. You're running a pretty heavy operating system on some serious processing power compared with a single-purpose Arduino. I'd rather offload that onto another Arduino and have it send out NMEA strings for the data rather than communicate via I2C or similar with the Pi. Somewhere I have a Pi Sense HAT, maybe I should dig it out again. But that means running a Python program to talk to the hat. IIRC I was playing with it using Node Red some years back. I found at the time that the temperature and therefore humidity sensors on-board were totally useless because the temperature reading was polluted by the waste heat emitted by the Pi itself. And without accurate temperature, the humidity calculation is always going to be incorrect.

As I said, PyPilot looks like an all-in-one deal. That's a perfectly acceptable approach, but basically it's another black box solution albeit cheaper than the commercial options. In which case I'd want to know that ALL the hardware needed was specified in detail and supplied as part of the purchase package. I may just buy the entire box & dice and implement it anyway if I can, I'm not too taken with reinventing the wheel myself if I can avoid it. But I do like to know how deep & twisty the rabbit hole is going to be before I start down it.

Meanwhile one Pi 4 is running its apt-get upgrade and then I'll install OpenCPN. After that I'll clone the SD card because it's a PITA going through the process of getting everything configured again. Another Pi 3B is running OpenCPN with a USB puck connected & working fine. And I have another couple of 3Bs with touchscreens looking for a project...

FKT

Link to post
Share on other sites

And - ha ha - the top quality SD card in the Pi 4 shit itself doing the upgrade. Lovely i/o error. Now dead and won't boot. Can't even run the shutdown command.

Just imagine being out there coming to a tricky bit of navigation and your system shits the bed like this.

Oh well I always keep some spare SD cards and I've a Toshiba USB SSD I was planning on using next time I put a system together. And it's raining.

So here we go again. Another few hours down the tubes.

Let's see if I remember just what tools et al I had installed. GPSD and clients plus the RTC (real time clock) stuff and configuring NTP before I even get near OpenCPN, IIRC.

FKT

Link to post
Share on other sites
9 minutes ago, Fah Kiew Tu said:

Let's see if I remember just what tools et al I had installed.

You script it so it is reproducible. No need to remember. It should be recorded in a script.

As far as i/o error. Root filesystem is ext. It is journaling filesystem. And /boot is just reading.

It should recover on next boot unless there are some major hardware problems.

Link to post
Share on other sites
6 hours ago, kent_island_sailor said:

FYI - all the rudder angle indicators I set up back in the day were pots with three wires that connected straight to the autopilot computer. The computer probably needs rudder angle NOW, not in a second or so.

What data rate do you think is required? Serious question, I can test to see if my Arduino setup can do it. I reckon 10Hz won't be a problem.

In point of fact the information I have is, 1Hz is plenty. I'm already sending out properly formatted NMEA0183 sentences every 500 milliseconds. Boats really don't move that fast and nor do their rudders. The big ship's system had its gyro compass at 4800 baud to the AP. Not very fast.

I like playing  with this sort of stuff.

Incidentally the Pi 4 is running again from the Toshiba SSD rather than an SD card. Haven't tested to see if it survives a reboot as yet. Must do that before fully installing all the extra software.

FKT

Link to post
Share on other sites
11 hours ago, Fah Kiew Tu said:

The data rate demands aren't that high.

Really ?

Autopilots tend to be slow to react when compared to a human helm, IMO you really don't want to add latency anywhere especially going downwind in breezy conditions... That's actually what makes the difference between a NKE style autopilot and a more ordinary one!

Link to post
Share on other sites
11 hours ago, Fah Kiew Tu said:

 I have another couple of 3Bs with touchscreens looking for a project...

FKT

Hang on to those, you might be able to sell those at a substantial profit to people like me.

Still waiting for dhl (over a week so far) to pickup 60 3b+ in HK. Had to go to secondary market because they are almost unobtanium. And the price is marked up 80 per cent.

Link to post
Share on other sites
5 hours ago, Fah Kiew Tu said:

What data rate do you think is required? Serious question, I can test to see if my Arduino setup can do it. I reckon 10Hz won't be a problem.

In point of fact the information I have is, 1Hz is plenty. I'm already sending out properly formatted NMEA0183 sentences every 500 milliseconds. Boats really don't move that fast and nor do their rudders. The big ship's system had its gyro compass at 4800 baud to the AP. Not very fast.

I like playing  with this sort of stuff.

Incidentally the Pi 4 is running again from the Toshiba SSD rather than an SD card. Haven't tested to see if it survives a reboot as yet. Must do that before fully installing all the extra software.

FKT

10 Hz might work, but 1 Hz would SUCK. Easy to prove, run downwind with a following sea and make yourself say "one-one-thousand" before moving the wheel each time. Your boat will be all over the place! I know my old autopilot with no rudder sensor at all blows at downwind.

Link to post
Share on other sites

Anyone ever try connecting one of these to the Raytheon/Autohelm wheel drives? This thing is cheap enough and wiring to my drive is easy enough to experiment on without doing any permanent mods.

I started this thread pretty skeptical of the whole thing and now I want one.

Link to post
Share on other sites
30 minutes ago, kent_island_sailor said:

10 Hz might work, but 1 Hz would SUCK. Easy to prove, run downwind with a following sea and make yourself say "one-one-thousand" before moving the wheel each time. Your boat will be all over the place! I know my old autopilot with no rudder sensor at all blows at downwind.

Yes, it would suck. And it would likely be far worse than a one-second delay. Probably be a surprise if all the latencies were identified and summed. Every step has a latency. The fluxgate compass is only checked so often and even its principle of operation involves delay as the phase change rotates around the coils. The smoothing operations (often dubious, so loved by hackers) also cause a phase shift as the system waits for new values. Communication of data along wires also delays, especially at 1950-era 4800 baud. The time from the sender's first character to the receiver decoding the last character is significant. And there can be computationally-dubious jitter from waiting for and synchronizing inputs from several sensors. Don't forget inertia in the drive mechanics and rudder slew rate. Etc.

I wouldn't attempt building a system on an OS-based platform. One wants a simple real-time kernel with guaranteed latency. And I would think hardware floating-point, too.

What is the latency of a human? Say the latency sensing a turn with eyes or g-force to hand beginning to move the wheel? 200ms? Gotta do at least that.

 

Link to post
Share on other sites
15 minutes ago, El Borracho said:

Yes, it would suck. And it would likely be far worse than a one-second delay. Probably be a surprise if all the latencies were identified and summed. Every step has a latency. The fluxgate compass is only checked so often and even its principle of operation involves delay as the phase change rotates around the coils. The smoothing operations (often dubious, so loved by hackers) also cause a phase shift as the system waits for new values. Communication of data along wires also delays, especially at 1950-era 4800 baud. The time from the sender's first character to the receiver decoding the last character is significant. And there can be computationally-dubious jitter from waiting for and synchronizing inputs from several sensors. Don't forget inertia in the drive mechanics and rudder slew rate. Etc.

I wouldn't attempt building a system on an OS-based platform. One wants a simple real-time kernel with guaranteed latency. And I would think hardware floating-point, too.

What is the latency of a human? Say the latency sensing a turn with eyes or g-force to hand beginning to move the wheel? 200ms? Gotta do at least that.

 

Back in the day we would improve squirrelly boats by adding a gyro sensor to fluxgate driven autopilots. The fluxgate just didn't provide info fast enough for good yaw data. One of the worst boats was one where the owner wanted the "best" autopilot for a boat that did 45 knots and ended up with something more at home on a tugboat or a freighter. It has hopeless at a boat with fast reactions until we got different firmware for it. Little twitches and overshoots that a 120 foot steel tug would never react to made a fast powerboat yank all over the place :o

Link to post
Share on other sites
15 hours ago, mgrouch said:

Really?

 

1 minute ago, kent_island_sailor said:

Back in the day we would improve squirrelly boats by a dding a gyro sensor to fluxgate driven autopilots. The fluxgate just didn't provide info fast enough for good yaw data.

 

7 hours ago, Fah Kiew Tu said:

What data rate do you think is required? Serious question, I can test to see if my Arduino setup can do it. I reckon 10Hz won't be a problem.

In point of fact the information I have is, 1Hz is plenty. I'm already sending out properly formatted NMEA0183 sentences every 500 milliseconds. Boats really don't move that fast and nor do their rudders. The big ship's system had its gyro compass at 4800 baud to the AP. Not very fast.

It depends on sea state, point of sail, and your expectations of the ap.  On a reach on a nice day your 1 hz will work great.  On a run in heavy seas and winds 100 hz might be better than 10 hz.  A well designed ap algorithm looks at the first and second derivative of the ins data which means a series of recent points are required.  A well designed ap algorithm will belay previous orders to the rudder drive more aggressively than it will usually steer which requires accurate and timely rudder position data. 

7 hours ago, Fah Kiew Tu said:

 

Incidentally the Pi 4 is running again from the Toshiba SSD rather than an SD card. Haven't tested to see if it survives a reboot as yet. Must do that before fully installing all the extra software.

FKT

SSDs are the achilles' heel of the pi.  The pi will exhaust their write life, surprisingly quickly under some conditions.  They also can be corrupted by unexpected power-down events.  In my lab I don't use them for those reasons (except for very short term experimental playthings) and network boot them instead.  The Toshiba SSD is a good choice.

Link to post
Share on other sites
2 minutes ago, 2airishuman said:

SSDs are the achilles' heel of the pi.  The pi will exhaust their write life, surprisingly quickly under some conditions.  They also can be corrupted by unexpected power-down events.  In my lab I don't use them for those reasons (except for very short term experimental playthings) and network boot them instead.  The Toshiba SSD is a good choice.

"tinypilot is my own custom linux distribution designed specifically for pypilot. This distribution is based off of tinycore linux, and runs completely out of ram after booting offering superior stability."

It seems like this is taken into account if you run JUST the pilot program, It would load once at startup and then leave the SD card alone.

Link to post
Share on other sites

Low latency with low gain will beat high latency and the then unavoidable high gain every time. You see this in A/P’s that always seem to be driving in Panic Mode. Better to react promptly but conservatively to some sensor noise than add latency (like by smoothing) and then have to over-react. 
 

If 10 Hz seems like a good reaction period then I’d plan on a latency of 10 ms.

Aren’t there at least two separate servo loops in an A/P? One for heading and one for rudder position? Might be a third for course or track?

Link to post
Share on other sites
5 hours ago, kent_island_sailor said:

10 Hz might work, but 1 Hz would SUCK. Easy to prove, run downwind with a following sea and make yourself say "one-one-thousand" before moving the wheel each time. Your boat will be all over the place! I know my old autopilot with no rudder sensor at all blows at downwind.

I think we're talking about 2 different things.

I'm talking about the rudder angle indicator. All it tells you is where the rudder currently is. You want to know this so you don't exceed the soft limits on travel and break something trying to exceed the hard limits.

You're talking about the rudder motor driver. That's different. It's going to get its instructions from the brains box which in a simple case is just steering to a target COG and using the GPS data to get the current heading. That needs to be faster than 1Hz for sure.

But 10Hz on the indicator should be easily achievable, 100 millisecs is a long period - I'll tweak the code and see what happens.

FWIW my boat with its long keel is quite stable downwind.

And yeah SD cards suck for intensive i/o, always have. The Pi with the SSD has survived a few reboots now so I might start loading up all the extra software needed. And take another look at some of the Sparkfun IMU's that'll work with an Arduino.

FKT

Link to post
Share on other sites
3 minutes ago, kent_island_sailor said:

Does anyone know if the PyPilot uses an actual fluxgate or ??????

If it has the magnetic sensor integral to the unit, then it would have all the mounting restrictions any fluxgate would have.

I'm pretty sure - not certain, but pretty sure - this is the Hat that sits on the Pi. It's an IMU with gyro and magnetometer. You need to run a compensation routine. Could be interesting with a steel boat, it's one of the issues I keep thinking about.

The PyPilot also gets GPS data if available. My simple needs would be just to hold a given course using the GPS data rather than relying on any form or magnetic compass. There are problems with this at really slow speeds as we found out 20+ years back as the GPS just tells you COG and doesn't care if the vessel is going sideways or indeed backwards. Which is why I want a working IMU...

FKT

  • Like 1
Link to post
Share on other sites
33 minutes ago, kent_island_sailor said:

Does anyone know if the PyPilot uses an actual fluxgate or ??????

If it has the magnetic sensor integral to the unit, then it would have all the mounting restrictions any fluxgate would have.

The fluxgate compass is part of the 9-axis ins chip that is in the hat for the pi.  The pi must therefore be mounted away from magnetic interference.  That is the reason the motor controller is separate, since the currents involved will produce enough magnetic flux to affect the compass.

 

Link to post
Share on other sites
38 minutes ago, Fah Kiew Tu said:

And yeah SD cards suck for intensive i/o, always have. The Pi with the SSD has survived a few reboots now so I might start loading up all the extra software needed. And take another look at some of the Sparkfun IMU's that'll work with an Arduino.

For clarity, it's the SD cards I've had trouble with.  Real SSDs work ok unless defective, and we've had trouble with that, and not just on pis.

Onlogic.com makes some nice PCs designed for embedded control.  Similar functionality to the pi only without the I/O pins, but in a really good fanless enclosure and designed for reliability.  Roughly the same size. They are comparatively expensive but if I were going to run OpenCPN on a boat using a permanently mounted display that is what I would use.  We've had really good luck with them at work except for the defective ssds that come with the low-end configurations.  They can be ordered with a higher performance SSD that works fine.

  • Like 2
Link to post
Share on other sites
On 10/15/2021 at 2:41 PM, mgrouch said:

Company can go out of business or discontinue the product and declare it EOL. You end up with no support and no source code. Not an issue with Open Source.

Sure it is. Open source with no one left to maintain it is about as bad as unavailable closed source.  In theory someone can pick it up again, but it is rarely happens. 

Link to post
Share on other sites
12 minutes ago, Alex W said:

Sure it is. Open source with no one left to maintain it is about as bad as unavailable closed source.  In theory someone can pick it up again, but it is rarely happens. 

Really? If there is demand for the solution then it is going to be picked up and used. With closed source there is no even way.

 

Link to post
Share on other sites
11 hours ago, mgrouch said:

Really? If there is demand for the solution then it is going to be picked up and used. With closed source there is no even way.

 

First off you all are conflating software and hardware. *Marine hardware* goes EOL all the time. The idea of "forever hardware" is way way back in the rear view mirror. The only reason my ancient Autohelm autopilot works is I scrounge Ebay and so on for bits and pieces and have so far managed to keep it going. Raymarine will laugh and hang up on you if you ask them for parts or to repair it. There literally is almost no such thing as open source hardware. The Pypilot motor controllers are about all I can think of. If you want waterproof daylight readable reliable gear for mounting outside, I haven't seen anything that can replace commercial marine electronics that isn't a lot more expensive than what you are trying to replace if it exists at all.

Software is a different deal. That is going to be on phone/tablet, Mac, Windows PC, or Linux PC. If you are both a skilled programmer and have endless free time, sure you could in theory right your own code if OpenCPN or whatever goes tits-up and ends all support and new releases. You also could also get some machine tools and make a new crankshaft for your engine, mine some aluminum and make a new mast, or dig a well and refine your own diesel. For the typical cruiser with a problem that needs fixing, none of these things are practical ideas.

If the software is some niche product with a small user base, open or closed if the one guy who maintains it quits for all practical purposes you are shit out of luck. If it is something like navigation software that is in wide demand and you have a computer/phone that isn't running some obscure operating system, either open or closed source something will come along to replace it. Sure SeaIQ could vanish, but there are likely at least 4 other replacements I could download in 15 minutes. Open source is not a magic potion against all problems and very few end users are able to maintain the code on their own.

BTW - I am a big fan of OpenCPN, the community that developed it have really made a first class product. One thing I love about SeaIQ is it looks just like OpenCPN in the way the charts render and uses the same NOAA downloads, so looking from the computer to the iPad and back again is pretty seamless. Which brings me to my rant of the day: Every hardware manufacturer seems (or seemed?) to love the "cheap razor, make money selling blades" model. Ever get totally pissed spending $$$ on electronic charts when they are FREE on the web but your plotter cleverly is designed to not be able to use them :angry:

Link to post
Share on other sites
24 minutes ago, Howler said:

What's the actual underlying OS? Surely it's one of the major Linux distros adapted for the Pi?

It is Raspberry Pi OS Lite. The desktop is not from it though. The desktop is Budgie and OpenBox window manager.

Link to post
Share on other sites
9 hours ago, kent_island_sailor said:

There literally is almost no such thing as open source hardware. The Pypilot motor controllers are about all I can think of.

Ardiuno

Raspberry Pi - though this is debated

NanoVNA

Nitrokey

These are just the ones I actually have.  There are plenty of others.  Wikipedia has a list at https://en.wikipedia.org/wiki/List_of_open-source_hardware_projects

Some are more successful than others.  Some people think open source hardware is a stupid idea promulgated by kooks.  Many of these people thought that GCC was a stupid idea and that Richard Stallman was a kook.  GCC is arguably the first and most pivotal open-source software project; its success changed the world.  NanoVNA and Arduino have derivative works that are sold commercially at a profit that demonstrate that the model works, at least in some cases.  Whether Richard Stallman is a kook remains debatable.

Link to post
Share on other sites

Very nicely combined list of raspberry pi CM4 (i.e. industrial pi4) boards/computers/enclosures:

https://pipci.jeffgeerling.com/boards_cm.html

I've already tested BBN OS with Waveshare IoT CM4 computer. A separate OS image is available too to take advantage of the additional board features.

 

Several of these products could be interesting for boating applications:

Waveshare Mini IO Board Computer (ver B):  https://www.waveshare.com/product/cm4-io-base-box-b.htm

Waveshare IoT CM4 Computer https://www.waveshare.com/product/raspberry-pi/boards-kits/compute-module-4-cat/cm4-io-poe-4g-box.htm

MCUzone Carrier Grade CM4 Computers (fanless)  https://www.aliexpress.com/item/1005001972265702.html

EDATEC CM4 Industrial Computer https://www.edatec.cn/en/Product/Camera_Modules/2019/0826/76.html

 

 

Link to post
Share on other sites
1 hour ago, 2airishuman said:

Ardiuno

Raspberry Pi - though this is debated

NanoVNA

Nitrokey

These are just the ones I actually have.  There are plenty of others.  Wikipedia has a list at https://en.wikipedia.org/wiki/List_of_open-source_hardware_projects

Some are more successful than others.  Some people think open source hardware is a stupid idea promulgated by kooks.  Many of these people thought that GCC was a stupid idea and that Richard Stallman was a kook.  GCC is arguably the first and most pivotal open-source software project; its success changed the world.  NanoVNA and Arduino have derivative works that are sold commercially at a profit that demonstrate that the model works, at least in some cases.  Whether Richard Stallman is a kook remains debatable.

I meant MARINE hardware - sorry about that.

Link to post
Share on other sites
11 hours ago, kent_island_sailor said:

There literally is almost no such thing as open source marine hardware. The Pypilot motor controllers are about all I can think of.

Even the documentation from the first post in this thread mentions some of open source marine PCBs.

Sailor Hat for Raspberry Pi by https://hatlabs.fi  With PCB design published on github https://github.com/hatlabs

GeDaD MCS, Marine Control Server Board by https://www.gedad.de/  With PCB design published on github https://github.com/Thomas-GeDaD/openplotter-MCS

Waveshare publishes schematics.

Gumstix https://github.com/gumstix/PKG900000001400

There are many others. Including active antennas designs and interface boards.

 

 

 

  • Like 1
Link to post
Share on other sites
17 minutes ago, mgrouch said:

Even the documentation from the first post in this thread mentions some of open source marine PCBs.

Sailor Hat for Raspberry Pi by https://hatlabs.fi  With PCB design published on github https://github.com/hatlabs

GeDaD MCS, Marine Control Server Board by https://www.gedad.de/  With PCB design published on github https://github.com/Thomas-GeDaD/openplotter-MCS

Waveshare publishes schematics.

Gumstix https://github.com/gumstix/PKG900000001400

There are many others. Including active antennas designs and interface boards.

Open Boat Projects has plenty of links too

https://open-boat-projects.org/en/

Link to post
Share on other sites
9 hours ago, mgrouch said:

Arduino hardware products for a boat:

WIO Terminal https://www.seeedstudio.com/Wio-Terminal-p-4509.html

M5Stack Tough (m5tough)  (waterproof) https://shop.m5stack.com/products/m5stack-tough-esp32-iot-development-board-kit

 

Wow - some cool stuff there. What always seems to be missing is daylight waterproof displays that cost less than a plotter does :(

Anyway, before I order the PyPilot I need to figure out which one. It can't mount at the chart table, too much wiring there for the compass, so I'll have to think about how it all interconnects and so on.

Link to post
Share on other sites
25 minutes ago, kent_island_sailor said:

Wow - some cool stuff there. What always seems to be missing is daylight waterproof displays that cost less than a plotter does :(

Sihovision Waterproof Monitor  SL100W         10"

https://www.sihovision.com/full-ip65-high-brightness-touch-monitor/waterproof-monitor-sl100w.html

or

SL7W     7"    https://www.alibaba.com/product-detail/sunlight-readable-7-inch-touchscreen-waterproof_60543830769.html

SL10W   10"   https://www.alibaba.com/product-detail/Outdoor-display-9-7-inch-IPS_1600251157854.html

SL12W   12"   https://www.alibaba.com/product-detail/daylight-viewable-monitor-ip67-touch-marine_60718449450.html

SL113    13"   https://www.alibaba.com/product-detail/Marine-displays-IP67-waterproof-13-3_62066633231.html

 

 

 

 

Link to post
Share on other sites
On 10/16/2021 at 8:01 PM, mgrouch said:

Really? If there is demand for the solution then it is going to be picked up and used. With closed source there is no even way.

It takes demand and at least one skilled developer to pick it up.  That second part is harder.

Case in point: I made a pretty popular Garmin sailing watch app that is open source.  A couple of years ago it was the most downloaded Sailing-related app on their "store" (quotes because everything was free at the time).  It is open source.  I get multiple queries a week asking me if I've ported it to the latest watches (which I haven't).  I always offer that it is open source and that I'd be happy to take pull requests for people who can do it, but that I'm busier with family than sailing right now and not working on it.

In the 4 years that it has been available I've had interest from about 3 developers and have seen zero pull requests.

I'd guess that most open source projects falter the same way.

Link to post
Share on other sites

I just found out my son has to make a project of some kind for a computer class using a Pi. This is working out apropos this thread, he is going to make a navigation computer in a waterproof case for his Whaler B)

Meanwhile, is there a PyPilot forum anywhere? I am trying to figure out if the autopilot computer can be configured and monitored easily from another computer or if I need to string a wire for a remote display or ????

* not sure how cost effective any of this is, but it is fun :)

Link to post
Share on other sites

Can someone just port B&G's OS so i can run it on a MPU that doesn't cost $8000?

I like their concept of a MPU running dumb displays.  But the price tag for relatively mediocre computing power is astronomical...

I've gotten a B&G Vulcan 12" for $799.  That's really hard to beat...  even at it's normal street price of $1099 it's a very good deal, and it's doing everything.  By the time you get a Pi4 running with a waterproof enclosure, the multiplexer, and a high brightness 12" touch display, you're getting pretty close to $799.

So if you can make a box like the MPU for $1000, i'd buy it.  But it's literally got to just work - N2k compatible, ethernet for Radar, AIS, etc.  Then I'd run an HDMI & USB to a Helm display and another to the nav desk.

 

Link to post
Share on other sites
5 hours ago, SimonGH said:

Can someone just port B&G's OS so i can run it on a MPU that doesn't cost $8000?

I like their concept of a MPU running dumb displays.  But the price tag for relatively mediocre computing power is astronomical...

I've gotten a B&G Vulcan 12" for $799.  That's really hard to beat...  even at it's normal street price of $1099 it's a very good deal, and it's doing everything.  By the time you get a Pi4 running with a waterproof enclosure, the multiplexer, and a high brightness 12" touch display, you're getting pretty close to $799.

So if you can make a box like the MPU for $1000, i'd buy it.  But it's literally got to just work - N2k compatible, ethernet for Radar, AIS, etc.  Then I'd run an HDMI & USB to a Helm display and another to the nav desk.

 

For $6000 they are asking for their helm processor (black box without a screen)

you can build waterproof raspberry pi based computer with LTE gateway and tons of sensors and a screen for nav station of even small touchscreen screen for a cockpit, and NAS server. And you will learn more in the process instead of learning how to call B&G customer service and support. 

 

 

 

 

 

  • Like 1
Link to post
Share on other sites