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

gazebo_ros: Wait spawning Gazebo Model until ros::Time::now() is not 0. #1024

Open
wants to merge 1 commit into
base: melodic-devel
Choose a base branch
from

Conversation

marcin-sielski
Copy link

Why:

  • Plugin incorrectly sends failure status message.

This change addresses the need by:

  • Looping over ros::Time::now() until non-zero is returned.

Why:

* Plugin incorrectly sends failure status message.

This change addresses the need by:

* Looping over ros::Time::now() until non-zero is returned.
@@ -2660,6 +2660,8 @@ bool GazeboRosApiPlugin::spawnAndConform(TiXmlDocument &gazebo_model_xml, const

/// \brief poll and wait, verify that the model is spawned within Hardcoded 10 seconds
ros::Duration model_spawn_timeout(10.0);
/// Wait until time can be read.
while (ros::Time::now().is_zero());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If simulation is started paused, this line will hang until simulation starts running. I'm not sure if this is desired.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might make more sense to switch this to be wall time not ROS time. I'm assuming this is resource contention based and not simulation time passing. Then we won't need to worry about whether ROS time is initialized.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand the comment form @spark4160 it is related to simulation time passing.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where would I find the file gazebo_ros_api_plugin?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

@hichamhendy hichamhendy Jun 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I installed gazebo ros packages using sudo apt-get install ros-melodic-gazebo-ros-pkgs ros-melodic-gazebo-ros-control and I can not find this directory!
image

Where would I find the file on melodic distribution?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hichamhendy did you find a solution for this

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I skipped it!!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the terminal that launched my gazebo world and found the errors that I needed to fix there. So if the URDF file has any issues, it doesn't load and times out.

@spark4160
Copy link

I encountered this problem while spawning models as gazebo starts using worlds that had the sim_time, real_time and wall_time tags in the world definition set to positive values. This meant the timeout variable was getting set when ros::Time::now() was returning 0 but as soon as the world actually started, the clock would skip forward to the defined sim_time and the spawn would immediately time out.

It's not a solution to this issue as the spawn model service should handle this case, but if you're reading this, check the sim_time of your world.

mdepp added a commit to UofA-SPEAR/software that referenced this pull request May 1, 2020
@grassjelly
Copy link

I encountered this problem while spawning models as gazebo starts using worlds that had the sim_time, real_time and wall_time tags in the world definition set to positive values. This meant the timeout variable was getting set when ros::Time::now() was returning 0 but as soon as the world actually started, the clock would skip forward to the defined sim_time and the spawn would immediately time out.

It's not a solution to this issue as the spawn model service should handle this case, but if you're reading this, check the sim_time of your world.

This worked for me

@kvnptl
Copy link

kvnptl commented Mar 20, 2021

I encountered this problem while spawning models as gazebo starts using worlds that had the sim_time, real_time and wall_time tags in the world definition set to positive values. This meant the timeout variable was getting set when ros::Time::now() was returning 0 but as soon as the world actually started, the clock would skip forward to the defined sim_time and the spawn would immediately time out.

It's not a solution to this issue as the spawn model service should handle this case, but if you're reading this, check the sim_time of your world.

Setting sim_time to 0, fixed my problem

@roboticlemon
Copy link

Changing sim_time in my .world file also fixed this issue for me.

@rk800506
Copy link

Changing sim_time in my .world file also fixed this issue for me.

can u just show where did you set the 'sim_time' .. image of part of the world file

@kvnptl
Copy link

kvnptl commented Jul 24, 2021

Changing sim_time in my .world file also fixed this issue for me.

can u just show where did you set the 'sim_time' .. image of part of the world file

check your world file,
image

@rk800506
Copy link

Changing sim_time in my .world file also fixed this issue for me.

can u just show where did you set the 'sim_time' .. image of part of the world file

check your world file,
image

thanks a lot.

@SwastikNandan
Copy link

This was both helpful and inciteful.

@SwastikNandan
Copy link

I encountered this problem while spawning models as gazebo starts using worlds that had the sim_time, real_time and wall_time tags in the world definition set to positive values. This meant the timeout variable was getting set when ros::Time::now() was returning 0 but as soon as the world actually started, the clock would skip forward to the defined sim_time and the spawn would immediately time out.

It's not a solution to this issue as the spawn model service should handle this case, but if you're reading this, check the sim_time of your world.

This was helpful. It worked like magic!

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

Successfully merging this pull request may close these issues.

None yet