Weird Simulation Performance in Different Laptop Power Modes

[vigisushrutha23]

The issue is regarding the performance of the Walking in simulation for ergocubGazeboV1_1. The simulation is setup on a ubuntu 22.04 docker as built using the repo https://github.com/SimoneMic/docker_ergocub/tree/docker_ergocub_iron . When running gazebo and attempting to walk weird CPU usage as well as walking performance was observed.

When the power mode of the laptop is set to performance mode, we get a good real time factor of 0.99. But unfortunately the walking fails before even making a proper step and the cpu usage of the WalkingModule is very low. Below is a screen recording of the simulation along with "top" output in the terminal.

https://github.com/icub-tech-iit/ergocub-software/assets/5215434/c6878ca0-ad6b-41fa-9fd3-b7902db32523

Screenshot of Laptop cpu usage:

When we instead set the power mode to power saver then the walking is stable and the WalkingModule uses more CPU, as can be seen in the video below.

https://github.com/icub-tech-iit/ergocub-software/assets/5215434/2db26d6f-78b1-4d46-be6c-c10aefa50eff

Screenshot of Laptop CPU usage:

I am not entirely certain as to why this happens. The causes could be related to docker, gazebo or something else. In the power save mode the simulation is really slow but at least the robot does not fall down while walking. I am hoping that we can work towards a solution that will allow us to run the simulation at a higher real time factor while maintaining the stability of walking.

cc: @mebbaid @SimoneMic

[traversaro]

(Replying here, @Nicogene if you prefer that this issue is moved elsehere please comment, thanks).

Thanks for the report @vigisushrutha23 ! Looking as a preliminary step to your Docker, I noticed something strange, that I do not know if they are related to the issue, but may be in some strange way:

• Any reason you use YARP 3.8 ? YARP 3.8 is relatively old (almost a year old, see https://github.com/robotology/yarp/releases/tag/v3.8.1) and is not the version tested by most our experiments
• You are installing manually YARP, YCM and gazebo-yarp-plugins pinned to some specific branch or tag, but then you also download and install the master branch of the robotology-superbuildd, I see that you are passing -DROBOTOLOGY_ENABLE_CORE=OFF, but then if you are enabling -DROBOTOLOGY_ENABLE_DYNAMICS at least YARP is compiled as a dependency of bipedal-locomotion-framework and walking-controllers, so effectively you have both YARP 3.8 and YARP 3.9 present in the machine, and that can result in unexpected behaviour.

Beside that, are you sure that the synchronization done by YARP_CLOCK is working as expected? For that, I guess it may be useful to have a output of the walking-controllers log.

[traversaro]

I just noticed that WalkingModule is printing some warnings as super high frequency, probably it could make sense to try to avoid this to happen.

[traversaro]

I just noticed that WalkingModule is printing some warnings as super high frequency, probably it could make sense to try to avoid this to happen.

The warning was added in blf in https://github.com/ami-iit/bipedal-locomotion-framework/pull/790 . Probably you need a walking-controllers that include https://github.com/robotology/walking-controllers/pull/162 ?

[traversaro]

I just noticed that WalkingModule is printing some warnings as super high frequency, probably it could make sense to try to avoid this to happen.

The warning was added in blf in ami-iit/bipedal-locomotion-framework#790 . Probably you need a walking-controllers that include robotology/walking-controllers#162 ?

See also https://github.com/robotology/walking-controllers/issues/174 . An alternative solution is to go back to a blf version before 0.18.0, for example 0.17.0 .

[traversaro]

I just noticed that WalkingModule is printing some warnings as super high frequency, probably it could make sense to try to avoid this to happen.

The warning was added in blf in ami-iit/bipedal-locomotion-framework#790 . Probably you need a walking-controllers that include robotology/walking-controllers#162 ?

See also robotology/walking-controllers#174 . An alternative solution is to go back to a blf version before 0.18.0, for example 0.17.0 .

Actually looking back at the Docker, it seems that walking-controllers from a fork is used https://github.com/SimoneMic/walking-controllers/tree/ergoCub_SN000 . Why a fork is needed, can't you just use the walking-controllers master branch? If a fork is needed (but I strongly suggest to submit any change as a PR, to avoid integration challenges as this) you need to backport https://github.com/robotology/walking-controllers/pull/162 to your fork.

[vigisushrutha23]

I just noticed that WalkingModule is printing some warnings as super high frequency, probably it could make sense to try to avoid this to happen.

The warning was added in blf in ami-iit/bipedal-locomotion-framework#790 . Probably you need a walking-controllers that include robotology/walking-controllers#162 ?

See also robotology/walking-controllers#174 . An alternative solution is to go back to a blf version before 0.18.0, for example 0.17.0 .

Actually looking back at the Docker, it seems that walking-controllers from a fork is used https://github.com/SimoneMic/walking-controllers/tree/ergoCub_SN000 . Why a fork is needed, can't you just use the walking-controllers master branch? If a fork is needed (but I strongly suggest to submit any change as a PR, to avoid integration challenges as this) you need to backport robotology/walking-controllers#162 to your fork.

Sorry I forgot to mention this....But I tested with the master branch as well and had the similar result. The fork for the walking controller allows us to interface Ros2 navigation commands to the walking controller. I think @SimoneMic plans for a permanent PR later.

Also when I use master I don''t get the frequency warnings from the WalkingModule but instead the following is printed.

[traversaro]

Ok, good to know! So we can rule out that the problem is in the warning. Those other message are just occurring once every second, so I think they are good to go, so I think other things that make sense to cleanup:

• Only use a single YARP in the docker image
• Ensure that YARP_CLOCK is published by Gazebo and read by the WalkingModule .

[traversaro]

If you like I am in AMI open space to quickly discuss the issue in person, however it may be hard to debug the issue until it is reproduced in an environment/image without the duplicated YARP problem.

[vigisushrutha23]

As advised we removed the standalone yarp (keeping only 3.9) and cleaned up the docker. After running multiple permutation and combinations along with @mebbaid , we observed the behavior reported in the issue only while using the navigation mode of walking in our fork of the walking controller. Reverting some of the params to match with master allowed for more stable walking but the walking motions are still much slower when compared to when using the master branch of the walking controller. Sufficient to say the problem seems to be isolated in our mode of walking, hence I am closing this issue. Thanks for the advice @traversaro .