Development Environment

There are two programming languages used in the UFS components, CPP and Rust. The flight computer is meant to be running Ubuntu so it makes things a lot easier if we setup our development environment in ubuntu as well.

Acquisition controller project

The acquisition controller is currently the only project written in CPP, this is mainly required due to the spinnaker library, the currently utilized GenICam library. Most of the dependencies for the acquisition controller project can be installed through the apt package manager, including but not limited to zmq, protobuf, json, etc.

There are still a few libraries that need to be installed from source or custom packaging. Spinnaker is the GenICam library developed and distributed by FLIR. The debian packages are downloadable from FLIR directly and can be installed through DPKG. There's the timezone extension to the date library that needs to be installed from sources directly, same for the dotenv library.

Still in the acquisition controller project, the legacy LUM sdk, lucam, also needs to be manually installed. The library can be downloaded from lumenera's website and the makefile will build and install the library.

The acquisition controller itself is a simple cmake project, which is great for compatibility with CLion, the C/C++ IDE from JetBrains.

Rust projects

The other software components of UFS are mostly written in Rust. Each project can be build individually, but can also be built together from a single workspace. This is achieved by creating a folder with a Cargo.toml which lists all the sub-folders as project members. As example:

[workspace]
resolver="2"

members = [
    "backup-utility",
    "flight-tools",
    "json-logger",
    "primary-app",
    "protocol-buffers",
    "reviewer-server",
    "telemetry-processor",
    "middleware",
]

In the dependencies of the various rust projects, one will find the flight-tools project, the source for this project can be adjusted to pick the local path instead of downloading the git repository on build. This can be achieved by using a git filter, more details on that here.

So with the package manifests pointing to the local version of the library, builds will reflect the code changes made locally if there are any. Once again, the JetBrains IDE can be used to facilitate our development. You will need the rust plugin or the RustRover IDE.

Remote Development

This is an area where personal preference might dictate the exact solution you end up choosing, personally, I found that working from a Windows or Mac workstation is more enjoyable, but as we stated earlier, it is definitely preferable building on ubuntu directly, rather than trying to cross compile and deploy manually.

Fortunately, the JetBrains IDE make that very easy with the Gateway workflow. You can read more about it here but in a nutshell, the remote development setup will run all the compiler, debugger and code inspection features on the target computer, the source code is all kept on the remote computer, but the front end is all rendered directly on the local machine. In this workflow, you need to be able to maintain an ssh connection to the remote computer.