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

undesired_contact_detector gets high load since Gazebo 9.16.0 #1

Open
yosuke opened this issue Dec 14, 2020 · 4 comments
Open

undesired_contact_detector gets high load since Gazebo 9.16.0 #1

yosuke opened this issue Dec 14, 2020 · 4 comments

Comments

@yosuke
Copy link
Member

yosuke commented Dec 14, 2020

Gazebo 9.16.0 (2020-11-24) seems to publish contact messages (in gzmessage form) more frequently than the previous versions.
This results in undesired_contact_detector to be very heavy.

@yosuke
Copy link
Member Author

yosuke commented Dec 14, 2020

Result of gz topic -z /gazebo/default/physics/contacts in Gazebo 9.9.0

Hz: 757.29
Hz: 3135.17
Hz: 294.77
Hz: 195.75
Hz: 571.19
Hz: 312.31

@yosuke
Copy link
Member Author

yosuke commented Dec 14, 2020

Result of gz topic -z /gazebo/default/physics/contacts in Gazebo 9.16.0

Hz: 535.92
Hz: 449.76
Hz: 453.55
Hz: 673.86
Hz: 556.43
Hz: 590.84
Hz: 617.81
Hz: 818.10
Hz: 855.72
Hz: 836.09

The difference in Hz is not as large as expected.
May be contained data size in the message?

@yosuke
Copy link
Member Author

yosuke commented Dec 14, 2020

Or maybe the reason is the stabilized frequency of message callbacks in over frequency situations.
Probably better to implement a call skipping function based on the timestamp (10Hz will be enough for contact detection).
The time stamp in the message is in the following format:

time {
  sec: 117
  nsec: 562000000
}

@yosuke
Copy link
Member Author

yosuke commented Dec 14, 2020

CPU load is still high even if we lower the contact detection rate.

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

1 participant