"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."
Buscar este blog
miércoles, 22 de septiembre de 2010
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.
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.
Suscribirse a:
Entradas (Atom)