DRCSIM: Simulating the hands is killing performance
I did a timing test on the Atlas robot without hands, with the sandia hands, and with the irobot hands. I set the update rate to zero, the time step to 1ms. and the number of solver iterations (iter) to whatever led to a realtimefactor of about 1.0. I used the following commands to launch the simulations, and waited more than 10s until the controller started operating.
roslaunch atlas_utils atlas.launch roslaunch atlas_utils atlas_sandia_hands.launch roslaunch atlas_utils atlas_irobot_hands.launch
This is DRCSIM-2.0 updated as of Sat Feb 16 15:32:53 EST 2013. Aside from the adjustments mentioned above, this is "out of the box" software.
On my Xeon-based machine (dual Intel(R) Xeon(R) CPU E5-2687W 0 @ 3.10GHz) with Quadra 6000 and Tesla K20 GPUs (this machine is a slightly newer version of the cloud machine we plan to use): No hands was able to hit 125 iterations per time step. With the Sandia hands I was able to get about 65 iterations per time step (about 1/2 the no hands performance). With the iRobot hands I was able to get only 15 iterations per time step (about 1/8 the no hands performance). I have no idea why the iRobot hand simulation is so much more expensive.
This is not good. Check out www.cs.cmu.edu/~cga/drc/constraints.html to see how joint constraint violations go up as iters goes down. In those plots iters goes down to only 70 because we couldn't get walking working at all below that. Recently we discovered a secret hack that I won't tell you for competitive reasons that allows us to walk with iters equal 40, the current default. I will give a PhD to anyone who can make the robot walk with iters=15 (CMU may not endorse this offer).
This is purely a computational cost issue, and is orthogonal to the numerical conditioning issue I brought up in another post on theroboticschallenge.org.
I am cross posting this in http://answers.gazebosim.org and heroboticschallenge.org
It would be nice not to have to rely on secret hacks.
Padawan Chris
