Timeline for How mature is real-time programming in robotics?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 9, 2012 at 8:27 | comment | added | Rocketmagnet | @bit-pirate - I couldn't tell you in detail. Maybe ask it as a question. It's actually quite possible to do perfectly good motor control with 100us jitter. And it's normally less than this. I think that you have to give the loop its own core. | |
| Nov 9, 2012 at 0:57 | comment | added | bit-pirate | @Rocketmagnet: Interesting indeed! So, what is deprecated? Do they not use RT PREEMPT anymore? Actually, I thought 100us is not a bad performance for Linux + RT PREEMPT. Of course, some say such a performance is not hard realtime. Anyway, I actually only wanted to make sure, that people don't expect good behaviour when controlling a motor directly from within Linux/Windows/ROS/... without any additional tweaks, such as real-time extension (RT PREEMPT, Xenomai) and specific tools (e.g. OROCOS). PS: I didn't have enough karma to downvote you anyway! :-) | |
| Nov 8, 2012 at 9:47 | comment | added | Rocketmagnet | @bit-pirate - According to our software guys, this is depreciated. I have also discussed the EtherCAT loop with the guys at WG, and they inform me that the loop is not hard real time. I have also directly measured the jitter on this loop because we make EtherCAT based hardware with ROS drivers, and I have had to go to some effort to compensate for the fact that it runs a very soft real time control loop. Lastly I have seen the actual code for the inner loop. You know how the 1kHz timing is implemented? It's a sleep instruction! | |
| Nov 8, 2012 at 0:23 | comment | added | bit-pirate | @Rocketmagnet I'm sorry to have to downvote this one, but the PR2 part is wrong. On the PR2 there is a single real-time loop running at 1000Hz parallel to ROS (on Linux + RT PREEMPT), which is communicating via Ethercat with the motor controller boards, doing the actual motor control of each DOF. You have to be careful when programming controllers (e.g. a joint trajectory controller) in order to not break real-time and they also have special tools to manage them (e.g. load/unload them). Look here for more details. | |
| Oct 25, 2012 at 20:49 | history | edited | Rocketmagnet | CC BY-SA 3.0 |
More about control
|
| Oct 25, 2012 at 20:45 | comment | added | Rocketmagnet | @sylvain.joyeux - I agree. ROS performs pretty badly for control when you have only 2 cores. | |
| Oct 25, 2012 at 20:34 | comment | added | sylvain.joyeux | I would like to stress one point: you have so many processing power on the PR2 that you might get something "good enough". I worked on a robot with "only" a Core2 Duo. That's not an option there: the complete stack is taking each core 100% most of the time. Here, Rock (Orocos) and RT-Linux were necessary to hold the 1kHz control loop together. | |
| Oct 25, 2012 at 15:10 | comment | added | Rocketmagnet | @Shahbaz - I can't comment on exactly how often it's actually used, but I can say that if it is used, then it may well be unnecessary. We used to use RTAI, then abandoned it because it was actually hindering more than helping. | |
| Oct 25, 2012 at 13:52 | comment | added | Shahbaz | So in short, you are saying that real-time is often not used, because non-real-time software works "good enough"? | |
| Oct 25, 2012 at 13:48 | history | edited | Rocketmagnet | CC BY-SA 3.0 |
added 1130 characters in body
|
| Oct 25, 2012 at 13:38 | history | answered | Rocketmagnet | CC BY-SA 3.0 |