Open Source Marine Linux for Raspberry Pi
- Thread starter mgrouch
- Start date
Fah Kiew Tu
Curmudgeon, First Rank
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
kent_island_sailor
Super Anarchist
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.
2airishuman
Anarchist
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.
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.
Last edited by a moderator:
Fah Kiew Tu
Curmudgeon, First Rank
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
Panoramix
Super Anarchist
kent_island_sailor
Super Anarchist
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
Alex W
Super Anarchist
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.
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.
Last edited by a moderator:
Panoramix
Super Anarchist
Giving away code for free for others to use and study is a very generous thing to do.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
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.
kent_island_sailor
Super Anarchist
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
There is a place for all the free stuff and there is a place for things that just work.
2airishuman
Anarchist
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.
This is why, in the private sector, there are product managers -- even for major Linux distributions and other more general-interest open source packages.
That's the approach that's worked well for Garmin, B&G, etc.
kent_island_sailor
Super Anarchist
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.
Panoramix
Super Anarchist
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.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
There is a place for all the free stuff and there is a place for things that just work.
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...
Fah Kiew Tu
Curmudgeon, First Rank
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
- Thread starter
- #35
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
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?
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.
That's why scripting it and sharing it on github with others would have been better.
SignalK works with NMEA 2000 nowadays.
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.
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?
Two sentences just contradict each other. 2 paragraphs apart.
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.
- Thread starter
- #36
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).
- Thread starter
- #37
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.
Last edited by a moderator:
2airishuman
Anarchist
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 sensor. I 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.
- Thread starter
- #39
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.
2airishuman
Anarchist
Right. I believe it reduces the gain, resulting in less runtime for the motor.