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
Great! Thanks for the link to that thread, looks like you guys are way ahead of me. Keep up the excellent work :-)
@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.
@Michael Kagalenko I don't think the realtime issue is insurmountable. The hard deadlines are handled by the PRU, and support for the RT patches could be added if needed. Anyway, if the lack of true RT guarantees is a deal-breaker, then there's nothing forcing you to use the BeagleBone - there are plenty of more deterministic APM platforms to choose from. I may have missed something in the comments, but where do the authors state that mainline Linux can provide hard RT guarantees? To the contrary, in the paper they state that "The Linux kernel has not been designed to meet real-time constraints...".
To the authors - awesome paper, there's a lot of valuable discussion/development in there. I am not convinced a Linux HAL makes sense, though. Any code which is purely dependent on Linux must logically be hardware-independent, or at least handled within Linux's own 'HAL'/udev. The parts which aren't, such at the memory-mapped IO and PRU, are really part of a BeagleBone HAL more than a Linux one. I can see that it is difficult to decouple the two, but I worry that if this project is ported to many different Linux platforms then this will result in a huge amount of non-portable code sitting within the 'Linux' namespace, compared to a relatively small amount that is actually Linux-generic. Case in point, everything in the "Tools / Linux_HAL_Essentials" is actually BeagleBone-specific, despite the name.
I guess some sort of modular Linux/{BeagleBone, RasPi, ODROID, ...} HAL would be ideal...
So maybe your building with cracked foundation stood for months instead of weeks, and you put a lot of crutches around the walls. It's still not safe to enter.
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.
Finally got the time to read through the paper. Interesting stuff. Few questions/comments for the authors.
1.) DCM version of attitude estimation of the APM is based on Rob Mahonys work on non-linear complementary filtering. It would be nice to see his work cited alongside [12]
2.) What about GPS, what does it connect to?
3.) How difficult is it to port this code to a different board running linux like the Odroid w/o PRU-ICSS? On that note, I have a feeling that using board/processor specific hardware such as PRU is not the best way to go.
4.) Your results contradict previous results by [5]. Can you explain the reason for this?
5.) Your methodology to achieve real-time response to receiver, SPI bus and PWM generation seems overly complex to me, but that maybe because I'm not an expert in Linux. However, having read this paper, it makes me wonder whether all this complexity is really worth it when compared to a 2 board solution with one running an RTOS such as NuttX.
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.
The problem with the article is not the goal, but the means they chose to achieve it. Their approach is inherently unsafe. Authors are like builders that put a house on cracked foundation and say that the house is sound because it did not fell down after a few weeks.
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.
I'm no expert in Linux systems, but I for one believe that these guys deserve some credit for what they are doing/trying to do. Clearly they've put in a lot of work into it. There maybe some deficiencies, but constructive criticism is the way to go.
I believe that if they can make this work, it would be really valuable to a lot of people. More and more UAVs developers are looking at integrating more senors such as lasers and cameras to improve the capabilities. In that case, we definitely need a powerful linux on-board computer. While having a separate board with an RTOS is definitely the best way to go, it increases the cost and adds more complexities such as communication and synchronization. If it is possible to ensure that the control system code can be given high-priority and run real-time or near-real-time on the linux computer, then that simplifies the setup quite a bit.
Having said that, I want to ask the authors a question. Why beaglebone and not something like Odroid U3??
-
1
-
2
-
3
-
4
of 4 Next