OpenPlotter
openmarine.net
openmarine.net
Has an excellent community of developers and hardware components.
If you have a specific concern, explain it, instead of just exuding judgment.
SignalK is neat. As you note not all protocols are suitable for all use cases, but marine sensor networks where most signals are in the realm of 1-10Hz it definitely has its place.
Simply firing up cli for troubleshooting and debugging of any kind should not be "expected behavior" at sea.
What's a server? Do you have servers in a NMEA2k environment?
> Simply firing up cli for troubleshooting and debugging of any kind should not be "expected behavior" at sea.
No one said that arcane troubleshooting and debugging should be needed after integration of a system. I mean, NMEA2K certainly never makes one fiddle around and play with things aimlessly to make stuff work /s
> especially if wireless is involved
Most common way wireless is involved here is to get the information off-boat or to a tablet for convenient review of trends.
The reason I love it so much is that it's just so straightforward to make server or client that can talk to it. All of our embedded Linux systems are written in C++ right now and they have absolutely no problem publishing and consuming messages in our standard format. One of the original driving factors for this is that we do have some web-based and Electron-based UIs and any protocol that we made that wasn't HTTP-based or Websocket-based would require them to do twice as much work: first, connecting to whatever service from a "backend" server and implementing whatever protocol it needed, and second exposing that backend service to the frontend over a Websocket (generally... since it needed live updates). By standardizing on our in-flight services just exposing everything as Websockets natively we pretty much eliminated a whole tier of complicated logic. The frontends have a single generic piece of code that has standardized reconnect/timeout/etc logic in it, and the backends just have to #include <WSServer.h> and instantiate an object to be able to publish to listeners.
I definitely didn't start there. And I 100% understand where your opinion comes from... from so many different angles a lot of the "modern" web systems shouldn't come within a mile of a safety critical system. Websockets though? They're great! And while JSON isn't necessarily the most efficient encoding, it sure does make debugging easy. We run everything on a closed network that usually doesn't have an Internet connection, so we don't run TLS in between the ground and air systems. If we need to figure out what's going on and an interface is acting up, we can just tcpdump it and have human-readable traffic to inspect.
The flight critical stuff is isolated from all of this and spits out a serial telemetry feed (Mavlink). We do send that directly to the ground station over a dedicated radio, but we also have an airborne service that cooks that into Websockets and in many cases the Websocket-over-very-special-WiFi connection has been more robust than the 915MHz serial link.
And it's not as if existing protocols like NMEA are all that good either.
- We have a flight planning module that takes multiple polygons as input and returns a (large) list of waypoints for covering the regions that the polygons cover. When I was trying to work out the request/response format I decided to use GeoJSON with some extra properties added. You submit the GeoJSON boundaries with a POST request, the planner does a bunch of computational geometry and graph algorithms, and returns back a GeoJSON. If you want to, you can just load the flight plan up in QGIS or ArcGIS or whatever and inspect it directly.
- We also accumulate quite a bit of geospatial data that we need to post-process. We used SQLite with the Spatialite extension to store that. Same story as the flight plans... you can really easily load it into QGIS or Geopandas or whatever you want and do your analysis
- We need to stream video down to the ground station and ended up using RTSP, h.264, and GStreamer to do that. You can connect to the video feed using our ground station software if you want, but you can also just connect to it using VLC. And internally this meant that if we wanted to do hardware-accelerated encoding it was just a matter of changing the GStreamer pipeline. Or... if I get my way over the next month or so, we'll be adding a HUD with extra telemetry right into the video feed, again using GStreamer plugins.
The only "safety critical" thing in this tech is the chart plotter (and GPS), and weather reports. Marine chartplotters are glorified consumer grade computers, and this OpenPlotter thing with OpenCPN is 1000% more reliable and not actively trying to kill you with proprietary licensing crap. Your phone is a great chartplotter and plenty of people cross oceans using nothing more than an iPad.
A lot of industrial ones come with GPIO built in, some even follow the same rpi pinout.
I wonder if industrial-strength RPi clones / variants exist. The demand is certainly there.
SBCs are good in conditions where reliability is not the primary concern - scenarios where frequent restarts are needed, change sd card, room temperature etc.), but in a boat? I don’t know anything about marine conditions but having a malfunctioning in SD cards and overheating is not uncommon in robotics and especially in drones (where it’s harder to use full fledged PC), few times actually the SD card died midair, no crashes thankfully.
Seco: https://edge.seco.com/usa/ and Variscite: https://www.variscite.com/products/system-on-module-som/?cpu... are two of the vendors I've worked with and had great experiences with.
If you are buying loads of them they will also customise the pi for you (although I think that's contracted out)
Often coupled with RPi "hat" interface used to attach isolated industrial I/O (24V/analog/4-20mA, etc) or other interfaces.
Amen to that.
I blame the YouTube influencers posting all the RPi content that would make you believe you can run the world on RPi. Some of the shit they post is truly dumb ... Ceph clusters on RPi ? Rather you than me !!!
I once experimented with Pi's just for a fun unimportant home-server project. I got sick and tired of all the dumb failure modes, even when I expressly went out and bought high quality industrial SD cards, went above and beyond to minimise SD card IO etc. And that was just the SD card issues.... Never again.
That was just a decent consumer-grade SD card.
I’m not sure your experience happens to most people, at least not recently.
I have over 5000 nautical miles logged (thanks to a very nifty influxdb integration as part of open plotter) using this set up since ~2021, and so far it’s held up better than I could have guessed. I keep a spare pi and sds on board but have never actually needed them. My use case is long distance races, mostly in sub tropics/temperate areas, and I’ve had limited exposure to really hot air temp (say 90F and up in the tropics which is where I could see SDs starting to fail)
the best part? it cost very little. Worried about redundancy? Build two, keep the SD cards backed up. Problem solved.
cheers.
That depends on a lot of variables: what kind of IOs you are looking for? Do you need them isolated (DIO vs GPIO), Does it need DIN rail? Integrated screen? What connectivity is needed (wifi, cellular)? Or resources (ram, cpu, etc.)? What’s the power delivery requirements?
So there’s a lot of factors that only you can answer given you know the application, but since you are looking for dust proof, then you should look for fanless AND ventless one, and one that’s vibration resistant (obviously with an SSD), and most of them can survive high temperatures, but personally I would even add it in a panel to provide extra protection, with a fan and proper ventilation just in case.
I did try some of them, like onlogic (1) and arestech (2) among others, and don’t restrict yourself to the brands, some Chinese (mostly cheaper) ones are good enough for the job like GigaIPC (3) and others too.
(1) https://www.onlogic.com/pub/media/resources/Brochures/LogicS...
(2) https://www.arestech.com.tw
(3) https://www.gigaipc.com/en/index.php?action=products2&cid=2&...
https://github.com/metisvela/sailtrack
It’s a similar project, but specifically designed for racing dinghies. It focuses on modularity and performance analysis.
Regular people save literally tens of thousands of dollars per install by going open source in this space, and end up with superior toolkits.
https://sailingcourage.xyz/projects/plotter/
Something also not often realized is that many, many sailboats are actually quite old (20, 30, 50 years!) and so are their on-board electronics. Any chance to update wiring, instruments, diagram out on-board electronics, etc. is probably a really good opportunity for nav system and overall boat maintenance.
The number of people using things like Open plotter is even smaller, but still greatly appreciated by all!
Thou for entertainment it's an other side, that would be useful.
Another issue is that there are very few makers or the technology.
I think it's a great area for development because it is immature and in the middle of technical upheaval that nobody really knows what how great a plotter could be.
In recreational vessels, our needs are more basic, but even us geeks may be more prone to shell out $500 - $2000 to Garmin or Raymarine for a hardened chart plotter MFD that "just works", is waterproof, and robust at least in the nav function. I got a "deal" on a Raymarine Axiom Pro which has both touchscreen and a keypad mode for when the rain interferes with the display, has nav, ais, radar, sonar display, engine gauges, and tons of other features, it is running some version of Android. It's really good honestly. When the wind is howling and the waves are high, it's not necessarily a good time to do some hacking and bug hunting on the nav platform. I do plenty hacking on my boat in the sensor integration world, but that's another story...
For a masterpiece of technical documentation dig up a copy of admiralty chart 5011 for a dive into the colours and symbology used.
See 59-north for examples of offshore sailing schools who seem to have found a good mix of modern and reliable
https://www.sailmagazine.com/cruising/navigating-by-tablet
The only thing I don’t like about a tablet is that it will ruin your night vision. Integrated marine electronics usually cater to that pretty well.
I had one on my last boat (though in a space that was primarily air conditioned all the time. Had another on my balcony running a Marine Traffic AIS station for 6 years that was ‘weatherproofed’ with an unsealed ziploc bag. No issues.
and you would think there would be thousands of developers eager to work on something like this. Being able to actually test ride boats, and live a more adventuous lifestyle while putting their engineering skills to practice.
Even in that class of boat the owner will typically have a coxswain on his beck and call whenever he fancies going on a jolly.
Some people have chauffeurs, others have a boat and coxswain ... sometimes the coxswain doubles up as chauffeur if the owner isn't quite rich enough to employ more than one person.
First because on a billionaire's yacht, there is a crew of 20 doing various jobs, 3 of whom do shifts on the bridge. So if you want to know where you are, you just pick up the phone to the bridge and bark at whatever poor sucker is on duty (or you bark at the person serving you drinks who then relays it up the ranks).
Second, on a billionaires yacht they already have large fancy displays with less ugly graphics.
Finally I would hazard a guess that (at least some of) the software "languishes in mediocrity" due to the safety certifications.
We would have something purpose made from raymarine/garmin/whoever hard-mounted to the steering station networked into the various sensors onboard. There would be at least one redundant display elsewhere (out of the weather in the case of boats steered from deck). We would never go for something on a raspi. Some boats will have the sensor canbus hooked into a computer to use additional software. The purpose made displays are all sleek touchscreen systems that look more like a Tesla interface than this raspi thing.
As far as UI and graphics: They are modeled on what actual paper charts look like (which is standardized, and what mariners are trained to use). These are systems designed as a safety tool first, and iterating through the latest design fads every 2-3 years to make things pretty is unsafe. I want my chart-plotters and tools to be near universal in symbology and interface, and that is what they have done.
2. Even the big fancy screens in fancy yachts have god awful UI.
3. I am not talking about meaningless fad designs. Google Maps decades ago made road maps intuitive and beautiful at the same time.
By comparison, the vast majority of those chart plotters look like ancient Windows95 graphics. It's disingenuous to suggest that's as good as it can get. Google could have easily just scanned a bunch of awful old school highway maps and called it a day if that was true.
Those chart graphics (colors, symbology, everything) are an industry and legal standard, even if you don’t think they are aesthetically pleasing or intuitive. Any trained mariner can get onboard and understand the information regardless of brand. They aren’t meant to be intuitive and beautiful, they are meant to match extensive training and expectations of professionals. They are meant to be the digital evolution of a product with centuries of development. Nothing about nautical charts is a mistake. By comparison googles maps are extremely faddish, the look of their maps has changed quite a bit since launch their launch 19 years ago.
As far as the UI outside of the charts, that works the same as any iDevice or app.
The fact that I can think back over my work history and not remember the brand of the instruments and displays I’ve used is a feature not a bug.