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
Intermitent connection from Amsterdan :/
@Michael "stress" was launched as "stress --cpu 1" and then "cyclictests" were used to do measurements. Please refer to http://erlerobotics.com/blog/beaglepilot-cyclictests-different-kern.... If this doesn't satisfy your criteria can you point out which way you'd suggest?. I would
@Roberto i head back to Spain.
@Kabir we've flight with the stress command creating as much load as possible and i can assure you that it flies as good as always. The system has been designed so that the threads have priority over the rest of the processes. Please refer to the code and take a look at the fact that all of the threads are marked as SCHED_FIFO.
Also it seems to me that there's a misconception here. The fact that Erle-brain is a computer itself doesn't restrict it from having a companion computer. Actually the fact that it's itself a computer makes it easier to be interfaced with. I would generally agree that for certain (computationally expensive) tasks you definitely want to make use of an additional computer.
Erle-brain can handle more than just the autopilot itself. I've seen myself scenarios that involved networking traffic, the autopilot, ROS and a web server simultaneously. @Kabir we are using GoPros externally but we'll take in consideration your suggestion.
@Hans
I can't either. And we are definitely working towards making a system that doesn't suffer from that. This discussion is indeed enriching. Can you suggest a set of scenarios you'd like to see tested?
I'd have to agree that a non-companion concept seems dangerously flawed from a basic engineering perspective (I do not claim to have any more than a very basic understanding of linux). When I see Boeing and Airbus FMUs also managing in flight entertainment and the flushing of lavatories, I will happily become a convert. I am sorry if this comes across as being harsh, but this really seems like a basic and dangerous conceptual mistake. In short, flight control functions are essential and everything else is not. I cannot imagine accepting a set up where a non essential process can bring down an essential one.
To use just for flight control, BB is quite overpowered and if no other software is run, it will most likely be able to meet the necessary deadlines. But then why use BB with its 1GHz core, when much less powerful/heavy/power hungry processor is enough?
Kabir: You eloquently summed up the points that I was trying to make.
Hi,
Regarding onboard vision, take for example last year's AVC, the red balloon finding challenge. One would expect such a challenge to be in the target-space of Erle-brain's "additional tasks." Randy ran a Odroid and was getting 2fps, if I remember correctly. That was with a quadcore processor going full-tilt. While the blob-matcher was pretty inefficient and brute-force approach, you can see what a seemingly "easy" task entitles.
It is extremely doubtful that the BeagleBone would be able to run much more other than the autopilot safely. The intrinsic non-realtime nature of the system would make it unsafe to load the processor too much. Even on a vanilla BBB system, you can hardly run any proper algorithms. As-is the system will be under pressure enforcing pseudo-RT deadlines. A simple test would be to just run camera capture on the BBB and check processor loading :P Check your framerates, they'd probably be pretty bad.
I have been running vision systems on copters for the last couple of years, and well, the BBB would be painfully slow in running anything of "consequence" if you are doing any serious work. This is the reason that I use a powerful companion which interfaces with the low-level flight controller, on ALL my research vehicles.
I even did my own hybrid approach to Linux FCs (see my blogs) which turned out good, but not good enough to justify continuing the development. Take it from AscTec for example. All their copter's run two dedicated flight processors and an optional companion (AscTec Mastermind). A dedicated flight processor gives you another layer of reliability too. While I'm not convinced by the no-companion concept, a very good job by Victor and team. Glad that you got mavros integration working.
@Victor
Welcome back to europe ... are you in Spain , Italy ? Where ?
@Michael
In my previous test on linux and APM on imx233 i saw that the main problem was pwm out the micro second timing wasn't respect by O.S. The Linux team choose to use BBB for internal PRU that can run outonomusly respect of CPU and if they need only 5 % of cpu no reason because not serve a interrutp that happen every millisecond. Other case is if you start to use other functionality as video compression and stabilization in that case you need more attention to not RT OS. I think that better approach is a cpu as fly stabilization system and another multi core cpu as application engine. Victor is agree on this approach,too
Kernel compiled with PREEMPT option is an official, "stock" kernel that does not have hard real-time capabilities, as you well know. Real-time kernel patches were not yet accepted for inclusion into official Linux kernel tree.
@Thomas ,
VR Brain is the original .. We called our board with this name 3 years ago :)
Happy Christmas :)
Just landed in Europe. I'm answering the comments:
@Vishakh we are not using the vanilla kernel but one compiled with the PREEMPT option. Our previous work with BeaglePilot showed that this option outperformed the rest and met all the time constraints nicely even in the worst circumstances. Refer to this publication for more information. We explain there how the thread priorities are set up.
@Michael we disagreed before so i see no point going over the same discussion again. Specially with criticism not justified. What exactly is wrong with using the "stress" Linux command as explained in the paper? Which one would you use better? Why do you claim that a kernel that has clearly been compiled with PREEMPTIBLE options is the default?
Let me remind you that BeaglePilot was developed by several experienced APM developers (and last time I checked Tridge was one of the most acknowledged Linux hackers). If your understanding of the real time options that the Linux kernel provides is better than us I'll be happy to hear about it. If you justify your criticism and you happen to be right, hey! that'll be a great contribution.
@Gary as far as our tests had gone, APM takes about 14% of the processor and ROS+mavros an additional 5% (this depends of the nodes you've launched though). This leaves you quite a few cycles for doing many tasks.
How much extra would the linux computer be able to do? I am flying a separate embedded linux box on other tasks at the minute if I could have it in one unit it would be fantastic.
-
3
-
4
-
5
-
6
-
7
of 9 Next