drake-visualizer slow simulation with icub and valkyrie

[InriaBrice]

Hi,

It seems that drake-visualizer is pretty slow with complex robot model, like for Valkyrie or our robot : iCub. For icub, when we try to load our URDF (icub_with_transmission.urdf.zip ) the robot doesn't show up, and it's publishing this warning :

[2017-10-06 16:07:03.146] [console] [warning] DrakeVisualizer::Publish() called before PublishLoadRobot()

When i try with a simple URDF, with only few part of the robot, the robot is load but it take more time in function of the number of part i use.

Example :

only with icub_waist : few second icub_waist + legs : few minutes icub_waist + legs + torso and head : around 20 min full : never show up after more than 1h

Meshes : meshes.zip

.obj got generated from .dae with a blender script, we know about the miss orientation. But for now we just want to see something in simulation. Be carefull i put dae and obj in separate folders (dae and obj) and in icub_with_transmission.urdf all path are ../meshes/visual/icub_waist.obj for example.

Our original URDF load in Gazebo, we added transmission and changed a bit some name to match with drake's URDFs. htop show that one core is running to 100% and the memory isn't full or swapping.

With Valkyrie it looks like the simulation is running slowly. The model is load but even with target_realtime_rate set to 1.0, the dynamics and whole simulation is running slowly.

Best regards,

Brice CLEMENT Team LARSEN, Engineer R & D INRIA Nancy Grand Est

[RussTedrake]

Brice. One clarification -- target_realtime_rate will only slow down a simulation that is running faster than realtime. It does not try to speed things up. In general, we have many numerical integration options/routines/settings. Many are chosen to guarantee accuracy first (vs performance), but I think you should be able to expect reasonable performance, too. The biggest slow-down I've seen is when the collision geometry is overly complex, and the collision checking slows things down. it would be great if you could profile the sim process for us to see where the time is being spent.

I've not seen any slow-downs coming from director rendering robot models (except once when we simulated hundreds of robots). cc @patmarion in case he knows otherwise.

The publish before PublishLoadRobot() is known to be an excessive printout. #7205. cc @SeanCurtis-TRI .

[kazuotani14]

Hi Russ, As you said, the collision checking was slowing things down. ~50% of the time was being spent in collision checking. We tried enabling a collision filter group that includes all of the links - that sped things up, and we were able to see the iCub model in drake_visualizer. What numerical integration scheme would you recommend for speed? The valkyrie demo is running at around 0.25x real-time for us.

[SeanCurtis-TRI]

It's also worth noting that if you're using the same geometry for visualization and collision, you'll be taking a performance hit there as well. (Sorry, I haven't looked at your urdf.) If you're already using simplified collision geometry, you can ignore this. If you're not, I can take a look at your meshes and make suggestions.

[RussTedrake]

Fwiw - For walking/balancing you can get surprisingly far with having very simplified collision geometry — many groups just put ONLY for zero-radius spheres at the four corners of the feet. We used that (with a few refinements for stairs) throughout the DRC.

[kazuotani14]

Thanks for the tips, we will move towards using simple collision geometries.

Also, using Eigen's colPivHouseholderQr instead of jacobiSvd in LinearSystemSolver::Solve seems to make the Valkyrie simulation much faster (2~5x). This tweak is mentioned in #2287 but it's unclear if it was ever tried. My understanding is that SVD was used because it's the most numerically stable; is there any way to test whether this will be a problem for the current use cases? The QR method passes the current tests, with one change in the underdetermined linear system test: check that (A*x_sol - b) is approximately zero instead of comparing x_sol to x_expected.

[hongkai-dai]

Hi @kazuotani14, yes you are right that colPivHouseholderQr is a lot faster than jacobiSVD. We did not choose QR decomposition because it does not produce the same solution as SVD. jacobiSVD always produces the least square solution, while colPivHouseholderQr doesn't. Namely if we have

A * x = b

where there are infinitely many solution x_sol, jacobiSVD guarantees that the norm |x| is minimized.

I did try to switch to QR before, it fails in one of the simulation test for IIWA arm. The box falls off the hand during the simulation.

One thing I have not tested is to switch to CompleteOrthogonalDecomposision (https://eigen.tuxfamily.org/dox/classEigen_1_1CompleteOrthogonalDecomposition.html). This guarantees a least square solution also, and should be faster than QR.

Anyway, there is a lot we can do speed up the simulation. For example, the linear system we solve has some special structure. It is in the form

[ M J'] * [v̇] = rhs
[ J  0]   [f]

By exploitting the special structure in the matrix on the left-hand side, we should be able to improve the simulation speed.

[kazuotani14]

I see, I didn't know that.. Any improvements on simulation speed would be great!

[patmarion]

Hi Brice, please let me know if there's anything I can help with the meshes. It looks like the issue here was in the pipeline before the data gets sent to the visualizer, and not an issue with loading the meshes in the visualizer.

Just to check, I tested your obj files with the command line drake-visualizer --data meshes/visual/obj/*.obj and they open instantly.

[InriaBrice]

Yes all the meshes are ok, we just need to apply some rotation and it will be fine thanks ! I'll close this issue, thanks all.