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.
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.
Which is… never trivial. I’d say 25-50% of my career so far has been repeatedly “fixing” clunky deployments of ROS, OpenCV, L4T, CUDA, cudnn, libc, etc. in Docker and Nix. Fun stuff!
There's actually two completely separate games (Java edition and Bedrock) that can't cross-play with each other. You can buy a Bedrock edition Minecraft for Windows that should be able to cross-play with the switch.
Java Edition is the original game and it's fairly easy to either host your own server (The dedicated server is just a .jar you run) or pay for a server ($10-40/mo) using a game server host.
There are lots of companies using NixOS for this, BalenaOS (Yocto + Docker), or building their own bespoke tooling on top of a minimal Linux setup.
Although many places start with Ubuntu or Debian in my experience it’s common to invest a lot of time and energy in getting out of that unmanaged setup once the company scales.
This is great. I can't count how many times I've setup an ad-hoc Slack bot that posts to a channel using the API. Each time it's usually the same, a lot of boilerplate to handle each platform's event stream and get the block layout looking nice in Slack.