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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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
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+.
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?
60 comments
[ 4.0 ms ] story [ 126 ms ] threadThis 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.
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/
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.
Faster updates are nice, but not always needed.
BTW, this was written by Andrew Tridgell of Samba fame.
http://diydrones.com/profiles/blogs/a-peek-into-the-future-o...
Ultimately it will depend on which you value more-- response time or resolution.
That said, I had 2G video off a flying wing in 2010 with this method.
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?
When LTE is not available you can use long range wifi.
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.
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.
Currently the best-in-class are naze32 with baseflight/cleanflight firmware (stunt, mini copters) or APM / pixhawk (mapping, cinematography, GPS)
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?
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.
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.
[1] http://www.raspberrypi.org/products/model-b-plus/
[1] http://aardvark.co.nz/pjet/cruise.shtml
[1] http://www.hobbyexpress.com/senior_telemater_plus_drop_box_1...
https://www.youtube.com/user/RCModelReviews (educational)
https://www.youtube.com/user/xjet (fun stuff)
#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+?
Reach will be a replacement of normal GPS for any autopilot. It will be compatible with Navio+.