motivating research concepts

embedded sucks

for anachronistic, unnecessary, solvable reasons

• no os and c/c++ are basically not reusable / this is such a pain that people don't do it, and when they do, it's very poor quality

• or you have an rtos and are locked into their ecosystem

• rust is great

  • a language package manager, wow
  • many usable #![no_std] libraries
  • no vendor lock-in with rtos -- embassy is the most central thing, but almost all of the components work independent of any runtime
  • it's still a pain in the ass to setup (hence molybdos)

• there are a bunch of very low cost microcontrollers ($0.10) out there. it often makes sense in an embedded project to offload work to another processor, but usually a single mcu only has one core. so add more! but you often need to write your own primitive networking stack to have them talk to each other, and that integration complexity makes it not worthwhile

  • however, we've solved this problem already. we have a lot of mature networking standards and software, and the reason they're not on embedded is how people wrote them and how they're packaged, not that they're not fit for purpose
  • in rust this isn't an issue -- look at embassy_net, embedded_nal, and smoltcp. these are intentionally intercompatbile networking interface definitions that are a de-facto standard for embedded rust.
  • hence interstice -- embassy already has a ppp implementation that wraps embedded_io_async::{Read,Write} types (e.g. UARTs), we just need a packet switch to bridge multiple L2 links

• what else is nice? just having an operating system -- then you don't need a different software kind for bare-metal

  • Ox64 + elixir + rust

minimum cost hardware

• lots of "open source hardware" publishes the schematics and firmware but not the board design. this is a fine model but it also means there are a lot of designs out there that are way more expensive than the components and in reach for to relayout (optionally publish) and use for myself

  • e.g.:
    • vesc
    • crazyflie
  • basically, it's not really open source hardware if it doesn't have a bom and design files — should be a single digikey order + basically 1 click from jlc

• embarassingly parallel physical problems

  • drones suggest themselves as the obvious thing
  • "beach cleanup"-type -- keep adding units with simple logic
  • rts control -- 2.5d paradigm

• drone swarms for useful work

  • so far they don't do this -- only single-operator or preplanned missions

• dumbing down drone control

  • what is an actually-useful mvp for a drone swarm?
  • things only need to be able to see "good enough" and share information
  • super high-fidelity is probably not that great

• ...