7 ms·

Raspberry Pi inspired autopilot

110 points by ivereninov 12y ago

nacnud 12y ago
How do the power requirements for the autopilot compare to that of the rest of the flight hardware?
- asynchronous13 12y ago
  miniscule. The electronics will consume a few watts, the main motors will consume several hundred watts.
Jeandon 12y ago
Looks very nice. Is Linux actually real-time enough to run autopilot code?
- klinquist 12y ago
  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.
  - ivereninov 12y ago
    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.
    - klinquist 12y ago
      Very interesting, thanks!
- CHY872 12y ago
  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.
  - ivereninov 12y ago
    We run APM on Linux. The port to Raspberry Pi is our effort and it is now supported in APM upstream.
    - 3327 12y ago
      what is the % impact on endurance?
      - VereninovIgor 12y ago
        Raspberry Pi A+ with Navio+ consumes about 200mA. Compared to running motors this is almost nothing.
- pjc50 12y ago
  It's fast enough in almost all cases to work. "Realtime" is more about proving worst-case bounds on all control loops.
- lovelearning 12y ago
  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/ http://www.emlid.com/raspberry-pi-real-time-kernel/ [2]: http://www.emlid.com/navio-apm/ http://www.emlid.com/navio-apm/
- asynchronous13 12y ago
  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.
- valarauca1 12y ago
  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.
  - lsaferite 12y ago
    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.
    - valarauca1 12y ago
      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.
- MegaDeKay 12y ago
  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-of-ardupilot http://diydrones.com/profiles/blogs/a-peek-into-the-future-o...
  - 2bluesc 12y ago
    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.
    - mavkhimenia 12y ago
      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.
klinquist 12y ago
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.
- ivereninov 12y ago
  Exactly! We are working on this and will include a very easy to use LTE streaming configuration for HD FPV experience.
  - shoggs 12y ago
    Is it actually possible to fly FPV with that much of a delay?
    - Phlarp 12y ago
      It's probably possible, but it won't be easy or at all fun compared to a non-packet-switched analog feed.
    - zo1 12y ago
      Why would there be large delay? Am I missing something that you'd care to fill us in on?
      - Phlarp 12y ago
        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.
        mavkhimenia 12y ago
        The delay with Raspberry Pi camera module and proper LTE\WiFi link is much less - it's around 100ms.
bhhaskin 12y ago
This is awesome! How much weight does it add compared to traditional autopilots?
- igorvereninov 12y ago
  Thanks! Additional 23 grams for raspberry pi A+
  - bhhaskin 12y ago
    Not bad at all considering all of the extra processing power.
mjs7231 12y ago
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?
- igorvereninov 12y ago
  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?
  - Phlarp 12y ago
    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?
    - igorvereninov 12y ago
      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.
    - lovelearning 12y ago
      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.
  - eots 12y ago
    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.
NietTim 12y ago
I have thought about doing this before, but figured this would be too heavy. Guess I was wrong, very cool!
nakedrobot2 12y ago
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)
- igorvereninov 12y ago
  It runs on 32bit ARM at up to 1GHz with 512MB of RAM. Completely different league.
- Quai 12y ago
  APM is powered by a 8 bit controller.
tomswartz07 12y ago
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?
- mavkhimenia 12y ago
  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.
  - scoot 12y ago
    > 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.
    - mavkhimenia 12y ago
      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.
Alupis 12y ago
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/ http://www.raspberrypi.org/products/model-b-plus/
deleted 12y ago
[deleted]
gadders 12y ago
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 http://aardvark.co.nz/pjet/cruise.shtml
- Alupis 12y ago
  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_1035369_prd1.htm http://www.hobbyexpress.com/senior_telemater_plus_drop_box_1...
- tomsunax 12y ago
  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 https://www.youtube.com/user/RCModelReviews (educational) https://www.youtube.com/user/xjet https://www.youtube.com/user/xjet (fun stuff)
- pjc50 12y ago
  Ssh, this is going to happen sooner or later and result in quadcopters being banned forever. :(
zo1 12y ago
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+?
- VereninovIgor 12y ago
  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+.
simpsond 12y ago
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?
- igorvereninov 12y ago
  Did not help us much(since we are working with spidev and i2cdev), but did not cause much trouble either.

110 points by ivereninov 12y ago

nacnud 12y ago

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

asynchronous13 12y ago
miniscule. The electronics will consume a few watts, the main motors will consume several hundred watts.

Jeandon 12y ago

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

klinquist 12y ago
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.
- ivereninov 12y ago
  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.
  - klinquist 12y ago
    Very interesting, thanks!
CHY872 12y ago
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.
- ivereninov 12y ago
  We run APM on Linux. The port to Raspberry Pi is our effort and it is now supported in APM upstream.
  - 3327 12y ago
    what is the % impact on endurance?
    - VereninovIgor 12y ago
      Raspberry Pi A+ with Navio+ consumes about 200mA. Compared to running motors this is almost nothing.
pjc50 12y ago
It's fast enough in almost all cases to work. "Realtime" is more about proving worst-case bounds on all control loops.
lovelearning 12y ago
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/ http://www.emlid.com/raspberry-pi-real-time-kernel/ [2]: http://www.emlid.com/navio-apm/ http://www.emlid.com/navio-apm/
asynchronous13 12y ago
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.
valarauca1 12y ago
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.
- lsaferite 12y ago
  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.
  - valarauca1 12y ago
    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.
MegaDeKay 12y ago
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-of-ardupilot http://diydrones.com/profiles/blogs/a-peek-into-the-future-o...
- 2bluesc 12y ago
  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.
  - mavkhimenia 12y ago
    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.

klinquist 12y ago

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.

ivereninov 12y ago
Exactly! We are working on this and will include a very easy to use LTE streaming configuration for HD FPV experience.
- shoggs 12y ago
  Is it actually possible to fly FPV with that much of a delay?
  - Phlarp 12y ago
    It's probably possible, but it won't be easy or at all fun compared to a non-packet-switched analog feed.
  - zo1 12y ago
    Why would there be large delay? Am I missing something that you'd care to fill us in on?
    - Phlarp 12y ago
      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.
      - mavkhimenia 12y ago
        The delay with Raspberry Pi camera module and proper LTE\WiFi link is much less - it's around 100ms.

bhhaskin 12y ago

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

igorvereninov 12y ago
Thanks! Additional 23 grams for raspberry pi A+
- bhhaskin 12y ago
  Not bad at all considering all of the extra processing power.

mjs7231 12y ago

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?

igorvereninov 12y ago
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?
- Phlarp 12y ago
  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?
  - igorvereninov 12y ago
    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.
  - lovelearning 12y ago
    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.
- eots 12y ago
  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.

NietTim 12y ago

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

nakedrobot2 12y ago

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)

igorvereninov 12y ago
It runs on 32bit ARM at up to 1GHz with 512MB of RAM. Completely different league.
Quai 12y ago
APM is powered by a 8 bit controller.

tomswartz07 12y ago

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?

mavkhimenia 12y ago
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.
- scoot 12y ago
  > 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.
  - mavkhimenia 12y ago
    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.

Alupis 12y ago

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/ http://www.raspberrypi.org/products/model-b-plus/

deleted 12y ago

[deleted]

gadders 12y ago

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 http://aardvark.co.nz/pjet/cruise.shtml

Alupis 12y ago
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_1035369_prd1.htm http://www.hobbyexpress.com/senior_telemater_plus_drop_box_1...
tomsunax 12y ago
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 https://www.youtube.com/user/RCModelReviews (educational) https://www.youtube.com/user/xjet https://www.youtube.com/user/xjet (fun stuff)
pjc50 12y ago
Ssh, this is going to happen sooner or later and result in quadcopters being banned forever. :(

zo1 12y ago

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+?

VereninovIgor 12y ago
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+.

simpsond 12y ago

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?

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