Home | Tutorials | Wiki | Issues
Ask Your Question

How to accelerate a simulated robot and get the same result as when I use real time factor?

asked 2016-01-26 12:23:48 -0500

Durath gravatar image

Hi all,

I have a robot (any body), which I can control through a Twist message. Let's say I put the robot in position (0,0) with world as reference. From my code, I publish a topic which makes the robot moves at 1 m/s during 1 second, like:

rostopic pub -1 /cmd_vel geometry_msgs/Twist '{linear: {x: 1.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}'

So, after a second I publish another topic like:

rostopic pub -1 /cmd_vel geometry_msgs/Twist '{linear: {x: 0.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}',

to stop the robot. This is successful and the robot moves 1 meter forward (to position 1,0).

The problem is that the robot must move a lot of times to cover an area (thousand of movements). So I want to accelerate the simulation with the physics include (to check collisions). But, if I modify the real time factor to 0, to be as faster as possible, of course the robot moves faster but the same published messages will make the robot moves further than (1,0). So the result of Twist messages will be different.

I would like to know if there is a way to accelerate the simulation, in an independent way of the commands I send: So if I have, let's say, 100 messages published to make the robot moves forward, the robot will delay 100 seconds to move 100 meters. With these same messages parameters, I would like to know If I can accelerate the simulation to shorter times.

PD: I decreased the time for which I stop the robot. So I can have a movement of 100 m/s during 0.01 seconds. But the same as before happens. If I modify the real time factor, the robot moves really faster (which is what I want), but with different result as if I use the real time factor set to normal time. Instead of moves 100 m, it moves 120/130 or different things.

I really appreciate your help

Thank you

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2016-01-28 23:18:24 -0500

dcconner gravatar image

updated 2016-01-28 23:19:20 -0500

Unless your plugin timed out after 1 second of simulation time, the model will continue to act on the last command.
It is integrating on the old command for more simulation time.

I suspect that rostopic pub is using wall clock and not simulation time to determine how fast it updates.

If you publish your updates faster, I suspect that will fix your issue. The other issue will be delay.

The communications can't go faster, so if there is a delay between your detection of an event and processing time and comms time for your updated topic, running faster simulation time, will increase the apparent delay in getting the updated signal.

edit flag offensive delete link more


Hi dcconner, Yes, If I publish my updates (move, stop) faster when the simulation real time factor is accelerated (greater to one), I compensate it. But, I supposed there is a way to move the robot at 1 m/s during 1 second, but, with everything going faster in the simulation, lets say, 10 times faster. So the simulated robot will take 0.1 seconds to move 1 meter. But yes, the problem is that I am using wall time after each publish: move... sleep(1 second) stop and so on...

Durath gravatar imageDurath ( 2016-01-29 08:12:16 -0500 )edit

When you say "take 0.1 seconds to move", do you mean 0.1 wall clock. Then this should be working, If you mean 0.1 simulation, then you need to increase velocity command that is being integrated. If you are sending the commands programaticaly then you can use the /clock to get the simulation time (not wall time) and trigger your events off of simulation time. Use the ros::Time sleep functions instead of your OS sleep

dcconner gravatar imagedcconner ( 2016-01-29 12:31:46 -0500 )edit

I am going to try that! Thank you

Durath gravatar imageDurath ( 2016-02-01 06:34:33 -0500 )edit
Login/Signup to Answer

Question Tools



Asked: 2016-01-26 12:23:48 -0500

Seen: 680 times

Last updated: Jan 28 '16