Introduction

This is RustyFlight, a port of the Cleanflight flight controller to Rust. The code was initial generated by translating Cleanflight into Rust using the C2Rust transpiler, and then hand-modified and refactored from there. This repository consists of the following three major subdirectoris:

• cleanflight: a git submodule referencing our current base version of cleanflight.
• transpiled: a directory containing the basic transformation of cleanflight into Rust, without human modifications. As we may need to understand how changes in the base cleanflight tree effect our running version of RustyFlight, this should be handy.
• src: The source code for RustyFlight, a mix of auto-translated code from C2Rust and hand refactoring.

Platform Targets

At the moment, we care about the following cleanflight targets:

1. SPRACINGF3
2. SITL

As for running platforms, our goal is to support:

1. Software-in-the-loop testing on an x86 platform.
2. Cortex-M boards in general, or rust target thumbv7m-none-eabi

The Development Environment

The Dockerfile in this directory is intended to provide developers with our intended build and test setup, regardless of their host platform. The first step in development is thus to build the docker container. We suggest tagging it as a rustyflight container, to avoid needing to remember hashes:

docker build --tag rustyflight:latest .

[People running Linux may want to also look into podman; the Dockerfile provided works fine with that tool, as well.]

By default, this Dockerfile will set up a user rustyflight with password rustyflight. This user will be provided sudo access (so they can install software as necessary). If you would like to provide a different username, you can do so using the --build-arg command line argument, and resetting USERNAME and/or PASSWORD. Note that if you do not explicitly set the password, it defaults to be the same as the username.

When running commands in this README, or developing on RustyFlight in general, we suggest the following command:

docker run -itv `pwd`:/home/rustyflight/rustyflight rustyflight bash

[podman users may need to add a :Z to the end of the mount (pwd:<dir>:Z) to clean up some SELinux issues.]

This will map the current directory into the container, allowing you to run builds in the container and (a) see the output on your local disk while (b) maintaining the ability to edit files locally.

Rebuilding Transpiled

There are two major steps to transpiling cleanflight into the base version of RustyFlight. First, you must build a version of cleanflight for your desired target, using a tool that will capture the build commands used. Then, once you're done with that, you run the transpiler against the gathered commands. The Docker container should have all the tools use need to do this work:

cd cleanflight
intercept-build make TARGET=SITL

Replace SITL with your target of choice. This will create compile_commands.json in your cleanflight directory. One minor annoyance is that cleanflight appears to use a few compiler and linker flags that the LLVM tools used by c2rust don't understand. The following argument must be manually removed in order for c2rust to correctly operate:

sed -i -e '/save-temps=obj/d' compile_commands.json

Optionally, to get rid of a bunch of warnings, you can also do:

sed -i -e '/fuse-linker-plugin/d' compile_commands.json
sed -i -e '/Wunsafe-loop-optimizations/d' compile_commands.json

Then, from the root directory of the project, run the following command:

c2rust transpile --emit-no-std         \
                 --emit-build-files    \
                 --binary rustyflight  \
                 -o transpiled         \
                 cleanflight/compile_commands.json

This should generate all the code you need for the project. It is useful to redirect the output of this command to a file, because some of the errors get hidden in the long stream of warnings.

In our experience, the resulting code is unlikely to compile, for two main reasons:

1. Duplicated variables; in particular, in cleanflight, we see a lot of duplications of SystemCoreClock. It's not clear why.
2. Missing variables due to failed translations; usually "convert vector not supported". Go back into your c2rst log and see if you can find any errors. If you do, you'll either need to fix c2rust for that problem or simply hand-add the missing symbols.