Towards an Open Source Linux autopilot for drones

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.

Views: 2655

Comment by Gary McCray on October 12, 2014 at 9:11pm

Excellent paper guys and excellent work,

I am personally very interested in the use of Linux platforms for UAS and for robotics and would like to know in particular how close we are to an initially usable, widely available Beagle Board Black solution with the Fire cape.

I realize that in many ways this is the big question, but it seems that at least a workable implementation has been made at this point and the most important question is when can the actually operating version of the Fire cape be made available to us.

I think that there are many of us who would actually like to be able to start down this path.

Best Regards,

Gary 

Comment by Víctor Mayoral on October 12, 2014 at 9:18pm

Hey Gary,

Thanks for your words. From our side at Erle Robotics, we have several ready-to-go images and the hardware is coming along nicely. You can expect something to happen in the following two months.

Comment by Michael Kagalenko on October 13, 2014 at 5:30am
I briefly skimmed through the article, but I confess I still don't feel comfortable with your approach of basing autopilot on non-realtime system. Isn't that inherently unsafe?
Comment by Víctor Mayoral on October 13, 2014 at 7:27pm

Michael, some share your concerns. Many believe it is the future track. Our work here provides a path towards a safer Linux-based autopilot. We provide a deep analysis of RT aspects and we share timings and conclusions. Feel free to ask specific questions once you've read the article.

Beside the technical aspects i would also highlight the clear benefit of moving to Linux: opening autopilot development to a big and experienced community of developers.

The paper has been updated including more references of some previous work performed by Paparazzi developers.

Comment by Michael Kagalenko on October 15, 2014 at 5:49am
Victor, I have not found in your article any info on whether you did any stress-tests on your code. Measuring latencies on system that does nothing else tells little on how the autopilot code's performance will degrade once one loads up the CPU and I/O subsystem with some unrelated computationally-intensive task, like video processing. Linux kernel, in words of Linux Torvalds, is "huge and bloated". It was not designed for desktops and servers, not real-time control. Truying to shoehrn it into the tasks it was not designed for does not seem like obviously valuable project.

And also, given the direction Linux development taking lately, meaning things like the whole systemd debacle, bringing more Linux developers into autopilot programming is not necessarily an unmixed blessing, it seems to me.
Comment by Michael Kagalenko on October 15, 2014 at 5:52am
Thomas, I am with you on that one. I think far more valuable project would be to port Nuttx to more arm platforms, like beaglebone. Otherwise, we'll see people trying to wirte atopilots in Python and Jaascript
Comment by Víctor Mayoral on October 15, 2014 at 10:38am

Thomas and Michael, thanks for your comments. Your skepticism is quite welcome. We need it in order to steer in the right direction.

Michael, you may want to review the paper again. Refer to section 2.7 and the following content.

Comment by Michael Kagalenko on October 15, 2014 at 12:45pm
In tests from the section 2.7 of your article, average processor load was about 10% and never exceeded 20%. That's not meaningful stress-test. Pretty much any OS will show reasonable response times if it is so lightly loaded.
Comment by Víctor Mayoral on October 15, 2014 at 1:10pm

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. 

Comment by Michael Kagalenko on October 15, 2014 at 1:15pm
What "%CPU" column in Table 3 refers to, then? Also, "stress" command can generate different loads, depending on the switches used, and the article does not specify those.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service