-
assigned issue to
Large memory consumption in certain contact situations
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.
Comments (8)
-
reporter -
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
-
reporter - edited description
-
reporter - changed milestone to Qualifier 2
Worked around this for qual 1, but we'll aim to fix it for qual 2.
-
reporter - changed status to open
-
reporter - changed milestone to Qual2
-
- removed milestone
- removed responsible
-
- marked as minor
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
togear.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. - Log in to comment