V-Rep should publish to the /clock topic
Re: V-Rep should publish to the /clock topic
I was facing a similar problem to publish a tf tree and odometry data to ROS using the rosInterface implementation method. Rviz was giving me errors of Message removed because it is too old ..., which is because rviz by default uses ROS Time, while rosInterface implementation broadcasts in Simulation time. fferri suggestions were quite useful, so I would like to summarize them for the record, and add an extra point.
- You need to set /use_sim_time parameter in ROS to true right after running roscore and before launching any other ROS related command.
- Make sure that you are publishing from v-rep into /clock topic in ROS as instructed by fferri.
- Anywhere in the child script of v-rep that you need the time stamp, use the function simGetSimulationTime() and not simGetSystemTime().
- You need to set /use_sim_time parameter in ROS to true right after running roscore and before launching any other ROS related command.
- Make sure that you are publishing from v-rep into /clock topic in ROS as instructed by fferri.
- Anywhere in the child script of v-rep that you need the time stamp, use the function simGetSimulationTime() and not simGetSystemTime().
Re: V-Rep should publish to the /clock topic
Thanks for the precision!
Cheers
Cheers
Re: V-Rep should publish to the /clock topic
I have a console in which I print the output of clock, i.e: rostopic echo /clock
When I start the scene for the first time it works fine, but if I stop it and then start it again, the console needs some time to start printing the messages, sometimes even several seconds.
Can anybody reproduce this behaviour?
Regards
When I start the scene for the first time it works fine, but if I stop it and then start it again, the console needs some time to start printing the messages, sometimes even several seconds.
Can anybody reproduce this behaviour?
Regards
Re: V-Rep should publish to the /clock topic
Hello,
can you confirm that simulation is running and messages are being sent? OR is the simulation during that time halted too?
Cheers
can you confirm that simulation is running and messages are being sent? OR is the simulation during that time halted too?
Cheers
Re: V-Rep should publish to the /clock topic
Yes, the simulation is running and other messages are being published using the RosInterface plugin while the /clock remains frozen for up to a few seconds.
This only happens, when I stop and play the simulation again leaving the console with "rostopic echo /clock" open. If I ctrl+C this console and start a new subscriber using the same command and press the play button in V-REP it works flawlessly.
Regards
This only happens, when I stop and play the simulation again leaving the console with "rostopic echo /clock" open. If I ctrl+C this console and start a new subscriber using the same command and press the play button in V-REP it works flawlessly.
Regards
Re: V-Rep should publish to the /clock topic
This may be related https://github.com/ros/ros_comm/issues/176
from dirk-thomas:
from dirk-thomas:
This is a fundamental design choice of ROS and not "fixable". The connections between nodes happens after each node is started so messages can get lost until all these connections are made.
You should design your nodes in a way that they either do not rely on each message to arrive or consider using latched topics to at least get the last message when the connections is established after it was initially published.
Re: V-Rep should publish to the /clock topic
I was wrong when I checked the other messages. I was checking a message that was being published via a plugin I did. If I check a message published with the RosInterface plugin it also takes a while to publish if I was already subscribed to it when the simulation started.
I am going to open a new thread since it is not a clock issue as I first thought.
edit: this is the same problem I have described viewtopic.php?f=5&t=6180&p=24908&hilit= ... ace#p24908
I am going to open a new thread since it is not a clock issue as I first thought.
edit: this is the same problem I have described viewtopic.php?f=5&t=6180&p=24908&hilit= ... ace#p24908
Re: V-Rep should publish to the /clock topic
Hello,
After I download the "slamDemo", looks like CMakeList.txt (armesto/groovy_catkin_ws/src) is corrupted.
So that's why I am unable to build the file through catkin_make?
After I download the "slamDemo", looks like CMakeList.txt (armesto/groovy_catkin_ws/src) is corrupted.
So that's why I am unable to build the file through catkin_make?
Re: V-Rep should publish to the /clock topic
@fferi
I am doing what you say with publishing GetSimulationTime(). However, everytime i stop the sim to modify something, and restart it, the ros nodes become unsynchronized because i am using the "realtime" setting in Vrep, and when it is restarted it restarts from 0 seconds.
I tried using GetSystemTime() instead, but unfortunately that did not work. What i mean, is that with GetSystemTime(), my trajectory controllers are not able to move the robot at all. With GetSimulationTime() they work, but i can't stop/play..
I am doing what you say with publishing GetSimulationTime(). However, everytime i stop the sim to modify something, and restart it, the ros nodes become unsynchronized because i am using the "realtime" setting in Vrep, and when it is restarted it restarts from 0 seconds.
I tried using GetSystemTime() instead, but unfortunately that did not work. What i mean, is that with GetSystemTime(), my trajectory controllers are not able to move the robot at all. With GetSimulationTime() they work, but i can't stop/play..
Re: V-Rep should publish to the /clock topic
Then you will have to find an intermediate solution, or hybrid solution. When simulation is not running, then robots won't move either.
You can also find an alternate way of stopping/restarting a simulation without actually stopping the simulation: you can modify the main script so that if a certain custom user interface button is clicked, then you would skip the regular part of the main script.
Cheers
You can also find an alternate way of stopping/restarting a simulation without actually stopping the simulation: you can modify the main script so that if a certain custom user interface button is clicked, then you would skip the regular part of the main script.
Cheers