Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trouble with RTF of REEMC in Gazebo #4

Open
JJJKon opened this issue Sep 19, 2019 · 11 comments
Open

Trouble with RTF of REEMC in Gazebo #4

JJJKon opened this issue Sep 19, 2019 · 11 comments

Comments

@JJJKon
Copy link

JJJKon commented Sep 19, 2019

Hi,

I've installed the REEM-C simulation according to this tutorial on my laptop running Ubuntu 16.04 with the following specs that meet the requirements as given on this tutorial page:
SystemSpecs

The graphic card is set up with the proper drivers:
Driver

However, when I launch an empty world with REEM-C according to roslaunch reemc_gazebo reemc_empty_world.launch, the RTF of the simulation quickly (after a minute) drops to 0.1, even without enabling the controllers:
GazeboAfterOneMinute

I've tried playing around with the solver settings to increase this simulation speed, but the performance increase can only be pushed till 0.15 before the controllers become unstable for these solver settings.

It should also be noted that the MSc. student that worked with REEM-C on a door opening environment before me also suffered from the same slow simulation speed.

Lastly, I've attached the terminal output of the launch file below such that you can inspect it for possible problems if necessary. Based on the warnings about not being able to disable collisions (line 1070 onwards), could it be possible that the engine is overloaded calculating contact dynamics resulting in the slow speed? Also, I was wondering if the fatal error regarding the library is relevant (line 1237)? Finally, could scanning for a joystick slow down the simulation every second, taking up too much resources, as the simulation seems to be blocking periodically?

Thanks in advance!

Output.txt

@v-lopez
Copy link

v-lopez commented Sep 19, 2019

Hello,

There's a pluginlib error in your output:

�[33m[ �[31m[FATAL] [1568883678.237463598, 0.001000000]: Failed to create robot simulation interface loader: Failed to load library /home/johan/reemc_public_ws/devel/lib//libpal_hardware_gazebo.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library (Poco exception = /home/johan/reemc_public_ws/devel/lib//libpal_hardware_gazebo.so: undefined symbol: ZN18gazebo_ros_control17DefaultRobotHWSim13prepareSwitchERKNSt7__cxx114listIN18hardware_interface14ControllerInfoESaIS4_EEES8)�[0m

Can you please make sure that you have our version of ros control in your workspace, and you have uninstalled all other ros control version from your system?

Maybe the RTF is caused by the robot being on the ground and having lots of contacts like you mentioned. But the robot should not fall to the ground when starting, I believe that these library loading issues are the cause of it.

@JJJKon
Copy link
Author

JJJKon commented Sep 19, 2019

The library is present in the given path:
Libraries

I am new to ros, so I don't know how to uninstall all other ros control versions and where to find those? I've not installed anything besides the packages mentioned in your tutorials, so I guess there's no other ros control versions? Could the double / in the library path /home/johan/reemc_public_ws/devel/lib//libpal_hardware_gazebo.so of the error message be the cause of the failure?

@v-lopez
Copy link

v-lopez commented Sep 19, 2019

Check if you have other ros control versions with dpkg -l | grep ros-control. Uninstall anything that starts with ros-.

Ros control is released on the official ROS repositories, we're running a modified ABI incompatible version, that can conflict and lead to situations like this.

@JJJKon
Copy link
Author

JJJKon commented Sep 19, 2019

This indeed resolved the library error. Now the robot indeed stays upright after initialization, but the RTF dropped to 0.07:
Standing

Maybe the RTF is caused by the robot being on the ground and having lots of contacts like you mentioned.

I was not referring to the contacts with the ground, but self-contacts, as it seems that the launch file outputs that it was not able to disable contact between multiple joints of the REEMC.

@v-lopez
Copy link

v-lopez commented Sep 19, 2019

Can you post the output of the console like you did before?

Also run a top and post it here please.

@JJJKon
Copy link
Author

JJJKon commented Sep 19, 2019

Console output (collision warnings from 1070 onwards): Output2.txt

Top while running the processes: top

@v-lopez
Copy link

v-lopez commented Sep 19, 2019

It looks like your CPU is saturated.

Can you print cat /proc/cpuinfo? Also are you sure your nvidia is properly configured? gzclient is taking also too much cpu.

@JJJKon
Copy link
Author

JJJKon commented Sep 19, 2019

cat /proc/cpuinfo produces: cpuinfo.txt

Before I configured nvidia, Ubuntu was using the Nouveau driver with Intel Haswell listed as graphics in the first two images posted. With this configuration, I was not able to run the simulation at all: it would drop to RTF 0.01 and eventually straight-up stop simulating anything. The current situation is after configuring nvidia. Is there any other way I can test if it is properly configured?

@v-lopez
Copy link

v-lopez commented Sep 19, 2019

Run glxgears (install mesa-utils if you don't have it).

It should give an output similar to this:
image

And if you run top, glxgears should use minimal cpu. If it's using cpu to render, glxgears will use 100% cpu.

@JJJKon
Copy link
Author

JJJKon commented Sep 19, 2019

It is in fact using the cpu to render (edit2: 100% usage, not for rendering), so I'll have a look at the card configuration again.

Edit: glxgears is also an active process on the GPU as indicated by nvidia-smi while also using 100% CPU.
glxgears

This is the same for gzserver and gzclient
GPU_usage

I suppose that if the card was not properly configured, I would not have these processes running on it?

Edit2: glxgears also indicates that it is using the GPU for rendering:
glxgears_info

Edit3: profiling the cpu (sudo operf glxgears followed by opreport) shows that another process takes up the biggest chunk. Investigating and solving this is however far beyond my knowledge, so before I continue, I would first like to hear your thoughts on if it is indeed a problem with the video card configuration.
CPU_usage

@v-lopez
Copy link

v-lopez commented Oct 2, 2019

Sorry I did not get any notification regarding the edits you made to your comment.

I believe your issues are not related to reemc simulation, but I will try my best to help you.

Tthe glxgears should be running at 50-60fps and take minimal cpu, if not, maybe still some part of your graphic settings or openGL is not configured properly.

Also, your cpu specs may be limiting you for these kind of simulations.
My machine has a i7-7700k CPU (which is around 50% faster than your cpu according to benchmarks) , with it we're running it with RTF of 0.6 launching roslaunch reemc_gazebo reemc_empty_world.launch.

image

And glxgears is using around 2% cpu.

Still I believe you should be able to reach 0.3 or 0.4 RTF on the empty world.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants