UFO: A Drone/UAV Programming Library for Rust | Hacker News Reader

UFO: A Drone/UAV Programming Library for Rust

github.com

121 pointsformalsystem37 comments

Is anyone working on flight controllers in Rust? Now that the STM targets are maturing it seems like a perfect target. I can only find stub projects and blog posts right now.

I've been on sabbatical for a while but a while back it was pretty much C, C or C.

there is https://github.com/copterust/, it's somewhat flying, but still a lot of work. we're in process of porting f3-eva repo to rtfm, so a lot of things are different now, and we have to rethink and reimplement a lot.

we also working on writing drivers and supporting libs as we need them: we've implemented drivers for accelerometers, magnetrometers, pressure sensor, tof sensor, and ported dcmimu algorithm to rust.

This is amazing and exactly what I was looking for, thank you! I had trouble finding it because I was searching for "quadcopter" and not "quadrocopter," I think.

A low level flight controller needs only statically allocated memory, so one of the main benefits of Rust is irrelevant. The syntax is still nice though.

And the much more stringent error checking, as I don't want a null pointer making my quad mow people down.

> so one of the main benefits of Rust is irrelevant

Not sure what you mean with this comment. Even in a context like this, Rust has a lot of safety benefits, but yes you don't have access to the stdlib, and are restricted to core.

I think parent meant "one of the main benefits" = safety not as useful because anyway no dynamic allocations are needed to implement a basic flight control algorithm.

It also helps with other references, shared mutability, UB, etc.

Allocation and deallocation focuses on small sliver of safety, but yes, That’s not a concern in that context.

There was a comment in another thread that talked about the benefits of using the ownership mechanism to control access to all the I/O. It's possible that Rust is useful to manage not just memory, but all kinds of hardware resources.

As someone who has reviewed, debugged and fixed ton of issues in embedded code before, I strongly have to disagree. There are tons of memory issues that can also happen without dynamic allocations. Invalidated pointers to the stack are a prime example. Multithreading issues (on an RTOS) another one. And forgetting to release resources (e.g. a RTOS mutex lock) is yet another one.

Yes! I'm founder of a start-up (about 10 employees now) that makes flight controllers for Drones, and all the software that runs on them is written in Rust.

We don't use STM chips though. Since the way we do state estimation and fault tolerant control requires a lot of computational power, we settled on 64-bit ARM Cortex A series processors. Since there was nothing available that fit our requirements, we produce the hardware ourselves as well.

When we started a bit more than two years ago, we started in C++, but have been slowly switching to Rust starting less than a year later. Now that everything is in Rust, our productivity went up a lot, together with the reliability of our systems (which is our main selling point).

The thing we miss most from C++ is the Eigen library, but the alternatives in Rust are pretty okay, though less complete. We are adding features and optimizations to some of these libraries, which we'll publish open source in a few months probably.

Do you have a website?

We do, but it's very minimal for now: https://dronesforwork.nl/

We'll be changing our company name in a few weeks, followed by the launch of a new website which should have a lot more information than the current one.

Me and the company I am at are on the fence with Rust because the type system still can't do Eigen but probably will eventually. I worry all of the current array libraries for Rust will go obsolete in a year or ten and Rust will only then start building up a convincing ecosystem for numerical computing.

Getting const generics finished up is on this year’s roadmap.

Cool! I knew it was being worked on; I look it up every few months but keep forgetting the name. RFC 2000 const generics. Any talk yet of a standard ndarray type once that lands? C++ doesn't have one and numeric library compatibility really suffers. Python has one (the buffer interface basically blessed numpy arrays). At our shop python is our glue language mainly because you can pass data between libraries and expect it to work and work efficiently (without unnecessary copies).

Yeah, it’s taken a lot of work to get it going, It we might even have an implementation soonish!

I don’t know how soon ndarray will adopt it. We’ll just have to see.

Yes, this was our main worry as well. At first we switched to Rust only for the lower level code, the parts that interfaces with sensors and the motors, that do the data logging, our inter process communication library, etc. The part with the control algorithms (where all the interesting linear algebra code is) was still in C++ until recently.

For all the small vectors and matrices, things like Vector3 and Matrix3x3 from nalgebra work fine. A few generic things we had to change from statically sized to dynamically sized arrays/matrices, but since these were rather big already, the difference in performance was neglegible. The type safety was maintained by directly wrapping those in a generic struct where the template parameter describes the contents of the matrix or vector. Such template parameter is basically a struct where the members describe the meaning of all the columns/rows of the related vector/matrix. A custom derive proc macro generated the conversions to and from this type (which are all optimized away by the compiler). It looks something like this:

    struct Foo<T: VectorLike> {
        matrix: DynanamicallyAllocatedMatrix<f64>,
    }

    impl<T: VectorLike> Foo<T> {
        fn new() {
            Foo { matrix: DynanamicallyAllocatedMatrix::zeros(T::N, T::N) }
        }
        fn get_diagonal(&self) -> T { ... }
        ...
    }

We were already doing something like this in C++, but with some hacky preprocessor macros instead of Rust's procedural macros.

In the end, keeping track of the meaning of the entire vector/matrix in the type system provides us with even a lot more safety than only keeping the size of them in the type system. And it has the advantage that you don't need const generics, since you're keeping track of whole types, and not just numbers. The downside is that we have to maintain a few procedural macro implementations.

Seems cool, especially since I know nothing about programming drones. I was glancing through the code, and ibwas wondering if there was particular reason you split flight commands into UDP and camera controls into TCP. As I said I know nothing about drone programming, sorry if it is obvious.

Hi, Not the maintainer of the above library, but this seems similar to a reverse engineered library for a couple of other chinese wifi quads.

Someone created a chrome app for their specific model a couple of years ago, and their notes are available here [1]:

> The commands are simple 8 byte packets sent continuously over UDP.

> The drone creates an unprotected wireless network and streams live video to an android or ios app named 'RC-Leading' (there are dozens of near-identical apps from the manufacturer)

> The drone's IP is always 172.16.10.1

> I've captured the communications between the drone and app and there seems to be several rounds of back and forth of ~100 bytes worth of non-intelligible data over the TCP 8888 port before the video streaming begins (I assume this is some kind of app level handshaking)

> It streams unencrypted video over TCP port 8888 (I can view video frame info using ffprobe on captured packets)

There was a similar hackaday project for this [2] and some of their notes are at [3]:

1) https://www.reddit.com/r/HowToHack/comments/4512il/how_to_ha...

2) https://hackaday.io/project/56102-reverse-engineering-a-dron...

3) https://steemit.com/drone/@highonapples/reverse-engineering-...

(edited for formatting)

This is awesome!

If anyone is interested in the software side of things, we have a fabrication team and facility in the Pittsburgh area (proximity to CMU) right near an airport. Early stage exploration of building personal transport drones.

Looking into a cooperative / holocracy type model. We could use some strong engineers in our group!

What hardware is required for this?

As the README indicates, this is a networking client library to control JJRC H61 drones over their built-in network control protocol, with the goal apparently being to abstract over the control protocol for a variety of drones.

would love to talk to anyone that is big into drones and video. live streams of builds, etc.

here is our old video of maiden flight https://twitter.com/copterust/status/1024724881680867328

Does it work with the 3dr solo?

No, but https://github.com/3drobotics/rust-mavlink would. The enterprise version of Solo actually ships with a Rust app running on the onboard computer for camera control, which uses rust-mavlink to talk to the autopilot.

thanks!

Reply on news.ycombinator.com