Writing a flight controller for drones in rust

community
1

Rust is the perfect choice to write software in the form of either firmware for drones or one level above that, flight controllers.

Have there been any projects that aimed at writing either:

  • low level firmware for speaking to the rotors and in general enabling flight
  • high level libraries that allow for writing autonomous flight programs

As you might realise, I have very little clue about actual drones, so any improvements to this post are welcome.

Also, the goal is to get a discussion started around writing or contributing to these areas.

Kind regards,
Adrian

7 Likes
2

Most of the people doing FC work are using C on bare metal, possibly using the Arduino HAL. All the boards I know of that run open source firmware are in that category, though I've seen some talk of using things like a raspberry pi

If I were going to do this I'd start with one of those boards, and rewrite subsystems in rust one at a time. So you'll need to be familiar with embedded systems development, ARM processors (there are some atmel 8 bit boards around, but they are obsolete and last time I checked the Rust builds didn't support atmel cpus). You'll want an embedded library of some kind. Zinc used to be the choice, but last I heard it was no longer under active development. If you want to get started cheap, the floureon h101 had been hacked and there's open firmware for it, and you can find those for about $9 on sale. I'd probably start there, but I already have two of them running that firmware.

3

Disclaimer: I haven't actually piloted a drone before but I have
(non-professional) experience in control systems, robotics, electronics, and
embedded software development.

Have there been any projects that aimed at writing either:

I haven't heard of any so far.

low level firmware for speaking to the rotors

This is trivial to do. The motors powering the rotors are always attached to a
ESC (Electronic Speed Controller) that has some form of processor in it that
controls (using a PID controller or similar) the motor; the microcontroller only
has to command them using PWM (Pulse Width Modulation). Most microcontrollers
has hardware support for PWM and writing an API to control the rotor (forwards,
backwards, speed) can be done in probably about 100 LoC.

in general enabling flight

This is a way more complicated. Now we are talking about interacting with
sensors, which you have to calibrate beforehand, and running a (PID) controller,
which you have to "tune" beforehand, all with possibly real time requirements,
so you may want to throw in a real time OS (RTOS), just to get your drone
hovering still in the air without crashing to the ground just because of an
occasional breeze.

Now we are in the order of thousands of LoC that involve not only software
development but control engineering.

high level libraries that allow for writing autonomous flight programs

What sort of autonomy are we talking about here? "Follow this predetermined
path", "Follow this predetermined path minding your surrounding so that you
don't actually crash with an obstacle", or "Follow this person around".
Hardware-wise, the first two seem doable with just one microcontroller if they
don't involve a camera. Anything that involves a camera will probably require an
additional processor running at hundreds of MHz. Algorithm-wise, the first
seems like a solved problem; for the other two you probably want to look into
some recent research on path planning and image processing.

Also, the goal is to get a discussion started around writing or contributing
to these areas.

I'd suggest the same thing as @mwm: Focus on a single existing platform and get
something working (a monolithic application is fine) before thinking about
supporting other boards, micros, sensors, etc or even building high level
libraries.

This is how I would go around developing a MVP.

Disclaimer: I haven't wrote a flight controller before.

  • Pick a platform, a flight controller. I'm talking about the elecronics. Pick
    something with an ARM Cortex-M processor in it because that's what Rust
    supports right now. I'd also recommend a processor with hardware support for
    floating point math as lots of math are involved in the control system. The
    actual rotors, motors and ESCs seem less important as they all are controlled
    in the same way. Having the same microcontroller and sensors is more
    important.

  • Write code to manipulate the registers. The so called register maps. This
    involves a lot code but thankfully it can be automatically generated from SVD
    files using a tool like svd2rust or svd-mmap.

  • Write drivers for the sensors and the ESC. This is going to involve dealing
    with peripherals like I2C, SPI and PWM but you only have to read the reference
    manuals to do this part. At this point a blocking API is fine.

  • Then look into the calibration of the sensors and the ESC. Calibrating the ESC
    is easy as there is a predetermined protocol for it. Calibrating the sensors
    is more involved as it requires quite a bit of math (matrices).

  • Develop digital filters for your sensors. This will likely require "real time"
    plotting of the readings to get a better feel of the amount of noise in them.

  • Look into and implement an algorithm to compute the 3D orientation of the
    board / quadcopter using the sensors as inputs. Something like this.

  • Develop a wireless communication channel between the quad and your laptop.
    Serial over Bluetooth (RFCOMM) should be enough. Something minimal just to
    send commands to the microcontroller.

  • Look into open loop control to get familiar with the flight mechanics: All the
    rotors spinning at the same speed should move the quadcopter up, down or keep
    it still. Figure out what those speeds are. You'll have to input the speeds
    manually using the wireless comm developed in the previous step. This also can
    be used to confirm the calibration of the ESC was successful: sending the same
    PWM signal to the four ESC should make all the rotors spin at the same speed.
    You'll probably need a tachometer for all this.

  • Look into closed loop control just to keep the quadcopter hovering still in
    the air in presence of small perturbations. At this point you want to turn all
    your sensor reading APIs from blocking to async.

  • Look into stable vertical flight: take off and landing. Probably using a
    barometer to get feedback about the height.

  • Look into small sideways movements without crashing and losing height. This
    part scares me the most and will probably be the trickiest to get right.

  • Build a slightly higher level wireless controller. Just using the terminal
    seems fine with commands like left to e.g. move a bit in the minus X axis.

At that point the project would be mature enough to be called a MVP, IMO, though
it's nowhere near done.

IMO the hardest part is the control engineering: figuring out the right
algorithms for stable flight, the digital filters, the calibration of the
sensors and the tuning of the PID controller. The firmware development part,
writing drivers/API for the sensors, seems trivial compared to the rest of the
work that needs to be done.

4 Likes
4

I agree. Fortunately, that's all also available in open source projects, like the floureon software I mentioned. That's why I suggested starting with that and replacing bits of it with Rust: you have something that's flyable (and quite a bit of fun) and inexpensive to learn this stuff on.

FWIW, there's also an avr-rust project which is getting active development. At least, when I pinged them about a problem they promised to look into it after a Rust conference. But I'd still go with the Cortex M series.

I disagree about needing floating point. While on the face of it there's lots of floating point stuff involved, most of it can actually be handled with acceptable accuracy and better speed with fixed point integer operations. Which means you can use a less expensive platform. Not to mention avoiding the problems inherent in floating point arithmetic.

5

the floureon software

got a link? I'm only finding stuff related to CCTVs.

you have something that's flyable (and quite a bit of fun)

I'm a weird person. I find more interesting building stuff from scratch that starting with something that works. :smile: The former provides more hours of "fun" as well.

FWIW, there's also an avr-rust project which is getting active development

I'm aware. I think they are mostly done with LLVM upstreaming process. Last time I checked there's only one LLVM "PR" pending to be merged. We'll hopefully have something in tree before the year ends. Perhaps, by Christmas.

I disagree about needing floating point.

Oh, OK. As I mentioned I haven't write a flight controller before so my initial reaction was to use the "standard" representation. But if fixed point arithmetic works well in practice then that's great.

6

Here's the discussion group on rcgroups: Eachine H8 mini acro firmware - RC Groups The post includes links to the wiki, discussion of which quads it works for, etc.

7

What if you just wanted to simulate the action of the remote-control system attached to a drone? Instead of worrying about the naughty bits of the drone's internals and just emulate a hand held remote controller then connecting that emulation software to a sensor unit attached to the drone for additional input?

8

Don't revive old threads just to answer them. If you have a new question, open a new thread.

1 Like