For those looking at the pictures and thinking "that's not a Raspberry Pi!", it is... under the black Navio+ board is a new Raspberry Pi model B+[1]

[1] http://www.raspberrypi.org/products/model-b-plus/

When I read things like this, it always reminds me of the Kiwi chap that was trying to build a cruise missile in his garage [1]. Although this is smaller than what he had planned, I would imagine you could add a "release" functionality to the Pi Autopilot so it could drop something when at a certain position.

[1] http://aardvark.co.nz/pjet/cruise.shtml

Bruce is very much into quadcopters and other hobby-rc stuff these days. Check out his YouTube channels if you want to see more of him, quite informative

https://www.youtube.com/user/RCModelReviews (educational)

https://www.youtube.com/user/xjet (fun stuff)

That's called a "Drop Box"[1] and they're fairly common. You just need a spare servo to operate the bay door.

[1] http://www.hobbyexpress.com/senior_telemater_plus_drop_box_1...

Ssh, this is going to happen sooner or later and result in quadcopters being banned forever. :(

Using the RPi as a video encoder may be the "killer app" for this. Currently, there isn't a "ready to fly" solution that will encode video and send it out over LTE.

Exactly! We are working on this and will include a very easy to use LTE streaming configuration for HD FPV experience.

Is it actually possible to fly FPV with that much of a delay?

The delay is not that big, around 50-100ms depending on the setup, that is mostly okay.

It's probably possible, but it won't be easy or at all fun compared to a non-packet-switched analog feed.

Why would there be large delay? Am I missing something that you'd care to fill us in on?

Most hobbyist multi-rotor flyers use an analog video feed over 1.2ghz or 5.8ghz radio, which has very minimal lag. Converting the video to a digital signal typically introduces 500-1000ms of delay, which is enough to make flying by the camera difficult or nearly impossible. Transmitting the signal over an IP switched network would likely introduce more lag in addition to the digital conversion.

Ultimately it will depend on which you value more-- response time or resolution.

The delay with Raspberry Pi camera module and proper LTE\WiFi link is much less - it's around 100ms.

Do you all have any plans to shave that further? What might be considered the ideal maximum latency for things like flying obstacle courses(fpv racing)? landing from fpv?

You can use an Android phone with a Propbridge or IOIO board for control (disclaimer: I make and sell the Propbridge), however that is fairly heavy and contains components that you don't particularly care for, like a screen.

That said, I had 2G video off a flying wing in 2010 with this method.

This is very neat!

Has there been any thought about using the 'Compute Model' RasPi? It's the RasPi in the DIMM form factor. Perhaps this would help lighten up the payload even more?

Thanks! We've been thinking of it, but rejected the idea. RPi A+ is quite light, so RPi+Navio weighs as the normal autopilot. Also, A+ is much cheaper.

> RPi A+ is quite light, so RPi+Navio weighs as the normal autopilot

Not to detract from the novelty value of an RPi based flight controller, but if you were involved in the design, you must know that's just not true:

RPi A+: 23g, Navio: 24g, Total: 47g

APM Mini: 7g

That's a significant difference in a situation where every gram counts towards flight time.

The Navio also costs 6X an APM mini, and that's before you add the RPi and power module, which brings it to 8X.

I get why someone might develop this as a hobby project, but I can't think why anyone would buy one.

Navio does NOT weight 24g. It's weight is around ~12g. RPi A+ with Navio = 23+10 = ~35g. Pixhawk weights 38g.

With Navio+RPi you get a lot of stuff compared to hardware like APMMini: network connectivity (LTE, long-range WiFi), affordable 1080p camera module with H.264 encoder for FPV, a lot of processing power for advanced flight algorithms (as an example - a lot of new features of APM such as EKF are NOT available on old APM platforms) and the overall hackability, which you don't get with any microcontroller based autopilot.

How much hacking and/or electronics knowledge is required to set this up and get it running?

#Edit. Another question, will the Reach (when it comes out) integrate easily with the boards coming out in Februaray, and be supported as part of Navio+?

Not much. Write an SD card image, install APM, connect to Wi-Fi or Ethernet and you are ready to go. After that it requires calibration and setup in APM Planner like any other autopilot.

Reach will be a replacement of normal GPS for any autopilot. It will be compatible with Navio+.

Looks very nice. Is Linux actually real-time enough to run autopilot code?

The second PDF in the link below compares the Raspberry Pi with the Beaglebone Black for a next gen APM. The nod went the the Beaglebone because of more GPIO, PWM support, and the two PRUs for realtime operation. The Pi B+ helps the first point, but not the other two. There is also a really interesting page in here on the latencies that are required.

BTW, this was written by Andrew Tridgell of Samba fame.

http://diydrones.com/profiles/blogs/a-peek-into-the-future-o...

Thanks for this. Whenever I see people running around high fiving over the Raspberry Pi, I start to formulate an argument how the BBB would almost always be vastly superior for slightly more cost.

There a lot of boards that outperform BBB 10-20-30x times. But both RPi and BBB are more than enough to run an autopilot code. One of the great advantages of RPi over BBB is 1080p camera module with hardware H264 encoder as well as bigger community.

They are using a realtime patch on Raspbian. [1]

They also say "autopilot’s code works directly on Raspberry Pi using the APM’s Linux HAL". [2]

[1]: http://www.emlid.com/raspberry-pi-real-time-kernel/ [2]: http://www.emlid.com/navio-apm/

A true real time system is likely over kill.

General time-sharing systems generally are accuracy to +/- 4ms. Which is acceptable for most applications, as 60fps is ~16ms per frame.

If you (ab)use Linux properly you can get most your threads to only halt on blocking for IO. So they'll get scheduled practically (not always) once that IO state is satisfied.

This requires heavy multi-threading not horrible, just isn't amazingly optimized for cache.

I control high pressure fuel systems and we don't need to use Real Time OS's (always), and generally sigh away from them when I don't.

I would guess the PID loop benefits greatly from real-time execution. So much so that really the base control system should be on a dedicated controller with AP functionality as a secondary system driving the inputs to the PID controller.

It really depends what you are controlling. With a PID loop generally more accurate timing is the battle cry for moving them off board. As implementing a PID in a time-shared OS is rough as you don't get timing guarantees. So your Delta-T is always off. Generally by a margin of 1% which is large enough to throw off a correctly tuned system.

Faster updates are nice, but not always needed.

Possibly not. It seems that this runs APM, which is an open source autopilot system. On their install pages, the Raspberry Pi is listed as a companion computer (presumably to be hooked to some other device that runs the code) (which this system might not do) but the Beaglebone Black (which I guess is similar to the Raspberry Pi, so might be what they do here) requires installation of realtime patches for Linux.

This works by patching the Linux kernel to make almost all of it preemptable, (replacing spinlocks with mutexes) so interrupts can be acted on more quickly.

We run APM on Linux. The port to Raspberry Pi is our effort and it is now supported in APM upstream.

what is the % impact on endurance?

Raspberry Pi A+ with Navio+ consumes about 200mA. Compared to running motors this is almost nothing.

It's fast enough in almost all cases to work. "Realtime" is more about proving worst-case bounds on all control loops.

Typically, APM/MavLink runs on a Arduino (my Quanum CX-20 quad runs an Mega 2650). This looks like this is a Raspberry Pi shield that I suspect contains an ATmega - so it's not Linux that is doing the flight controlling.

Actually we run APM code ported to Linux, there is no Atmega on the board. There was a lot done to make this possible including special real-time Raspbian. It flies very stable and with great timing performance.

Very interesting, thanks!

Yes. Linux is plenty fast to run autopilot code. There are real-time patches for Linux kernel, but in my experience those are not necessary for decent performance.

Just curious here. The CC3D boards were also open source, hackable, and only 1/3 the price, and guessing, but looks about 1/5th the size. What makes using better than all those downfalls?

This is completely different. Autopilot runs under Linux and that gives incredible flexibility. You can send HD video over LTE, run scripts in flight. SSH to drone in the air, how cool is that?

Yes, SSH-ing to my drone and running scripts while doing low passes and tight turns is just what I need. Sarcasm aside, this looks really cool from a hacker perspective but I'm straining to find a practical use case. Both CC3D and Naze32 platforms are open (hardware and software), smaller in size, cost 5 times less -- but are, I guess, nowhere near as flexible as this thing.

Well, SSHing may be not that useful for those who just want to fly a drone, but it's quite useful for developers, researchers and enthusiasts. Compared platforms are way less powerful and won't be able to perform new advanced flight algorithms, as well as they do not provide easy network connectivity for 1080p H264 video stream from Raspberry Pi's camera module.

Not sure how different it really is.

I have to admit, as someone who is into quads (and embedded software) my first thought was that it would be cheaper to buy a $35-60 CC3D or knock-off dedicated APM module and then just add a Raspberry Pi to the quad as a separate unit. Having the two communicate is a bit more complicated but totally doable via serial if you're willing to hack on APM or OpenPilot code and a lot of the use-cases people are bandying about don't actually need the two units to communicate anyway.

Each approach has it's advantages. Navio was built to serve as a Linux platform for APM which provides more processing power than microcontroller platforms - it's useful for advanced flight algorithms (for example, a lot of new features of APM asuch as EKF are not supported on older APM hardware) and the level of integration between payload apps can be much higher than on two modules with serial link.

Yeah this is a good point, if you are tightly integrating the linux bit to the flight controller bit you will get some benefits here, I was focusing primarily on the topics other people keep mentioning like compressed video feeds which don't require that sort of integration.

It is certainly an interesting project, though personally I'd be more apt to buy/build a BeagleBone Black cape to achieve this sort of thing over a Raspberry Pi board.

How is running scripts (locally?) or SSHing into it over a serial modem any different from the scripting functions or telemetry information available with APM or GCS (CC3D) based systems?

What advantages would the raspi have in streaming HD video over LTE that strapping last years android phone to the drone wouldn't give me?

It is very different.You have a full Linux environment with multiple libraries. It is great for education research and development.

When LTE is not available you can use long range wifi.

700 MHz CPU, 512 MB of RAM, a competent GPU - that's good enough for things like real time terrain image processing on the copter itself.

I'm somewhat intrigued by the HAT spec and how the daughter card provides the OS a device tree fragment. Can you comment on the pains/gains from conforming to it?

Did not help us much(since we are working with spidev and i2cdev), but did not cause much trouble either.

I have thought about doing this before, but figured this would be too heavy. Guess I was wrong, very cool!

How do the power requirements for the autopilot compare to that of the rest of the flight hardware?

miniscule. The electronics will consume a few watts, the main motors will consume several hundred watts.

This is awesome! How much weight does it add compared to traditional autopilots?

Thanks! Additional 23 grams for raspberry pi A+

Not bad at all considering all of the extra processing power.

Is this only 8-bit? That is not really responsive enough.

Currently the best-in-class are naze32 with baseflight/cleanflight firmware (stunt, mini copters) or APM / pixhawk (mapping, cinematography, GPS)

It runs on 32bit ARM at up to 1GHz with 512MB of RAM. Completely different league.

APM is powered by a 8 bit controller.