Ferroflow

Ferroflow is the new control software for all Liquid Rocketry projects at the TU Wien Space Team. It interfaces with our custom Engine Control Units ECUs, through our custom LiquidCAN protocol. On the other end, it provides a high-level API for our ECUI, which is the user interface for our ECUs.

Setup

Integration tests: SocketCAN / vcan

Some integration tests talk to the ECUemulator over SocketCAN. For that you use a virtual CAN interface.

Test helper: ferroflow-vcan

For test environments, this repo provides a small helper binary that can be granted CAP_NET_ADMIN once via setcap. Integration tests will automatically use it (if it’s available on PATH) to create/delete vcan interfaces without sudo.

Build the helper (feature-gated; not part of normal builds):

cargo build --release --features test-vcan --bin ferroflow-vcan

Put it on PATH (recommended for tests):

install -m 0755 ./target/release/ferroflow-vcan ~/.local/bin/ferroflow-vcan
sudo setcap cap_net_admin+ep ~/.local/bin/ferroflow-vcan

Manual usage:

ferroflow-vcan up vcan0
ferroflow-vcan down vcan0

Development

Running CI Checks

The repository includes a CI script (ci-rust.sh) that runs all quality checks on the Rust implementation. This script is used both locally and in GitHub Actions

Run all checks:

./ci-rust.sh
# or explicitly
./ci-rust.sh all

Run individual checks:

./ci-rust.sh build         # Build the project
./ci-rust.sh test          # Run tests
./ci-rust.sh fmt           # Check code formatting
./ci-rust.sh clippy        # Run clippy linter

You can fix formatting or linter issues by adding the -fix suffix to the command. e.g: ./ci-rust.sh clippy-fix

Running fmt and clippy as a pre-commit hook

A pre-commit hook script is available in .githooks, which executes the CI script with fmt and clippy only and without the fix option. To setup the hook, configure git to use the .githooks directory and make the pre-commit file executable.

git config core.hooksPath .githooks
chmod u+x .githooks/pre-commit

Database & Diesel

Timescale

We use TimescaleDB, which is an extension of PostgreSQL optimized for time-series data. You can install it by following the instructions on the TimescaleDB installation page. Using docker is recommended for local development (if you already have another instance of postgres running, use e.g. -p 5433:5432 instead of -p 5432:5432):

docker run -d --name timescaledb -p 5432:5432 -e POSTGRES_PASSWORD=yourpassword timescale/timescaledb:latest-pg18

The field_logs migration enables the timescaledb extension before creating the hypertable, so the database user running migrations must be allowed to create that extension.

The project uses Diesel for database interactions. Diesel CLI is recommended for managing db migrations and schema. You can check the official Diesel documentation for installation instructions, or check if your package manager provides it.

Running Diesel CLI Here's some common commands:

export DATABASE_URL=postgres://postgres:yourpassword@localhost:5432/ferroflow # Set the database URL
diesel setup # Set up the database
diesel migration generate migration_name # Generate a new migration
diesel migration run # Run pending migrations
diesel migration revert # Revert the last migration

Diesel Migrations Migrations are located in the migrations directory. Each migration consists of an up.sql file (for applying the migration) and a down.sql file (for reverting it).

Rust schema Since diesel-cli cannot generate a schema for tables without a primary key, we maintain a manually written schema for the field_logs table in src/db/timescale_schema.rs. For all other (future) tables, the schema is (would be) automatically generated by diesel-cli and located in src/db/schema.rs.

Container-backed Tests

Database tests use testcontainers to start a temporary TimescaleDB/PostgreSQL instance in Docker. Running the full CI test step requires a working Docker daemon.

There are two examples in the repository:

• a unit test in src/db/mod.rs
• an integration test in tests/db_logging.rs