johnhsu at willowgarage.com
Wed Nov 10 02:14:43 UTC 2010
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
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.:
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.
On Tue, Nov 9, 2010 at 4:40 PM, nickopen <nicholas.hillier at gmail.com> 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:
> Sent from the ROS-Users mailing list archive at Nabble.com.
> ros-users mailing list
> ros-users at code.ros.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ros-users