Raspberry Pi Quadcopter

[youtube=http://www.youtube.com/watch?v=TjXvzMdf8Nk&w=470]

It was bound to happen sooner or later, but that doesn’t diminish the awesomeness of [Matthew]’s Raspberry Pi-powered quadcopter.

[Matthew]’s quadcopter is similar to all the other flying drones we’ve seen before with one important difference – all the processing, from reading the gyroscopes to computing exactly how much power to give each motor – is handled by a Raspberry Pi. This task is usually the domain of a microcontroller, as these calculations need to happen in real-time. The Linux distro [Matt] is running on his Pi has a lot more overhead than a simple AVR or ARM microcontroller, so doing everything that needs to be done in real-time isn’t guaranteed. With a bit of clever programming, [Matthew] managed to make sure all the necessary tasks were taken care of in time. It’s still not a real-time operating system, but for this project at least, it’s good enough.

Since the Raspberry Pi in [Matthew]’s quadcopter is much more powerful than a microcontroller, there’s plenty of head room to SSH into the ‘copter while it’s flying. There may even be enough processing power to stream video to a web server; we honestly can’t wait to see what [Matthew] does with his flying Linux computer in the future.

You can check out [Matthew]’s code over on the git or watch a few flight test videos over on his youtube.

 

30 thoughts on “Raspberry Pi Quadcopter

  1. This was done on a non RTOS and yet it works like a charm. This should be the way to go from here on. I see little to no point programming a 32KB flash based microcontroller, barely making it space wise when you could use MBs of memory and a rich programming and execution environment like that of Linux. Good job Matthew for starting this off.

    1. fair point. I was perhaps a bit harsh. I haven’t even checked the code yet. It would be really interesting to see what video capture plays like, as I assume the interrupts will not like high throughput apps running.

    2. How about if you need reliability.

      “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
      -C.A.R Hoare

      1. I’m having trouble agreeing with that quote… obvious to the user or the designer? All deficiencies are painfully obvious to the designer and it’s a LONG list of them. Perfection is a path of diminishing return. The point at which to stop aiming for perfection is debatable, but in my mind one thing is for sure: both simplicity and complexity are overrated.

      2. Hey, creator here.
        I completely agree, the raspberry pi is far from the ideal processing solution for a quadrotor. If I was aiming to design the best flying quad possible I would have just opted for a modern 32bit microcontroller, but that has already been done a thousand times over, so I decided to try something original for the sake of it. Initially I too wasn’t sure if this concept was really practical or worthwhile, but the final platform seems to perform far better than I ever expected. Plus, the friendly dev environment and plethora of available debugging tools really sped up prototyping, allowing me to complete this project in my spare time over only a few weeks instead of spending an eternity wrapping my head around the innards of whichever MCU I chose to use.

        1. Hello,

          You may want to check out Xenomai. This allows hard-real time from linux. I have successfully ported it to a number of embedded ARM CPU’s. I’m not sure if the RPi processor is sufficiently open to do the port. Maybe someone has already done it…

  2. Outstanding accomplishment!!! Without knowing the Raspberry PI hardware but I do know something about Linux, I just have a got feeling using an ARM or ATMega chip for the low level real-time sensor/motor control is a better option and have the Raspberry handle the higher level operation such as navigation, telemetry and video processing. With this said, This is still a MAJOR ACCOMPLISHMENT. Kudos!!

      1. I was thinking it might be better to get a simple MPU, Atmel or whatever, to do the actual motor-controlling, and have slower-changing, more highly abstracted, variable sent to it from the RPi thru a serial link. Use things for what they’re best at.

        Then you’d have a flying Linux platform with nothing to worry about, and could load on all the video and server stuff you liked. I know it’s boring but it’d be a lot easier to handle, especially when you’ve no idea where the bug is that’s making it drop out of the sky.

    1. He knows that and the point was to make an RPi fly which he did. I don’t think an MPU has enough power to do fun stuff while flying like having a real-time video transmission or programming it to follow a complicated paths while avoiding obstacles. Shit, you can even be crasy and attach a kinect to it.

    2. I think the point here is to have a general purpose operating system, which allows to implement software on a very abstract level. We use the same approach in our system and it really helps in debugging, logging and other related aspects.
      Of course, the predictability of code execution is not optimal, but it’s enough to run a 200Hz control loop under Linux. From a software developer’s perspective, there is no way around using an operating system, unless you want to integrate and write any device driver and file system driver on your own.

  3. You should be able to scale-up with the RasPi. Afterall, many of the US military’s drones are running… wait for it… Gumstix. So there’s still an opportunity to quench the haters, if you want, by scaling-up.

  4. The FPV should work relatively OK. I’ve tested 320×240 jpeg 30 FPS stream on Beagleboard-XM and it took about 15% of CPU. With something more complex like h263 the resolution could be much greater however there would be some nasty latency limitations for using the quad as RPV. I’ve tried Beagle’s DSP for h263 encoding but it has not yielded any useful results in latency issue.
    The 320×240/30FPS jpeg stream takes about 200-300 kB/s depending on the compression level.

    1. Beagle has a more sophisticated chip, which includes a DSP that can do realtime MPEG encoding. However, the V4L driver is the bottleneck — it’s crap. It’s not too hard to fix it, though. 320×240 MPEG on beagle can go until the HS USB to the camera is the limitation. I don’t believe the ARM11 on the RasPi is quite so capable, but I bet it would benefit from the same V4L optimizations.

      1. The RPi can do hardware h264 encode/decode on the GPU, too. When the camera board comes out that hooks into the CSI port and feeds directly into the GPU, great things are going to happen.

  5. “The Linux distro [Matt] is running on his Pi has a lot more overhead than a simple AVR or ARM microcontroller”

    This is by far the most senseless sentence i ever read.
    Linux = OS
    AVR = Microcontroller Family
    ARM = Microcontroller Architecture

    and you compare all 3 together…

    1. Nice hack, but I agree with you, I would have used something else to manage the flying and stability with the Raspberry PI doing the complex stuff required of a drone…

      This is one of my future projects as soon as I can get approval for a quad-copter purchase!

  6. I had a raspberry pi 2 and controll KK2.1.5 flight . in this case I want to control KK2.1.5 with raspberry pi with his running through my labtob . whether from you guys can help me ? , I am very happy if these problems there are willing to help and share knowledge to me

Leave a Reply to Matthew WatsonCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.