Building a Map

TurtleBot maps are build with gmapping. You can tweak this algorithm by modifying parameters on launch/includes/_gmapping.launch file.

First, you need to start the robot drivers ,
and then start the ROS node responsible for building the map.

It has to be noted that to build a map ROS uses the gmapping software package, that is fully integrated with ROS.
The gmapping package contains a ROS wrapper for OpenSlam’s Gmapping. The package provides laser-based SLAM (Simultaneous Localization and Mapping), as a ROS node called slam_gmapping.
Using slam_gmapping, you can create a 2-D occupancy grid map (like a building floorplan) from laser and pose data collected by a mobile robot.

On terminals:
$ roscore
$ roslaunch turtlebot_bringup minimal.launch
$ roslaunch turtlebot_navigation gmapping_demo.launch

Move the robot ：
$ roslaunch turtlebot_rviz_launchers view_navigation.launch
$ roslaunch turtlebot_teleop keyboard_teleop.launch

save the built map ：
$ rosrun map_server map_saver -f /tmp/my_map

will generate two files with the name you specified in the map_server commnd.
So in this case, the two files’ names are my_map.pgm and my_map.yaml.
If you open the .yaml file you will see something like this:

image: /tmp/my_map.pgm
resolution: 0.050000
origin: [-12.200000, -12.200000, 0.000000]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.196

The .yaml contains meta data about the map, including the location of image file of the map, its resolution, its origin, the occupied cells threshold, and the free cells threshold. Here are the details for the different parameters:
* image: has a pgm format which contains numeric values between 0 and 255. It represents the path to the image file containing the occupancy data; can be absolute, or relative to the location of the YAML file
* resolution: it is the resolution of the map and is expressed in meters/pixel, which means in our example 5 centimers for each cell (pixel).
* origin: The 2-D pose of the lower-left pixel in the map, as (x, y, yaw), with yaw as counterclockwise rotation (yaw=0 means no rotation). Many parts of the system currently ignore yaw.
* occupied_thresh: Pixels with occupancy probability greater than this threshold are considered completely occupied.
* free_thresh: Pixels with occupancy probability less than this threshold are considered completely free.
* egate : Whether the white/black free/occupied semantics should be reversed (interpretation of thresholds is unaffected)

Now, for the second file, that is the .pgm image file, it is just a gray-scale image of the map which you can open using any image editor program
It is recommended to use the The GNU Image Manipulation Program to open and edit PGM files.

The gray area represents an unknown non-explored space.
The white area represents the free space,
and the black area represents obstacles (e.g. walls).

You can open this file with any text editor like gedit or kate to see its content.
In what follow, we present the four first lines of a typical pgm file :

P5
# CREATOR: GIMP PNM Filter Version 1.1
600 600
255

The first line, P5 identifies the file type.
The third line identifies the width and the length in number of pixels.
The last line represents the maximum gray scale, which is this case 255 that represents the darkest value. The value 0 in a PGM file will represent a free cell.

desription of turtlebot_navigation gmapping_demo.launch:

First it starts the 3dsensor launch file which will runs either Asus Xtion Live Pro or Kinect 3D sensor of the Turtlebot.
It sets some parameters to their default values and specifies that the scan topic is refered to as /scan.
Then, it will start the gmapping.launch.xml that contains the specific parameters of the gmapping SLAM algorithm (parameters of the particle filter) that is responsible for building the map.
Finally, it will start the move_base.launch.xml that will initialize the parameters of the navigation stack, including the global planner and the local planner.

Practical Considerations

When building a map with a Turtlebot it is possible to get a good or bad map depending on several factors:
First of all, make sure that your Turtlebot robot and its laptop have full batteries before starting the mapping tasks. In fact, gmapping and rviz both consume a lot of power resources.

The quality of the generated map greatly depends on quality of range sensors and odometry sensors. For the Turtlebot, it has either the Kinect or Asus Xtion Live Pro camera with only 4 meters of range, and only 57 degree of laser beam angle, which render it not appropriate for scanning large and open space environments. Thus, if you use Turtlebot to build the map for a small environment where walls are not far from each others, it is likely that you will get an accurate map.

However, if you build the map for a large and open space environment, then it is likely that your map will not be accurate at a certain point of time. In fact, in large and open space environment, you need to drive the robot for long distance, and thus, the odometry will play a more cruicial role in building the map. Considering the fact that the odometry of the Turtlebot is not reliable and is prone to errors, these errors will be cumulative over time and will quickly compromise the quality of generated maps.
It will interesting to try using your Turtlebot to build maps for both small environment and large environment and observe the accuracy of the map for each case.

ADCANCED

gmapping package:

This package contains a ROS wrapper for OpenSlam’s Gmapping. The gmapping package provides laser-based SLAM (Simultaneous Localization and Mapping), as a ROS node called slam_gmapping. Using slam_gmapping, you can create a 2-D occupancy grid map (like a building floorplan) from laser and pose data collected by a mobile robot.
slam_gmapping package: slam_gmapping contains a wrapper around gmapping which provides SLAM capabilities.

To use slam_gmapping, you need a mobile robot that provides odometry data and is equipped with a horizontally-mounted, fixed, laser range-finder.
The slam_gmapping node will attempt to transform each incoming scan into the odom (odometry) tf frame.

For Example To make a map from a robot with a laser publishing scans on the base_scan topic:
$ rosrun gmapping slam_gmapping scan:=base_scan

10-mapping

(1) ssh to On TurtleBot :
$ roslaunch turtlebot_bringup minimal.launch
$ roslaunch turtlebot_navigation gmapping_demo.launch

(2) On local workstation :
$ roslaunch turtlebot_rviz_launchers view_navigation.launch
$ roslaunch turtlebot_teleop keyboard_teleop.launch

(3) using teleoperation from local machine, navigate TurtleBot around the entire area you wish to map

(4) if complate, using ssh to save the map on remote robot:
$ rosrun map_server map_saver -f map_file:=/home/dehaou1404/zMAP/my_map_half.yaml
NOTE: not use relative sunch as ~, use /home…

(5) you can find the map and yaml
$ ls /tmp/

Useful for compatibility checking and introspection.
$ rosrun kobuki_driver version_info

PART I installtion

This instruction describes how to install Kobuki ros packages and get you ready to play with Kobuki.

1. Install Kobuki
$ sudo apt-get install ros-indigo-kobuki ros-indigo-kobuki-core

2. Set udev Rule
Copy across a udev rule for /dev/kobuki port and add your user to the dialout group (you may need to log out and log back in).
Connection to the kobuki base is via usb enabled by an ftdi usb-serial converter which is always pre-flashed at the factory with the serial id kobuki. For convenience, to enable the device to appear on /dev/kobuki, use the following script to copy across the udev rule and restart udev (you’ll need your sudo password):
$ rosrun kobuki_ftdi create_udev_rules

NOTE for none ros users:
In case you are not in a ROS environment, you will need to build the package first, in order to get the create_udev_rules script.
To do so navigate to the package folder and do
$ make udev

3. Keyboard Teleoperation
Ready to rock! With all the software you have installed so far, you should be able to teleoperate your kobuki around with your keyboard!

# This launches the minimal operation configuration
$ roslaunch kobuki_node minimal.launch

# This launches the keyboard teloperation node
$ roslaunch kobuki_keyop keyop.launch

PART II Inspection

Inspect the sensors’ state and send commands.

1. start minimal.launch to bring up Kobuki’s basic software (bootstrap layer). We use the argument –screen to get verbose output in the terminal.
> roslaunch kobuki_node minimal.launch –screen

2. take a look at Kobuki’s topics.
$ rostopic list
/sensor/: Continuous streams of the sensor’s data (note that /odom and /joints_states are remapped by default, since they are widley used at the highest level/namespace)
/events/: If a sensor changes its state, e.g. bumper pressed/released, the new state is published here.
/commands/: Use these topics to make Kobuki do things like switch on LEDs, playing sounds and driving around.
/debug/: Outputs detailed info about a lot of Kobuki’s internals.

3. Check sensors
$ rostopic echo /mobile_base/events/bumper
state: 1
bumper: 2
$ rostopic echo /mobile_base/events/wheel_drop
state: 1
wheel: 0

$ rostopic echo /mobile_base/sensors/imu_data
header:
seq: 0
stamp:
secs: 1355022789
nsecs: 36483345
frame_id: gyro_link
orientation:
x: 0.0
y: 0.0
z: 0.28769484546
w: 0.957722128749

Change the color or turn off a LED:
$ rostopic pub /mobile_base/commands/led1 kobuki_msgs/Led “value: 1”
$ rostopic pub /mobile_base/commands/led1 kobuki_msgs/Led “value: 0”

Play a sound:
$ rostopic pub /mobile_base/commands/sound kobuki_msgs/Sound “value: 6”

PART III Manupulation

Make it move

$ roslaunch kobuki_node minimal.launch –screen
$ roslaunch kobuki_keyop safe_keyop.launch –screen
There is also a normal keyop launcher (keyop.launch). The difference between both is, that safe_keyop makes use of a velocity smoother and Kobuki’s safety controller.

PART IV automatic docking

This tutorial will show you how to run automatic docking with kobuki, and will give you a brief description of algorithm. The code is located in kobuki_auto_docking package.

To run automatic docking properly, docking station should be placed in an open space of at least 2 meters wide by 5 meters long. There should be no obstacles between kobuki robot and docking station. And the dock station should be held by a wall or something heavy enough to prevent the robot to push it. A static red light on top of the docking station signals that it is powered on properly.

If you already launched kobuki_node, load the auto-docking nodelet into the running kobuki core. For convenience, just type:

$ roslaunch kobuki_auto_docking minimal.launch –screen
Or if you have not launched the kobuki core yet, type:
$ roslaunch kobuki_auto_docking compact.launch –screen
Be aware that this is just loading the algorithm; it is still not active. The algorithm is implemented as a typical action server. You need to call the server via an action client.

To activate it type:
$ roslaunch kobuki_auto_docking activate.launch –screen

Kobuki’s docking station has 3 IR(Infrared) emitters. The emitted IR lights cover three regions in front of the docking station: left, central and right, each divided in two sub-fields: near and far. Each beam encodes this information, so the robot knows at any moment in which region and sub-field he is. Also, as regions and fields are independently identified, they can be overlap on its borders.

Kobuki has 3 IR receivers. When the robot is placed within the field of the docking station, and at least one IR receiver is facing toward it, the robot will catch the signal and stream it to the controller netbook. The information is available on /mobile_base/sensors/dock_ir topic, in the form of kobuki_msgs/DockInfraRed messages

PART V Kobuki’s Control System

A note on Nodelets
Nodelets are heavily used in Kobuki’s control system. They have various benefits over normal nodes. The most important among them are avoiding serialising/deserialising of messages and the transmission over the TCP/IP. This is done by passing pointers to messages instead of the messages themselves. That means messages are faster processed and transmitted. When working with big messages, such as point clouds, this can also significantly lower the CPU consumption.

For our use case, the speed improvement is important, that is why we implement controllers and other speed-sensitive parts of Kobuki’s control system as nodelets.
Implementing code as nodelets instead of node is nothing to be afraid of as the the next tutorial will show.

Kobuki’s control system uses three different components.

kobuki_node: (AKA mobile base) is actually a nodelet, which wraps the C++ driver for communicating with Kobuki
cmd_vel_mux: is a velocity command multiplexer (or in otherwords a switch). It manages multiple incoming velocity commands according to the configured priority.
Kobuki controller: is a nodelet-based controller type – used for various applications; one example is the kobuki_safety_controller, which watches the bumper, cliff and wheel drop sensors and acts accordingly. Use this to implement your own reactive controller (see the next tutorial).
Furthermore, there is an implementation of a velocity smoother: yocs_velocity_smoother. This tool is optional, but highly recommended to use. In case a node publishing velocity commands can’t ensure their smoothness, put this smoother in between that node and the cmd_vel_mux.

The three components introduced above are used in a small hierarchy. Starting bottom-up, there is the mobile base, which listens for commands (LEDs, sounds, velocity) and publishes sensor information. On top of that we use the cmd_vel_mux, which makes sure, that only one velocity command at a time is relayed through to the mobile base. On the next level we have one or more controllers and other programs, such as keyboard teleop and the navi stack. There are cases, in which we want smooth velocity (e.g. keyop) and cases in which we don’t (safety controller). So, use the velocity smoother when necessary.

In the shown scenario, there are multiple programs, which want to control Kobuki’s movement. The velocity muxer allows using all of them in parallel. An example multiplexer configuration could be the following:
Priorities:
3 (highest priority): safety controller
2: keyboard teleop
1: android teleop
0 (lowest priority): navi stack teleop
In this case, the navi stack would control the robot in most of the times. However, the user can override navi stack’s commands, by triggering commands with the Android teleop app or the keyboard teleop. In case both teleops would be active at the same time, keyboard teleop would win. However, all the velocity commands above will be overridden when the safety controller kicks in (bumper, cliff or wheel drop sensor activated). This allows safe driving of Kobuki with all three tools.

IMG
https://docs.google.com/drawings/pub?id=1AP_T-5yWtVKxe981M7h8I9Paxd8gfzGIqvLZEudCG9k&w=750&h=1091

CHAPTER VI write nodelet

how to write and run a simple nodelet-based controller for Kobuki.

In this section we will create a simple “blink, when a bumper is pressed” controller, which will be similar to the Kobuki’s safety controller.

You find the code explained in the following paragraphs in the kobuki_controller_tutorial package. We will also make use of the default controller from yocs_controllers.

First create a new package for this controller in your workspace. We use roscreate-pkg to add the dependencies right away:
$ catkin_create_pkg kobuki_controller_tutorial roscpp yocs_controllers std_msgs kobuki_msgs nodelet

REF: https://charlyhuangrostutorial.wordpress.com/category/ros%E8%87%AA%E5%AD%B8%E7%AD%86%E8%A8%98/