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.

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.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Michael Kagalenko October 15, 2014 at 3:30pm

From the article it is not clear if the authors even realize the difference between "CPU load" and "CPU utilization"
Michael Kagalenko October 15, 2014 at 3:28pm

I am sorry, but that is still meaningless without data regarding the system load and "stress" command-line switches. For one, % of CPU utilization does not tell if any processes are waiting in run queue, and if yes, how many. 100% load does not mean much unless load average is > 1
Siddharth Purohit October 15, 2014 at 3:17pm

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 Kagalenko 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.
Víctor Mayoral 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.
Michael Kagalenko 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.
Víctor Mayoral 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.
Michael Kagalenko 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
Michael Kagalenko 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.
Víctor Mayoral 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.

of 4

This reply was deleted.