Conceptually, BlueOS is structured around 4 main components:
To understand how BlueOS is developed, it's valuable to understand what it's made of, and the ideas it has been designed around:
- Containerised components and services (Docker)
- Containerised, individual services are easier to maintain than a monolithic system
- Can restart and update containers with very low risk of needing to re-flash SD card
- Integrators can create their own Extensions, instead of forking the whole system
- Allows Extension and BlueOS version changes without affecting the underlying system
- Dependencies are isolated, so individual services don’t need to compete for versions
- Access to system and hardware resources can be limited per Extension
- Web interfaces and APIs
- Core interface provides consistency, control, and displays active services
- Services display links to API documentation → simplifies development
- Extensions Manager makes it easy to find, install, and manage services from others
- Includes a web store, where Extensions can be downloaded from
- Frontend (Vue.js, Typescript)
- Allows for very reactive components (see heartbeats icon)
- Using reusable Vuetify components to make it look good
- Relies heavily on Mavlink2Rest (rust-mavlink) for integrating MAVLink with web technologies
- Modern backend technologies
- Python (3.9) for simple services
- Rust used for critical services
- MAVLink-Router for MAVLink routing
Docker is a lightweight containerisation system that allows packaging one or more software programs into a single executable that can be easily shared across systems. A static package is referred to as a "Docker Image", and when it is being run it takes the form of a "Docker Container".
A Docker Container generally acts like an isolated mini operating system, but it's possible to enter a running Container from the host computer to see (and modify) what the programs inside are doing, and access things like logging output. Importantly, changes in a Container do not affect its Image, so they're not persistent1 and it's possible to "start fresh" by simply restarting the Container (which creates a new Container from the Image, without any changes from previous instances).
While changes within/to the Container are not persistent, it is possible to make persistent changes to the host's file-system if the Container has access to it (usually via
"HostConfig": "Binds" in the metadata
permissions, or volumes).
BlueOS-bootstrap is responsible for making sure BlueOS-core is running as expected, as well as gracefully restarting core during BlueOS updates and/or if it is detected to have unexpectedly stopped/crashed.
Extensions are individual Docker images that run independently of BlueOS, but can hook into the core systems and host system, providing access to additional devices and data streams, as well as modifying / adding to the web interface.
While BlueOS itself runs locally on the vehicle, there are various cloud-based services involved that allow downloading new BlueOS releases, installing new autopilot firmware, finding and installing available extensions, finding information about BlueOS, and getting support.
Of note are
- The BlueOS-docker repository, where BlueOS-core and BlueOS-bootstrap are developed
- The Blue Robotics DockerHub, where the BlueOS-core and BlueOS-bootstrap Docker images are deployed/hosted
- The BlueOS-Extensions-Repository, where BlueOS extensions are registered and findable from
- The ArduPilot Firmware Server, where autopilot firmwares are fetched from
- The BlueOS documentation (this site)
- The Blue Robotics Forum, where ideas and questions can be discussed
The BlueOS development team have done some presentations about what BlueOS is for, and how it can be used / integrated with. Bear in mind that presentation recordings are snapshots of history, and the information in them gets outdated over time as development progress is made.
BlueOS Development Features
ArduPilot Developers Unconference (March 2023)
Introduction to BlueOS
ArduPilot Developers Unconference (April 2022)