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.
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.
(Plus Floodgate so they don't need a Java account)
I just setup a new family minecraft server last week and have successfully hosted java and bedrock players simultaneously (one coming in from a Nintendo switch, another from their phone and several from Java clients).
There are also plug-ins allowing older (or newer) client versions to connect to your server as well (ViaVersion, ViaBackwards).
They're pre-compiled Windows and Linux binaries, but if I'm remembering correctly, I think they're statically linked, and I had no trouble running the Ubuntu one on my Fedora system.
I used to keep a Bedrock server running on my desktop, and my son and I could pop in from a phone, tablet, or laptop whenever we wanted to.
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.
The hardware usually comes with vendor-specific libraries (e.g. cuda in the case of nvidia) which are based on a specific version of libc, so then you will have to build your entire alternative OS around that version also.
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!
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.
Yup. I work a lot with MVTs and one of the headaches is, after you have your nice shiny state-of-the-art maps, turning them back into PNG raster tiles for all the various clients that can't natively render vector tiles.
This link is shrinking though! There's slowly growing support. Leaflet and OpenLayers are fundamentally limited by being canvas-based, so there's only so much they can do.
QGIS has one of the fastest, cleanest MVT renderers I've seen, but I don't know how easy that would be to extract out.
PostGIS is the best platform for generating vector tiles, but it's extremely clunky. On the projects I'm working on (eg https://vectorcharts.com/) I do extensive processing in PostGIS, but then encode to vector tiles in bespoke C++ code.
I got nerd sniped by a tweet talking about JavaScript in SVG, and set out to find out if I could run DOOM inside an image. And it works, with some caveats.
This is technically an SVG that plays DOOM, including audio and interactivity. Pretty cool, although I'm not sure who had the bright idea to allow Javascript in SVG...
The SVG is just using <foreignObject> to create an HMTL namespace, creating a canvas, and then running js-dos / DOSBox in the canvas.
The big caveat, probably a good thing, is that JavaScript in SVG only works if you load the SVG directly and not inside an <img>, since browsers block this as an XSS prevention.
So this is not portable and can't be embedded in a webpage, but I guess was a fun use of a few hours...
> Pretty cool, although I'm not sure who had the bright idea to allow Javascript in SVG...
Is the decision making process public and transparent? Can we find out what committee made the decision, and when? Who the members were and their individual votes?
I was on the Adobe SVG implementation QA team, focused on the javascript testing. I think that comment got some stuff wrong.
Critically, SVG became a W3C recommendation in 2001, but Macromedia wasn't acquired by Adobe until 2005.
W3C was interested in SVG because they wanted a vector image format. They included some stuff for animation, but it was all key-frame based, not scripted. But Adobe was interested in it because they saw it as a way to challenge Flash. So Adobe pushed for the Javascript stuff hard. This was also long before the current browser implementations. Remember that Google Chrome didn't come out until 2008. SVG was supported via a browser plugin you had to install, so if you want any sort of script interaction is needed to be baked into the SVG file itself.
After SVG launched there wan't a huge amount of uptake. Mostly because it was a plugin you had to install. It was also early days on the web, and I distinctly remember members of the working group being flabbergasted that you could generate SVG on the fly, despite the fact that it is just text. So there was clearly a gap between what it could handle and what people thought it could handle. We had evangelists at Adobe, but they could really only do so much.
Adobe saw three key differences between Flash and SVG that they thought would win:
- Flash was frame-based, SVG is all time based. SVG may drop frames, but it could stay in sync with audio. Flash would slow down, stutter, and de-sync if your PC couldn't handle it.
- Flash was a closed standard that required expensive tools to generate, SVG was an open standard with a text format that anyone could generate. Illustrator was able to export to SVG from day one, and Illustrator was not cheap, but it wasn't required.
- Flash is raster, SVG is vector. The vectors are nice for zooming and all, but people didn't really do that.
There were other benefits, like Flash using a proprietary language while SVG used Javascript.
After a few years Adobe saw that SVG wasn't going to be the Flash killer they had hoped for and opted to purchase Macromedia. Personally I think having to install the plugin was too onerous for users, so Flash just had the first mover / incumbent advantage.
TL;DR - They had to include scripting to make SVG interactive because of browser technology of the time and to challenge Flash.
That seems wrong. Having made Flash content in the early 2000's, the drawing tools in the software were all vector-based, and vector-based animation was everyone's go-to since frame-by-frame raster would have resulted in too large an SWF file for the Internet of the time. You could animate bitmap objects also, but they were usually used sparingly, and anyways SVG allows that too.
Ah, mis-remembered that part. Maybe I was under that impression because the clean zoom wasn't something that was exposed to the end-user. Early SVG plugins made zoom and pan part of their UI so it was a little more obvious.
Only appears that way because of the size of the icons representing them (which at the base zoom level are kilometers wide). If it was drawn at real scale the objects would be insignificant.
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.