Increase the Real Time Factor for ergoCub

[PasMarra]

When trying to grasp an object with ergoCub, I've noticed a substantial drop of the rtf and I've initially thought that it was caused by the hand collision mesh (see here). Any simplification of the hand mesh, and even of the bottle mesh, did not improve consistently the rtf variation.

Then, I've noticed also that more or less the same drop happens with iCub too, but in this case it does not affect too much the simulation because the initial rtf value is higher than the ergoCub one.
So, I'm opening this issue to discuss new ways to improve the rtf for ergoCub.

cc: @Nicogene

[PasMarra]

Here a comparison between ergoCub (ergoCubGazeboV1_1) and iCub (iCubGazeboV2_5_visuomanip) when launching the scenario (consisting of the robot + the table + the bottle):

• ergoCub rtf = 0.86/88
• iCub rtf = 0.97/98

This difference of about 0.10 appears when we just launch the scenario. As you can see below, the feet-ground contacts are way more in ergoCub than in iCub; furthermore, for ergoCub there are some flickering contact points (this is maybe due to the robot model, because iCubGazeboV2_5_visuomanip is fixed w.r.t. the ground, while ergoCubGazeboV1_1 is not).

ergo_contact.mp4

ergoCub: the rtf is about 0.70 because of the contacts visualization, but it goes back to 0.86 when the visualization is turned off.

icub_contact.mp4

iCub: the rtf is basically the same with or without the contacts visualization, maybe because there are just 2 contacts.

Remark: the rtf difference can also be caused by the laser simulation, which is absent in iCub.

[PasMarra]

Hi @Nicogene, I had changed the ergocub model and performed some tests.

More specifically, inspired by the iCubGazeboV2_5_visuomanip, I've applied the following changes to the ergoCubGazeboV1_1 model:

• laser sensor removed;
• legs sensors removed;
• legs controllers removed;
• added a fixed link between world frame and root frame.

As you might guess, the simulation of these sensors and controllers is useless since they are not involved into the grasp execution.

Now, when the scenario is opened in Gazebo, there is no more the initial rtf difference between the ergoCub model and iCub model.

initial scenario in Gazebo

Moreover, the minimum rtf value reached during the grasp execution is very much improved (circa 0.25). Please notice that I'm using the original collision mesh for the hands.

original_collision._.and_no_leg_ctrl.mp4

grasp execution with original hand collision mesh and modified model

Given these results, since there is already a specific iCub model for the manipulation (i.e., iCubGazeboV2_5_visuomanip), I would ask you to create an analogous manipulation model for ergoCub. Thank you.

[SimoneMic]

Hi @PasMarra

While working with gazebo I have found that also disabling the shadows helps a tiny bit with the RTF. In World->Scene->untick the shadows. I usually gain a bit, 0.05/0.07.

I agree that having a dedicated model for the simulation application is the right way to take. I use the version with _minContacts which has collisions only in the soles. The collision checking in simulation is computationally demanding, especially for complex meshes, so I suggest to remove as many unecessary collisions as possible from the robot URDF.

[Nicogene]

Hi @PasMarra, about this point

added a fixed link between world frame and root frame.

There are already models fixed in the world e.g.:

https://github.com/icub-tech-iit/ergocub-software/blob/master/urdf/fixed_model.sdf.in

Have you tried one of those?

I agree that having a dedicated model for the simulation application is the right way to take. I use the version with _minContacts which has collisions only in the soles. The collision checking in simulation is computationally demanding, especially for complex meshes, so I suggest to remove as many unecessary collisions as possible from the robot URDF.

@SimoneMic you are right but I have to understand first how to not make explode the maintainability of the repo, because any change has to be ported to all the urdfs, this is concerning since the procedure is not automated yet via github action.

For disabling the sensor and controllers in the legs we should add a new yarprobointerface xml file and create ad hoc yaml + urdf.
Maybe @traversaro knows how to handle these possible options?
In icub-models we used to generate the yaml via cmake and then run the simmechanics_to_urdf script with the generated yaml, unfortunately right now we cannot yet run via command line creo2urdf:

• CREO2URDF – Add the possibility to run URDF generation from the terminal creo2urdf#53

[traversaro]

Maybe @traversaro knows how to handle these possible options?

I have a few vague ideas, perhaps we can fix a meeting to discuss about this?

[Nicogene]

During today's meeting, it came out that using the fixed model seems to have more impact than these points

• laser sensor removed;
• legs sensors removed;
• legs controllers removed;

Anyhow, @PasMarra will provide the actual impact of removing them on the real-time factor to understand if it makes sense to invest some time in thinking of a postprocessing procedure (via bash/python script) for removing parts of the urdf.

In the meanwhile, I provided to @PasMarra a URDF that has only collisions in the hands/fingers, to understand if this helps to improve the performances.

We spoke also about the possibility of passing parameters to the sdf included in the worlds, that right now it is not a feature available in gyp but it would help using the functionality of yarprobotinterface for enabling/disabling devices (see this example).
This will be useful for @SimoneMic for enabling the ros2 nws, and @GiulioRomualdi (#203) for enabling the wbd device, but it will not improve the real-time factor, since the biggest impact is on the plugins themselves loaded in the urdf.

Anyhow a dedicated issue will be opened in gyp repo.

cc @pattacini

[traversaro]

Anyhow a dedicated issue will be opened in gyp repo.

robotology/gazebo-yarp-plugins#672

[PasMarra]

Hi @Nicogene, these are the results:

Test	fix link	laser	legs sens	legs ctrls	ergoCub meshes	ground mesh	init RTF	min RTF
0	--	x	x	x	x	x	0.86/0.88	0.08
1	--	--	x	x	x	x	0.83/86	0.12
2	--	x	--	x	x	x	0.88/0.90	0.12
3	x	--	--	--	x	x	0.98/0.99	0.11
4	x	x	x	x	--	x	0.99	0.12
5	x	--	--	x	x	x	0.92/0.94	0.15
6	x	x	x	--	x	x	0.99/1.0	0.15
7	x	x	x	x	--	--	0.99	0.17
8	x	--	--	--	--	x	0.99	0.19
9	x	--	--	--	--	--	0.99/1.0	0.22

• x = the component is considered
• -- = the component is NOT considered

Additional details:

1- The fixed link has a noticeable impact on the initial rtf. This is due to the fact that the fixed link sufficiently lifts the robot such to avoid any contact with the ground. In fact, some contacts arise if we use a different spawning height, and the rtf drops consequently:

no sensors and no controllers, spawned at 0.78 m

no sensors and no controllers, spawned at 0.775 m

2 - In the following table, the column "all modules running RTF" represents the rtf value when all the modules are running, and the robot is ready to grasp and waiting for the grasp request.

Test	init RTF	all modules running RTF	min RTF	init - all module running delta RTF (Delta1)	all module running - min delta RTF (Delta2)
0	0.86/0.88	0.49/0.53	0.08	0.36	0.43
1	0.83/86	0.42/0.45	0.12	0.42	0.31
2	0.88/0.90	0.48/0.51	0.12	0.40	0.37
3	0.98/0.99	0.76/0.81	0.11	0.21	0.67
4	0.99	0.85/0.87	0.12	0.11	0.74
5	0.92/0.94	0.87/0.89	0.15	0.05	0.73
6	0.99/1.0	0.89/0.91	0.15	0.09	0.75
7	0.99	0.86/0.88	0.17	0.12	0.70
8	0.99	0.94/0.95	0.19	0.05	0.75
9	0.99/1.0	0.92/0.95	0.22	0.06	0.72

On average, Delta1 gets smaller as Test 9 is approached, that is when the least number of components are involved in the simulation.
On the other hand, If we consider separately the first three tests (without the fixed link) and the other tests (with the fixed link), it seems like the Delta2 is more or less constant.
Nevetheless, on average, the min rtf value grows.

cc: @traversaro @SimoneMic @pattacini

[traversaro]

fyi @xela-95