Some of you might have read the work that Siddharth, Andrew, Philip and myself (supported by many others) have been doing over the last months with APM in Linux through the BeaglePilot project. We are happy to share with you today a paper titled "Towards an Open Source Linux autopilot for drones" (available here) that has been accepted in LibreCon 2014: Business and Open Technologies Conference that will be held the 11th and 12th of November in Bilbao, Spain.
The paper will be presented by my colleagues from Erle Robotics and they will also be showing our drones flying with APM in Linux. Feel free to drop by and join.
Code availability:
Most of our work with the AP_HAL_Linux has already been merged in the master branch of the main APM repository. We would be happy to address any comments either here or through issues in the main BeaglePilot repository.
Acknowledgements:
As we point out in the publication, this work would not have been possible without the support of many people. We sincerely want to thank DIYDrones community members for their support, words of encouraging and guidance. We also like convey thanks to Beagleboard.org, Google, 3DRobotics and Erle Robotics for providing financial means and material.
We would like to highlight the importance of having Andrew Tridgell (tridge) as our mentor through all these months. We can only thank him for his support and patience. It has been an amazing experience to work under his supervision and nowadays, more than ever, we deeply respect the work he and many other developers have done to bring up APM to this level. We wish that this contribution is just the first of many that will (hopefully) benefit the community.
Comments
Thanks for sharing David!
Since 2011 I have a quadcopter running on Linux OpenWRT with a Fonera 2201. It has not PREEMPT_RT but has SCHED_FIFO priority in the process, Sleeping by default waiting for and alarm fired by itself in each loop. At 70hz main loop there is no problem at all, and taking into account that Fonera still has to manage telemetry via web browser and send video via javascript requests. (And the hostapd taking cpu time too)
The only RT task performed out of the fonera is PWM, by PIC16F876. It think that if you want to keep costs low, you can use I2C ESCs. Only a cheap router would do the trick
More info in diydrones
http://diydrones.com/main/search/search?q=atropos
Since you seem to be well aware of the kernel, you'd probably know as well that technically speaking the "PREEMPT option" available right now in the mainline kernel was nothing but a set of patches included in the kernel. Anyhow what you point out is true, it's now available as an option during compile time. Should've used that term instead ;).
This is a true fact but our experimental results led us to think that the CONFIG_PREEMPT option outperformed the PREEMPT_RT patches both in minimum, average and maximum latency when we performed stress results over the BBB. If the tests we performed have been done the wrong way I'll be delighted to hear from you how they should be done.
@Michael have you read the paper? If so you'd know that we are using the PREEMPT patch (not to be missunderstood with the RT_PREEMPT) because that was the one who offered the best results. I'd be happy to see your arguing about why PREEMPT outperforms RT_PREEMPT on the BBB since we don't have a clear answer.
@Ben thanks for your comments.
I believe you are right about this matter. Many of the code is particular for the BBB and adjustments in the abstractions are needed. The good side of this is that there's already some ports going on: e.g.: the NAVIO guys are pushing forward the port to the Rpi forcing several changes in the abstractions, John Williams is working towards a port to an FPGA and i am aware of other groups working on Linux embedded boards.
1) Thanks for the pointer, noted (https://github.com/BeaglePilot/beaglepilot/issues/9).
2) There's an UART port for the GPS.
3) We selected the BBB with the idea of using its RT cores. In boards such as the Odroid and with the amount of cores you could probably bitbang it. I'd say that porting the code to a new board is getting easier thanks to the advances with the HALs.
4) That is a fact mentioned in the paper. I've got no clear answer for it at the time but i'd be interested to see if the same fact happens in different Linux embedded boards.
5) The system makes use of different processing units which makes it not that intuitive but once understood, there's nothing overly complex I'd say. The communication between the Cortex-A8 and PRUs uses simple shared memory.
Besides my doubts about your comments, first of, we've been working on this matter for several months (not weeks) and the results speak for themselves increasingly giving better and better flights as the code improve https://github.com/erlerobot/logs.
Second, even though Linux is not a real RTOS as you nicely point out there're ways of tuning Linux to provide a deterministic maximum latency (which is what we are basing our work on). We measured these maximum latencies and we found out that actually they are more than enough for our purposes. As i already mentioned the results are just the confirmation of the feasibility of this work.
Hi Dinuka,
Thanks for your comments.
There're some groups that believe exactly like you do and they indeed have good points: separating the flying logic from the application logic can help to secure the system, keep it open to the latest embedded computer or even make it easier to certify.
Over the last years the APM community has walked a long way with microcontrollers and indeed the progress on this side is currently much more mature than in microprocessors. I guess the question here is whether we (as a community) are able to push Linux autopilots to the point where the NuttX-based one is nowadays. I am quite optimistic about it. Particularly having had the change to work with Tridge and many other developers in the community.
I also believe that having the autopilot running in a Linux-embedded boards enables many new applications. For example, if we desire a small, low cost and capable drones using microprocessors is the way to go. Using a single computer also simplifies the drone assembly and does not necessarily limit the capabilities since it's totally possible to add more embedded computers. I am personally quite interested in education and the future of robotics in this field. The learning curve with the actual NuttX implementation is quite steep but i'd argue that it'll be the same with a system that is a widespread as Linux where there are many experts around the world (Linux).
Of course this is only my opinion (which is I guess biased since i am working on it). There's many influential people within the community that thinks differently and I respect their statements.
Our results are promising. We (at Erle Robotics) are starting to fly pretty much everyday comparing the results with the PixHawk. Of course we are still not there but we see improvement.
There're many relevant aspects: the size of the community, the software support, prize, it breaked out more I/O ports... There's also the fact that the BeagleBone Black is fully open hardware. For me this is quite relevant.
Michael,
You are correct it should be mentioned that %CPU and %MEM is the percentage of CPU time and memory consumed by Ardupilot during runtime. That's a glitch from my side, I’ll rectify that. Also, in the case of our usage of stress we always targeted to produced 100% CPU consumption and also attained it. In the case of minimal load where stress application was not run. Thank you very much for pointing out these issues.
Michael,
Probably we didn't make it clear enough in the paper:
"In order to generate an intensive computational task the stress linux command has been used. This command generates about 100% of computational load which is ideal for testing the different kernels reaction. The tests have been done using cyclictests, a benchmarking utility that measures the latency of response to a stimulus. This utility implements the following ... "
Both Sid and myself used stress to put the processor load close to 100%. Furthermore obtaining the same results with two different approaches provides a more reliable result.
-
1
-
2
of 2 Next