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
Mark,
Just updated the BeaglePilot README.
Erle Robotics.
The real time concerns raised here apply identically to the PixHawk Fire Cape (PXF). Erle-brain is our effort (Erle Robotics) to put into the market a close solution that includes the PixHawk Fire Cape, the BeagleBone Black and an anti-vibration system. The PXF can be acquired separately though.
I agree this is a bit confusing. Over the last two years i worked in something called "Erle robot" (that later I renamed to Erle-board), a single board BB-based PCB with an extended layout that included similar sensors with respect the PXF.
The issue with this technology was that the board was too expensive (in small quantities at the very least) and many couldn't manufacture it (6 layer PCB with BGAs) thereby we decided to focus supporting the PXF.
I found more information on the beaglepilot readme. This is apparently a competing effort to the pixhawk fire cape according to them. And I guess I should believe them because "erle robot" does not work without their project.
Test Platforms:
BeaglePilot is currently being tested using the following drones:
What companies and people are behind this project? I really need to understand more where you are coming from and what other parts of the community are planning to do before I spend a bunch of money on your newest greatest thing. If this was a release of pixhawk fire cape being announced by tridge, I don't think anybody would have any questions because that was a clearly stated roadmap several months ago. Is this an entirely separate effort from pixhawk fire cape? Or just what you are calling the product when finished?
I have to assume this is a parallel competing effort without being provided more information.
The image capture you saw is the result of torturing the kernel using the "stress" command. Particularly i used "stress --cpu 64 --io 64 --vm 2 --vm-bytes 128M". Using this call the threads waiting for execution increased (just as Michael pointed out).
Still, the autopilot behavior (as it can be seen in the bottom right screen) remains fine (with a few misses on every 10 seconds).
Mark and Michael,
Thanks for the comments. I fixed the "percent" aspect. My bad.
As I pointed out before, APM is coded assuming soft-realtime. The PixHawk misses deadlines so do we.
We are increasingly trying to make it better and thanks to the comments of many we've decided to release everything for without the payment restriction. It should be available soon.
The ones waiting for execution were the ones that corresponded with the stress call.
It's not.
Also, a load value of 17 is an "oh shit" situation on many linux application/web servers, which AREN'T expected to respond in real-time. Now there may be good reason for that thread queue, like your autopilot software is continuously monopolizing the CPU resources as it should (unless you have done that in a way that crashes the OS).
However for you to not see a 17, say "oh shit", look at EXACTLY which threads were waiting for execution... Makes me wonder if due diligence has been exercised by somebody who has engineered a highly responsive linux system previously?
Is this manufactured in the same facilities as pixhawk or different facilities?
I am really concerned that this is not ready for prime time, and possibly not a good idea. I am not getting any reassurance that this is a real-time system or that the person selling it understands the issues at hand.
Micheal, you are correct, a load value (seen in uptime) of 17 means 17 threads waiting for execution rather than 17% utilization. If those threads are CPU bound then it is at ~100% CPU most likely.
I am about to buy my first autopilot and I guess it should be a pixhawk? I can handle alternate processor architectures most likely, but I am a linux engineer/developer at my day job and at first this sounded really good.
Also, I tried to access the free version of your documentation, it was difficult to navigate and full of errors (PHYTON).
I imagine a pixhawk with a complementary linux system for more accessible development will be the way to go for now, let the embedded system do what it does well and keep the aircraft an aircraft.
Testing results in screenshot are interesting. Haven't looked at them very closely, but that's what I noticed
- uptime 17.0 is not 17%. Still not clear on CPU utilization vs load, are we.
- On the terminal in upper right corner load steadily grows as time goes by. That suggests to me that the system is about to choke up and freeze, if run a little bit longer.
- And there's still CONCEPTUALLY wrong position that authors of Erle-brain took - that auto-pilot is not hard real-time system. The fact of the matter is that if APM process fails to update attitude estimates and
servo outputs within some time frame (probably that timeframe is longer for planes who can glide for some time, shorter for multicopters who have no intrinsic stability) - the platform will crash and you will have system failure, not degraded performance. Maybe that timeframe will be seconds for well-behaved plane, but it is still hard real-time requirement.
@RoboBill,
Please refer to previous comments for a discussion on this matter. All the sources are open. E.g.: the MAVTools gitbook is available here.
We decided to assign a small fee in some cases because that helps us keep improving the material. We realized that some are willing to pay it while few (or almost none) donate.
Cheers!
This board looks exciting... especially if it will encourage development of a lidar/laser SLAM scanner to help navigate a rover when inch/cm gps accuracy is not available/reliable. But I too was very disappointed to see a fee attached to the tutorials.
-
1
-
2
-
3
-
4
-
5
of 9 Next