Overview

#Technology Stack

#Structure

Conceptually, BlueOS is structured around 4 main components:

#Development Infrastructure

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

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 persistent¹ 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).

#Bootstrap

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.

#Core

BlueOS-core is the body of BlueOS, and runs all of the built in services, along with the main web interface.

#Extensions

BlueOS has support for Extensions, which are handled by the Extensions Manager service in core.

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.

#Cloud Infrastructure

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

#Developer Presentations

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.