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
Victor..I missed a part where you explaining why not use Odroid..is it bcs of higher price?
@Kabir please refer to my previous comments. APM does not provide hard realtime. Not in microcontrollers, neither in microprocessors. Judging by the tone of your comments I presume you should understand enough of the code to judge it yourself. Refer to the scheduler implementation
I disagree. Just went for a flight with a copter and while being in the air i started stressing the processor. We did not notice any missbehaviour in the flight. None. It'll be nice if you could test it yourself.
The computational power available might not be as high as with an Odroid but it's far from being useless as you say.
Personally, given the flexibility and capabilities of a Linux autopilot and the consumption of the motors (being several orders of magnitude more) i have to admit i haven't looked that much into how to save power however Philip and I would love to get feedback on the design (source) and how to make it more power efficient.
Guys, to stay on topic, there are 3 main issues :
1. Hard realtime constraints being met - Victor has agreed to allow me to do independent testing on a board which will allow us to iterate on this thoroughly. Also, execution threads shouldn't keep adding up, as seems the case, since the stress command is a fixed loading command. A "live" test will be appropriate here. Linux cannot outperform a dedicated RTOS here.
2. The BBB being useful enough for anything else - As I previously mentioned, you cannot run anything of proper use on a BBB. There is NO question on this.
3. The processor is overpowered for just running *flight control*. Most of the processing power goes to waste. Basically, we have the worst of both worlds here, as we cannot run the flightstack as optimally as on a dedicated RTOS (see point 1) and neither can we run anything else which would give us a serious advantage (point 2) and maintain flight safety.
Would the system keep flying if the processor simply locked up on overload? Stressing it in flight would be interesting, especially with something it couldn't cope with. Its not possible for the end user to guarantee this, unless extensive testing and well-coded applications are used. 9 out of 10 times, there would be a failure on hand.
I need to preface this by stating that I wish the best of luck to erle robot and hope they have an outstanding success. However I am not the only person who can see the possible issues here.
@Victor Mayoral: I insulted your baby, and it hurt, but I think you should listen a little bit instead of get aggro about it. It might be productive.
@Damouav: Your fanboy mob mentality is amusing, you have decided I am against the "linux developers" without knowing who I am! Did it ever occur to you that the reason I am so concerned about a linux autopilot going badly and generating bad publicity is because many years of my life have been dedicated to Linux and evangelizing its' usage in the enterprise and public sector? Yes, I don't want you to pollute the hard work performed and success that has been reached with linux in enterprise systems, with the high profile horrible media "drone obsession" which would certainly focus on how linux could not do the job.
@Michael: exactly. It's going to go fine until somebody overloads one, because they haven't been told to not do that. That's my whole problem with Victor's slick sales pitch, it's pretty much "you can do everything on linux now!" rather than "do not load this autopilot down with inefficient code, and if you do modify it, you must test thoroughly". You can see why I am not a salesman.
Is anybody else other than Victor involved with Erle Pilot who will back his statements up? It seems like he is the only person assuring the success of this offering rather than a team who is ready to offer it. Maybe because everybody else involved knows it is highly experimental and higher risk to buy than Victor has portrayed? Victor if you take a commercial military UAV sales job you could finance your development efforts independently instead of through preorder--Because you are not bad at sales.
Whether that is even completely true is quite irrelevant to the fact that missing a hard deadline from an autopilot is not a "degraded performance". It is a mission failure. Real-time performance may be achieved without RTOS if system builder controls everything that is executed by the processor. In the case of your product it is explicitly not so, it is actually a point in your marketing that one can run something else on BB in addition to autopilot stack. I am sure that autopilot will work just fine if it is the only thing that BB is executed. But then using BeagleBone makes no sense, as iti is heavier, more expensive and power-hungry than STM-based autopilots.
The threads waiting for execution should not continually increase, though. "stress" command imposes a fixed load that is pre-determined by the command line switches. That the load keeps increasing means that the system is about to freeze up and stop responding.
@Victor : I hope the pre-orders start shipping soon so I can get my hands on it as soon as possible.
I am just a bit worried that 110gr Erle-brain be a bit bulkier than 38gr Pixhawk but I trust in you job!
Just go on ;)
I have been making an attempt to speak with more developers who have a better background in these specific projects. So far everybody has only had positive things to say about the work you are doing Victor. I hope I will get a chance to try one of these some day!
We iterated the PXF several times and we release it being confident it can compete with current autopilots. There're concerns in the community about the real-time aspects and I welcome them as a way to figure out a way to improve Linux autopilots. A topic I'm interest in.
I consider myself what you call a "Linux engineer". Maybe not as talented as apparently you are given the tone but hey, i should know a few things if I pulled of BeaglePilot together with Anuj, Tridge and Philip (you probably might want to check GitHub and my previous posts since I'm one of the guys pushing this from the very beginning).
You can find the design files also in GitHub. We also link them from the Erle-brain product page with proud since it's a project we have been part of from its origin.
We are doing our best to bring up an actual product with new capabilities, and we welcome the feedback/criticism as a way to improve ourselves. What I'm not going to accept is your offending nonsense. Specially giving the fact that i see no previous valuable contributions in your DIYDrones profile. It seems to me you just want to annoy me. And man! you've done it so I might just ignore you from now on.
If this is an open hardware offering, where are the design files? Have any independent parties reviewed them to determine if the actual design files were provided or if incorrect/old design files were provided?
Okay, it seems like you have an overmarketed product that isn't even ready to ship, that you are trying to get out the door before everybody else, while also ripping people off for really low quality documentation.
I'm guessing you have put more work into your sales and marketing website than the actual product. That's what happens when you throw sloppy load tests together and misinterpret them. Where are your linux engineers that understand the product? Or do you just open bugs with beaglepilot and ask them to help?
-
1
-
2
-
3
-
4
-
5
of 9 Next