Nicolas, Sorry I had your scenario backwards, to clarify it seems that you want to use gazebo to simulate dynamic obstacles while driving the real robot? Then use_sim_time does not appear to be the right option here. Gazebo is designed to try and simulate physics/dynamics, if that's not something you care about in your particular scenario, then OpenRAVE is also a good suggestion. One reason here to proceed with gazebo is assuming you have your dynamic obstacles setup already in gazebo simulator, then you can try the following: Spawn your robot as a static model. Create a ros node to update the pose of the simulated robot by feeding the real robot's published odometry to gazebo/set_model_state for your static robot in simulation. This should take care of the simulated sensor generation for your simulated dynamics obstacles. Assuming your dynamic obstacles world can be simulated faster than real-time, to ensure your simulated sensor generation rates are close to what you specify in real world wall clock time, you can throttle your overall simulation update rate by setting updateRate to be 1/dt to limit your gazebo simulation to 1X real-time, e.g.: 0.001 ... 1000 This is not something I have tried personally, so please let me know if you have any trouble getting this to work, I'll be glad to help out further. Best, John On Tue, Nov 9, 2010 at 4:40 PM, nickopen wrote: > > Depending on how much effort you have spent integrating wth Gazebo, I would > suggest considering using OpenRAVE for this sort of work. We use if for a > number of simulation and planning roles including a case very similar to > what you describe - we have run a robot with "virtual" obstacles that only > exist in in the simulation environment, so the robot considers obstacles > gathered from real data from its sensors and also an obstacle that only > existed in the simulation. There are nodes/plugins that provide this > functionality in the openrave_planning stack. > > We overcame synchronisation problems between real-time on the robot and > simulation time by simplifying the simulation as required to get it to run > close-to real time. For short-term experiments it ran fine, there are > probably better ways to do that though. > -- > View this message in context: > http://ros-users.122217.n3.nabble.com/Gazebo-tp1859978p1873283.html > Sent from the ROS-Users mailing list archive at Nabble.com. > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >