Costmap configuration

I created a new file in the itesm_demo package in order to include all of the configuration files related to the configuration of move_base.

$roscd itesm_demo
$mkdir config
$cd config

I created four files in this folder. The description of each of them follows:

1. costmap_common_params.yaml: Parameters that are common both for local and global costmaps:


obstacle range: determines the maximum range sensor reading that will result in an obstacle being put into the costmap.
raytrace range: determines the range to which we will raytrace freespace given a sensor reading.

footprint: in the case of specifying the footprint, the center of the robot is assumed to be at (0.0, 0.0) and both clockwise and counterclockwise specifications are supported.

Inflation radius: The inflation radius should be set to the maximum distance from obstacles at which a cost should be incurred.

2. global_costmap_params.yaml: long term plans over the entire environment


global frame: defines what coordinate frame the costmap should run in
robot base frame: defines the coordinate frame the costmap should reference for the base of the robot.
static map: determines whether or not the costmap should initialize itself based on a map served by the map_server.

3. local_costmap_params.yaml: local planning and obstacle avoidance

Rolling window: parameter to true means that the costmap will remain centered around the robot as the robot moves through the world.

4. base_local_planner_configuration.-yaml: The base_local_planner is responsible for computing velocity commands to send to the mobile base of the robot given a high-level plan

Successful map

The map created today seems to be fairly coherent. In order to create it I drove the robot around the hallway. Here it is:

Mapping

Today I could make a more or less coherent map of lab conditions. The problem is that my lab's conditions aren't ideal at all ... However, the overlapping of the map, which was the main issue to be solved, seems to have disappeared.

What I did this time was to use the original RosAria node since the one modified by the sscrovers team seems to throw odometry errors due to the introduction of an additional function (update). I will post later my comments concerning this code.

What I did afterwards, was to verify that the cmd_vel message published by the teleoperation node coincided with the one to which RosAria node subscribes to. In this case the specific name of the topic is /RosAria/cmd_vel and its type is geometry::msg.

Tomorrow I will physically construct a map with ideal conditions in order to verify that the odometry issue isn't present at the original RosAria node.

Configuration of the Joystick

1. Verify that Linux recognizes my joystick

$ ls /dev/input/
by-id    event1   event12  event2  event5  event8  mice    mouse2
by-path  event10  event13  event3  event6  event9  mouse0
event0   event11  event14  event4  event7  js0     mouse1

js0 is my joystick's port.

2. Make sure my joystick is working

$ sudo jstest /dev/input/js0

I see the data parameters changing.

3. List the permissions of the joystick

$ ls -l /dev/input/js0

crw-rw-r--+ 1 root root 13, 0 2010-10-12 20:07 /dev/input/js0

This indicates I need to change the mode of the port through:

$ sudo chmod a+rw /dev/input/js0

Listing the permissions again will show this result:

crw-rw-rw-+ 1 root root 13, 0 2010-10-12 20:07 /dev/input/js0

4. Start the joy node

$ rosrun joy joy_node

5. Echo the joy topic

$ rostopic echo joy

And I see the data of my joystick is being published through the joy topic. 

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.

Pablo's pioneer_tf.cpp

Renato shared with me a post of a ROS user that does slam using the ROSARIA node. Here is the url where this post can be found and following the program itself can be found:

http://ros-users.122217.n3.nabble.com/Pioneer3-td1265101.html#a1288712




#include
#include
#include



void poseCallback(const nav_msgs::Odometry::ConstPtr& odomsg)
{
//TF odom=> base_link

static tf::TransformBroadcaster odom_broadcaster;
odom_broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(tf::Quaternion(odomsg->pose.pose.orientation.x,
odomsg->pose.pose.orientation.y,
odomsg->pose.pose.orientation.z,
odomsg->pose.pose.orientation.w),
tf::Vector3(odomsg->pose.pose.position.x/1000.0,
odomsg->pose.pose.position.y/1000.0,
odomsg->pose.pose.position.z/1000.0)),
odomsg->header.stamp, "/odom", "/base_link"));
ROS_DEBUG("odometry frame sent");
}




int main(int argc, char** argv){
ros::init(argc, argv, "pioneer_tf_publisher");
ros::NodeHandle n;

ros::Rate r(20);

tf::TransformBroadcaster broadcaster;

//subscribe to pose info
ros::Subscriber pose_sub = n.subscribe("RosAria/pose", 1, poseCallback);

while(n.ok()){
//base_link => laser
broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(tf::Quaternion(0, 0, 0), tf::Vector3(0.13, -0.04, 0.294)),
ros::Time::now(), "/base_link", "/laser"));

ros::spinOnce();
r.sleep();
}
}