In my opinion: you should bundle this as an offline electron app that can save to the filesystem and get integrated into existing PLM. and/or sell a team plan that offers cloud design & library sync
… and partner with that YC company doing wire harness machines for a “buy now” button
It really is great, haunting, nostalgic music that I associate with a formative time in my childhood. Beyond the game it’s also fantastic deep focus & coding soundtrack.
If you haven’t heard it, listen to Sweden or Aria Math.
You joke, but there was a ferry accident (I think an NJ to Manhattan ferry) where control was lost because the control station… ran out of SD card space for logs and crashed
Cool! As a moonshot fun idea I’ve been interested in MCP as a way to use informal conversations to task robots. I’ll have to play around with this!
One example on unmanned boats: a human could radio to the boat over VHF and say “move 100 meters south”… that speech-to-text would feed to an LLM which extracts the meaning and calls the MCP.
I recently contributed this new plugin for Telegraf, Influx's open source telemetry agent.
This lets you collect metrics directly from a Mavlink stream, for example from an ArduPilot drone flight controller.
The end result is that you can now use standard telemetry pipeline tools - Telegraf, InfluxDB/VictoriaMetrics/TimescaleDB, and Grafana - to visualize livestreaming and historical data from drones.
I've been using this for the past few months professionally and it's been awesome to be able to use Grafana's graphing capabilities to plot things like vehicle speed, energy consumption, etc.
Writing path planning code is one of the most enjoyable programming tasks. Love the visualizations.
The path following code is also interesting because I bet you'll run into some corner cases where the A* path thinks a path is feasible, but the vehicle overshoots and hits something. Although in a game I guess that adds to the fun & chaos.
On a technical level, this is a perfect use-case for PostGIS, which I'm a huge fan of.
Charts are hand-authored by government hydrography offices and encoded into a format called "S-57". These files contain spatial data for a small area, and different charts cover different zoom levels. This presents a few problems for web apps: Charts of different intended zoom levels cover other data, the full chart dataset is too large to stream, and charts aren't divided into xyz tiles cleanly.
To solve this, I run a bespoke pipeline which processes all nautical chart data into an internal format using PostGIS. From there, I merge all chart data together, overlaying higher accuracy charts over the lower accuracy charts. The pipeline performs a lot of data validation & reconciliation to remove bad data, then simplifies & renders to vector tiles.
PostGIS is critical to this - I started by using a bunch of python geometry manipulation libraries, and slowly shifted more and more of the processing into SQL queries as I realized how fast and intuitive it is.
If you just want to play around with the nautical chart rendering, check out https://app.vectorcharts.com/ - A free nautical chart viewer that demonstrates the vector charts API.