chrisdalke

Exactly! I run a service that handles >1M tile requests per month served directly from PostGIS with ST_AsMVT etc. and file caching.

This is awesome.

What’s your plan for pricing?

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.

Oh my bad, I missed that! That's well said. NixOS really does solve a lot of this but with the steepest learning curve I've ever seen.

No mention of NixOS, which is miles ahead of every other operating system in terms of developer time spent tweaking endless configuration...

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’ll have to install this and play around.

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.

It's probably the wrong place in the stack to implement this, these are very low-cost commodity microcontrollers running the firmware and the design of flight controller software is focused on time guarantees and reliability.

With the exception of low-cost consumer drones, most larger drones have at least a "Flight Controller" (embedded MCU handling guidance, navigation, and control) and a "Flight Computer" (Higher level *nix based computer running autonomy software), and the flight computer is IMO a more appropriate place to put this.

You could encrypt any Mavlink or proprietary protocol at the application layer if you're using an IP link, or you could also just rely on the telemetry radio to perform encryption between the drone and your ground station.

That was my thought, at least one of those packets in their snooping (src. port 14551 / dest port 14550) is the standard Mavlink port to send to the GCS.

I wonder if the proprietary packet they decoded here is actually just a MAV_CMD_DO_SET_MODE setting the drone into a takeoff flight mode.