Closed vmayoral closed 10 years ago
After this is done it'll probably be nice to try the Xenomai path as well. This paper explored the idea https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf however it got outdated so the results can probably be published.
Using rt_kernel patch over the bbb will lead to loss of support for some peripherals such as usb, power management etc in the kernel, if this is acceptable then we can go this way, else i've an idea i.e. to use FreeRTOS on arduino for controlling basic loops such as Roll, Pitch and Yaw and higher level functionalities like pcl, path tracing using vision and inertial sensor fusion be done on the bbb using ros. Also it is for sure that for controlling the quad's heading, attitude and yaw we would require real-time control, that can be handled very nicely by a microcontroller else the input parameters to the controller will be at stochastic intervals leading to failure in any type of control esp. PID. Also keeping future in mind, the open-hardware community is going to be littered with open-source boards that are compact fusion of a powerful processor and micro-controller like http://arduino.cc/en/Main/ArduinoBoardTre which is a fusion of bbb and arduino.
I think adding a uC would be too big a hassle. Instead we can make use of the PRU for this, which is more or less the same thing. On Jan 8, 2014 7:39 PM, "Siddharth Bharat Purohit" notifications@github.com wrote:
Using rt_kernel patch over the bbb will lead to loss of support for some peripherals such as usb, power management etc in the kernel, if this is acceptable then we can go this way, else i've an idea i.e. to use FreeRTOS on arduino for controlling basic loops such as Roll, Pitch and Yaw and for higher level functionalities like pcl, path tracing using vision and inertial sensor fusion be done on the bbb using ros. Also it is for sure that for controlling the quad's heading, attitude and yaw we would require real-time control, that can be handled very nicely by a microcontroller else the input parameters to the controller will be at stochastic intervals leading to failure in any type of control esp. PID. Also keeping future in mind, the open-hardware community is going to be littered with open-source boards that are compact fusion of a powerful processor and micro-controller like http://arduino.cc/en/Main/ArduinoBoardTre which is a fusion of bbb and arduino.
— Reply to this email directly or view it on GitHubhttps://github.com/BeaglePilot/beaglepilot/issues/5#issuecomment-31833509 .
@bugobliterator thanks for sharing your thoughts. I do not understand why applying the RT patch implies losing hardware support. Could you elaborate this a bit more and explain it? How about Xenomai?
I like your reasoning about separating the (hard) real-time issues on another processing unit but I agree with @anujdeshpande. Using the PRUSS (which is included by default) might be better solution since it's directly integrated with all the peripherals that the BB(B) includes.
My guess is that up until now PRUSS hasn't been used so much because programming had to be done in assembly however as discussed at #2, once the C compiler is released we can probably make a good use of it. I was chatting with @greghaynes and the BeagleDrone project guys and we might collaborate together on this.
The repo for testing of peripherals and then implementation of control and filter loops on the Arduino with RTOS is prepared, checkout the following link https://github.com/bugobliterator/unoRTOS. The testing of USART, ADC and GPIO is done. I will merge the repo with the BeaglePilot after cleaning junk and useless code out of it. Will keep you all posted with future updates.
The RT_PREEMPT seams a good enough approach for the latencies needed. The contributions will focus on the ArduPilot code through the BeaglePilot/Ardupilot fork
Realtime evaluation of the BB(B) using the instructions pointed out by http://dev.ardupilot.com/wiki/building-for-beaglebone-black-on-linux/