Skip to content
Developers

Software Architecture

All of Velovision Rearview’s functionality is orchestrated by a single “supreme” server written in Rust.

The two modes of operation are defined by gstreamer pipelines that run as systemd services.

architecture-diagram

Note: This is a software-centric diagram. Hardware features like power management is not shown in the diagram. For example, an SR latch is used to eliminate power draw when the system is off but is not depicted here.

To explore the architecture yourself, you need to log into the Raspberry Pi through SSH.

  1. Turn on Velovision Rearview
  2. Connect to its WiFi network (SSID: Unpaired Velovision Rearview, password: racersaver)
  3. SSH into the device:
Terminal window
ssh velovision-rearview.local

Password is: crazedracersaver

Supreme Server

To see the status of the systemd service that runs the supreme server:

Terminal window
sudo systemctl status velovision-supreme-server.service

Which should output something like this:

🟢 velovision-supreme-server.service - Velovision control HTTP server
     Loaded: loaded (/etc/systemd/system/velovision-supreme-server.service; enab>
     Active: active (running) since Sun 2024-01-14 10:10:48 KST; 7min ago
   Main PID: 675 (supreme-server)
      Tasks: 10 (limit: 716)
        CPU: 6.229s
     CGroup: /system.slice/velovision-supreme-server.service
             └─675 /opt/velovision/supreme-server

This is a simple systemd service that runs the binary supreme-server located at /opt/velovision/supreme-server. The binary is built from the Rust source code in the velovision/rearview repository.

Recall that the supreme server chooses between “streaming” and “recording” modes. Both of these modes are also implemented as systemd services. The supreme server uses systemd to start and stop these services.

The other services are named: velovision-streaming.service and velovision-recording.service. They are meant to be started and stopped by the supreme server.