Hi everyone,
Some of you might have heard about the work we did with BeaglePilot porting APM to Linux both in the hardware and software side. Work we presented at LibreCon 2014 last month.
I am happy today to announce that after several months of improvements, flight tests and pre-series with manufacturers we are launching a commercial Linux hardware autopilot based on this work: Erle-brain.
Erle-brain is sold at 269 € and puts together a BeagleBone Black (rev. C) and the PixHawk Fire Cape in a single package that weights about 110 grams and includes 25+ sensors. The hardware designs are open to anyone that wishes to improve them.
The autopilot has a 4 GB eMMC flash memory that comes pre-flashed and provides:
- Linux 3.8 kernel compiled with the PREEMPT option (best results we measured)
- Debian Wheezy file system
- ROS Hydromedusa
- mavros ROS package
- APM running natively in Linux (and linked with ROS through mavros)
- preconfigured daemons for launching everything automatically, WiFi dongles support
Erle-brain has been successfully tested in copters, planes and rovers. Thanks to the contribution of many there're drivers for most of the sensor and we keep working hard to provide support for even more accessories. Here are some of the ones we've been playing with:
Expect more to come :).
Besides doing some hardware hacking we've also been putting time in documenting everything. The APM wiki is great and we love it but we wanted to do it our way so we've spent quite a bit of time creating GitBooks that should provide a walkthrough no matter which is your technical level:
We expect to come up with more material in the next months. Thanks everyone for your support and contributions. We will keep working hard to create amazing Linux autopilots.
Best regards,
Víctor.
Comments
Congratulations Victor, this is a great step towards having more control over drones and be able to do real life projects.
andreu from Lleida Drone.
@Víctor Mayoral
That's a great explanation, Victor!
I'd also like to note that using powerful microprocessors instead of microcontrollers allows for better but MIPS-hungry flight algorithms.
APM has already outgrown Atmega resources and will outgrow STM32 resources some time soon.
Merry christmas to everyone and thanks for the discussion! I'm sorry I have not been more responsive, jetlag and family are keeping far from computers.
I managed to save a few hours to reproduced some of the tests that we did last summer with Michael's comments (I appreciated the pointers btw. It indeed helped). Before i share the results let me start justifying why we chose the vanilla with the PREEMPT_CONFIG option and why we believe that Linux autopilots are the future and reliable:
First off, the discussion with regard making the Linux kernel real time is an issue that has gone for long. There's some people claiming that there's no way to make such a system "hard realtime" (there's more here about the different realtimeliness). Many justify so pointing the complexity of the Linux kernel and some choose to use microcontrollers to get a deterministic and more controlled environment.
The fact with an autopilot is judging whether we need hard-realtime or not. If we look at current autopilots such as the PixHawk or the APM2 and we enable debugging options in the scheduler (described here for Erle-brain) you will all see that the scheduler misses deadlines, quite a few depending on how you configure your system.
So, do we consider an autopilot a hard-realtime system? Clearly it's not been that way and all the flight controller you gentleman are using do not do so. Let's assume (as we did months ago) that we can use the hypothesis that an autopilot should be "soft-realtime" (the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service). Given this scenario we need to define nicely the maximum latencies we should comply with. E.g.: if the autopilot loop is running at 50 Hz then each loop should take no longer than 20 ms. If it's 100 Hz then we'll need to meet a 10 ms maximum latency. This was our initial point.
Our target initially was to use the PREEMPT_RT (set of patches, CONFIG_PREEMPT_RT). We did so as well as other options such as the CONFIG_PREEMPT option available in the mainline kernels (no need to patch):
If we refer to the Real-Time Linux Wiki:
It initially seemed that CONFIG_PREEMPT_RT was the right way to go but we kept ourselves open to all the options. We tested it and we got the results presented in the paper. Surprisingly CONFIG_PREEMPT did better! I was not honestly expecting this but we moved on with that kernel.
Besides the experimental results we also reached the BeagleBoard community and some of the RT Linux developers that explained that the RT_PREEMPT patches are not "that well" maintained and furthermore the integration with new kernels always takes a while and is troublesome. The CONFIG_PREEMPT is already in the mainline kernel so it's pretty comfortable. In any case if you are still supersticious we have the kernels (and modules) available so you can install the one you feel more comfortable with.
I reproduced the stress tests using the CONFIG_PREEMPT (PREEMPT) kernel and stressing the system. The results are briefly presented here. (In case somebody misses the "--hdd" option in the stress tests (or a higher "--vm") the BBB runned out of memory as soon i increased this value).
The meaning of these results is that even in a stressed situation (feel free to point out whether it's stressed enough or not. I believe so) Erle-brain maximum latencies are actually good taking in account that for APM runs at 100 Hz. Furthermore i've been monitoring the autopilot with MAVProxy through the whole process and it has behaved pretty much the same. A few cycles are not met (as expected) and the max. latencies are close to 20ms.
Let me now discuss some of your comments:
This is a misleading comment. Of course we addressed this matter setting the priority of the threads of APM above all the userspace tasks. Take a look at this material i just grabbed from my boad.
@Michael unless you code your web servers with FIFO scheduling and a priority above the APM threads this will not happen.
@Kabir indeed having Ethernet is a great (great) advantage. The BBB does not support gigabit but i can think of many scenarios were 10/100 T is more than enough.
This a good point. I am optimistic that the latencies won't be that critical but i don't have data enough to justify it. What i can argue is that i'm pretty sure that the latencies would be worse with a companion computer connected through a serial port (e.g.: UART) which is the case of many users now.
ROS in the autopilot would bring many advantages. After spending about 6 months at the OSRF and seeing the kind of projects with drones we faced, i can just admit that having ROS out of the box in the autopilot would just be awesome.
We tested it to the best of our knowledge and the responses are good. FIFO scheduling works really nice with standard PREEMPT.
Given the fact that we are using the PRUs mainly for PWM generation and RCInput processing i'd say it's highly possible to make a Linux autopilot without them. I'd love working in something like this unfortunately our funds can't allow us to hit so many options in parallel. We will eventually reach it but If anyone has the capital and wishes to speed/fund it we would be delighted to consider it ;).
@Kabir we've shipped boards over the last 2 months the main APM developers. If anyone has the bandwitdh and interest in testing the system feel free to write me at "victor at erlerobot.com". We can probably arrange a few more samples.
Someone is doing so and it's a valid approach. I'm eager to compare the systems but I still envision a full Linux autopilot as the future.
Think for about any interfacing with the flight controller (a microcontroller), or the continuous addition of features and how complicated is coding for the current NuttX approach. I feel comfortable enough with it to admit that any modifications should now done by experts such as Randy or Tridge limiting the number of contributions to their bandwitdth. A Linux autopilot would probably speed up things. Much more. We are making partnership to do so.
Nice board! I'm looking forward to seeing where this project goes. Let the horses nay.
@thomas Butler
There is an vibrant discussion here about the merits of using Linux for non essential FC processes. The best you could do was to call someone a 'moron' because you think the name was not original enough. I think a moderator should remind you of the etiquette here.
This is great work Victor, but I'm also concerned about the decision to run non essential/experimental tasks on the same hardware as the safety critical flight control systems. Further, using the PRUs seems to restrict the software to the BBB which defeats the purpose of implementing in Linux in the first place. I won't elaborate much more as this has been covered in previous posts and these concerns were raised by myself, and others, at the beginning of the project.
To me, the fix is simple - add an STM32F4 to the cape in the same configuration as Pixhawk and use the BBB as a companion computer for higher-level experimental algorithms. If anyone's interested, this video shows some of my work on vision-based close formation flight using 2 x custom BBB autopilot capes with similar hardware to Pixhawk and an Odroid maxed out for the vision. The BBB are running experimental formation guidance and navigation algorithms.
1. I agree 100% with the fact that its easier to interface to a second companion computer, but that sort of defeats the purpose of having the autopilot itself as a computer. Also, ethernet cannot match UART performance when it comes to tightly-coupled systems. Initially I was interested in Linux autopilots because of the fact that I could directly patch them through to my in-vehicle gigabit network.
2. Perhaps it would be fairly okay for use-cases you cite such as running a web server, which could be run on a GCS anyway. Running ROS on the board would again be fairly useless, unless you you could actually do a useful task, for which we again need a companion. A ROS node running on the Erle simply offboarding data to a companion would again introduce system latency and give no advantage.
3. FIFO scheduling behaves differently under RT and non-RT (standard PREEMPT) kernels. Have you extensively tested this?
4. Your load testing should be more comprehensive. To get a product out, especially which is dangerous to people around, you absolutely need to test the system to the breaking point to make sure you got the corner cases. CPU loading without IO and memory stress isn't bulletproof. Moreover, you need to overload the system instead of simply limiting it to a threshold. OpenCV does this pretty well without even trying :/ Pretty inefficient.
5. I was talking about running camera capture in flight to simply demonstrate a simple-use case which most users would want from a linux integrated board. Capturing frames at a high-resolution to disk is a pretty good stress test in itself.
6. A use-case involving ROS control presently requires large changes to APM middleware, which doesn't target a research audience. This is something you need to think about. Even a simple OpenCV example will not run decently onboard. So the question you need to ask here is, what advantages does this give over what we have now?
7. The matter of BeagleBoard moving to a PRU-less chip.
It would be great if you loaned out 1-2 boards to independent developers for testing and pushing them to the limits. I would have brought one myself for testing, but I'm not willing to spend a premium which I cannot yet justify myself.
Neat feature. So this drone can be made to crash remotely, by overloading web server with requests?
"stress command creating as much load as possible"? I think you have a bit of learning to do before trying to implement flight control software. Like, actually reading man pages for "stress", "uptime" and "vmstat"
Genial trabajo Victor! Enhorabuena!
Great work! congrats!
-
2
-
3
-
4
-
5
-
6
of 9 Next