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.
By the way, just about any introductory text on real-time systems mentions that latency and performance are two different and to some extent conflicting goals. Stock kernel compiled with CONFIG_PREEMPT option is not real-time OS, and can not guarantee any maximum latency - neither 10 millisecond, nor 10 minutes.
@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.
That is true only as long as BeagleBone is running hard real-time operating system. It could be Linux wih preempt_rt patch, or TI SYS/BIOS, or something else. Stock Linux can not guarantee bounded responce time, no matter how you tweak it.
Considering the dynamics of a reasonably sized multi - rotor, it is entirely sufficient to run the autopilot or the control loop @ about 100 - 200Hz. This means that you have about 5-10ms from the time the sensors are read till you need to produce actuator signals. (A 5 ms delay in the control loop shouldn't be too difficult to handle given the slow dynamics) I'm quite confident that a beagle bone can handle that with right thread priorities.
That brings us to the question of reading the sensors and writing to actuators. Again, this does not have to be done at exact time intervals as long as an average rate of about 200Hz is maintained. In fact some of the ESCs used in multu - rotors have an update rate of 50Hz.
So what needs to be done at hard real - time? Responding to external events. For example reading a PWM input or responding to clock signals generated by another board. I believe that's what the authors are doing with the PRUs. However I'm still not convinced that's the right way to go.
(And of course, PRU-ICSS on ARM Sitara does not run Linux)
PRU-ICSS subsystem in TI ARM processor used by BeagleBone is really a separate dedicated microcontroller on the same chip. Other platforms such as Odroid or RPi do not have similar feature, and port PRU-ICSS part to them is plain impossible.
Other single-board embedded computers (like intel Edison) sometimes have dedicated microcontroller for handling real-time stuff. That is little different from having a separate autopilot board, as that dedicated microcontroller does not run Linux.
What are non-hard deadlines in the autopilot code? I struggle to think of one. Failing to compute attitude estimation or PID controller output on time will lead to crash, so theyr ARE hard deadlines. Maybe, you are calling "hard" deadlines that are very small, like a few microseconds, but that is not what the term means.
"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."
The authors of the article in question promote the use of Linux for aircraft control. BeagleBone has little to do with the fact that it is flawed choice
"I may have missed something in the comments, but where do the authors state that mainline Linux can provide hard RT guarantees?"
That is what they do when they claim that Linux kernel may be tuned to guarantee meeting deadlines. With mainline kernel it is impossible. Morevoer, authors do not seem to have good understanding not just of real-time issues, but the very Linux platform they are promoting. for instance, when I pressed for specific figures regarding the system load in their testing, they replied that CPU utilization was 100% percent. So they apparently don't understand the difference between the two.
-
1
-
2
-
3
-
4
of 4 Next