Large memory consumption in certain contact situations

[Brian Gerkey]

It can happen that if you put the vacuum gripper link into collision with something (e.g., a part or a bin) that you get fast memory consumption and high CPU usage, at a rate that can take over your machine. A workaround is to disable gazebo's state logging.

Hypothesis: in this situation that link vibrates at a fairly high frequency, which causes constant but small changes in model poses, which in turn creates a firehose of data to be logged.

Ideas for addressing the problem:

• reduce the number of other models in the world (this seems to help, but it's not clear why);
• make UR10 collision bodies simple shapes instead of their current mesh representations;
• reduce the number of static models in the world; e.g., make the bins non-static but very heavy;

But before that, we should analyze the gazebo state log to confirm that the problem is lots of tiny pose changes.

[Deanna Hood]

removed unnecessary models in the qual1 config files in https://bitbucket.org/osrf/ariac/pull-requests/21

I also made it so that state logging has to be turned on explicitly so that users don't run into this when they're playing around with practice config files

[Brian Gerkey]

Worked around this for qual 1, but we'll aim to fix it for qual 2.

[Deanna Hood]

This has not proven to be an issue during the 2017 competition. By default, gazebo state logging is disabled. It is enabled in qualifier- or finals-specific trial config files.

Recently we added the option to pass --state-logging=false to gear.py which will override config files enabling state logging. Users can use this if they find that state logging is causing high cpu usage when practicing with qual configs.