Buscar este blog

miércoles, 22 de septiembre de 2010

Comments on ROS Time

"ROS has builtin time and duration primitive types, which roslib provides as the ros::Time and ros::Duration classes, respectively. A Time is a specific moment (e.g. "today at 5pm") whereas a Duration is a period of time (e.g. "5 hours"). Durations can be negative."

The function Time::now(), which is used in most of the codes I am working with uses the system time:

Time Time::now()
{
if (!use_system_time_)
{
boost::mutex::scoped_lock lock(g_sim_time_mutex);
Time t = sim_time_;
return t;
}

Time t;
getWallTime(t.sec, t.nsec);

return t;
}


When I create the map in "real time" the time used is the one from my computer:

"When running with a real robot, the ROS client libraries will use "wall-clock" time (i.e. the time your computer reports). "

In the case of the playback of the bag files I have noticed the following:

"if you are playing back sensor data into your system, you may wish to have your time correspond to the timestamps of the sensor data. "

Concerning Clock server:

"If you are playing back a bag file with rosbag play, using the --clock option will run a Clock Server while the bag file is being played."

Map overlapping

After modifying the launch file Renato shared with me, gmapping was no longer displaying neither the TF_OLD_DATA error, nor the dropped messages warnings. However, the map is still overlaping. Here is the content of the launch file I am currently using named launch_rovers.launch. The attempts to change nodes are presented as comments:


What I am doing right now is playing this launch file simultaneously with rviz, with which I have as well some doubts. Here are two screenshots of what the mapping process looks like:



I have been playing with the fixed and the target frames as can be appreciated in the screenshots. I, however, get the same result always: overlapping of the map.

I have noticed that during this process the mobile frame isn't able to fully rotate when it is necessary and this is what I think is causing the overlapping.

I have several suppositions for the generator of this problem:

1. Odometry isn't being correctly actualized.
2. Gmapping has an error (which I have no idea about).
3. The time ins ROS isn't properly actualized nor the buffer is properly being cleaned out when necessary.


I hope the question I placed at the mailing list is soon answered.