CSCE 452/752: Project 4

Overview and purpose

This assignment asks you to create software that determines a robot's position within a given map. The purpose is to give you some practice designing and implementing an algorithm for a simple form of mobile robot localization.

Your task

A differential drive robot moves over a floor composed of colored square tiles, some of which are light-colored and some of which are darker. When the robot is activated, it has access to a map showing the floor colors, but it does not know its own location.

As the robot moves across this floor, it wants to estimate its own position as accurately as it can. Fortunately, our robot has access to several sources of information that can help.

The robot is controlled by twist messages that contain linear and angular velocities. The robot's movements track somewhat closely to the given commanded velocities, but are noisy.
The robot has a color sensor aimed downward at the floor. This sensor provides noisy measurements of the color the robot is moving over. Unfortunately, the sensor does not come with documentation about how to interpret its outputs.
The robot has a compass that reports the robot's orientation with relatively high accuracy.

Your job is to design and implement a passive global localization algorithm that uses these sources of information and to demonstrate your algorithm's effectiveness on a selection of input cases.

Input data

Here is a collection input files to test your system:

Project 4 data

This archive includes bag files of recorded sensor data. Each bag is associated with a world file, which is a YAML file that describes the floor the robot is operating on for that bag. You should provide the name of the appropriate world file to your system, using a parameter or some other method, at run time.

Here is an example world file, including some comments documenting what you can expect:

Contents of file: cave.world

# Each cell is a square with this side length,
# measured in meters.
resolution: 1.2

# What does the floor look like?
#   # = dark colored floor
#   . = light colored floor
#   Each non-empty line represents one row.
#   Spaces and empty lines should be ignored.
#
# The origin of the 'world' frame is at the
# bottom left of this map, with its positive
# x-axis going to the right and its positive
# y-axis going up from there.
map: |
    ##################
    ###....#####.....#
    #................#
    #............#...#
    ##############...#
    #####...###..#...#
    ##.......#.......#
    ###..............#
    ###...#........###
    ##....############
    ###.......###...##
    ###.............##
    ###....##.....####
    ##################

The correspondence between bags and world files is shown in the table below.

Bag	World
11	light.world
12	dark.world
13	windy.world
14	windy.world
15	code.world
16	code.world
17	cave.world

To discourage overfitting, bags 18-20 are not available yet, and will be posted very close to the submission deadline.

To assist with testing and debugging, here are the robot's actual starting poses for some of the input bags.

Bag	Starting Pose $(x, y, \theta)$
11	(2.21, 5.64, -0.70)
12	(6.28, 3.13, -0.45)
13	(9.80, 6.52, 1.67)

However, your system must not use this information about the starting location — these are strictly for your own use in evaluating your solution.

In each of the provided bag files, the robots stays within the floor described in the associated world file; the robot never goes “out of bounds”.

Required outputs

You should construct a ROS system that publishes these outputs:

On the topic
/floor
, a message of type
nav_msgs/msg/OccupancyGrid
correctly showing the map expressed in the given world file. You can check whether the map message is formed properly or not by visualizing it in rviz. This should be published every five seconds.
On the topic
/estimated_pose
, a message of type
geometry_msgs/msg/Pose2D
providing your algorithm's best estimate of the robot's current pose. Your program should publish its single best estimate of the robot's pose accounting for all of the available information, even if that information is insufficient to be particularly sure of the correct state. This should be published every two seconds.

You should make good choices about the architecture of your system — for example, possible division into multiple nodes, use of launch files, use of parameters, etc. — but (unlike, say, Project 3) there are no specific required elements in the architecture of your system apart from the required output topics.

What to submit

Three required parts:

A PDF report including:
1. A concise description of how the system works. This should be a couple of paragraphs, describing your overall approach at a conceptual level. Some questions to consider: What choices did you make in designing the program, and why? What nodes does your system contain, and what role does each one play? What specific constants are part of your method, and how did you select values for those constants?
2. An rviz screenshot demonstrating the correctness of your published occupancy grids by showing
  cave.world
  visualized correctly.
3. A short answer to these questions: Did the results meet your expectations? Why or why not?
The source code for your program(s). This will span at least one source code file. Be sure to consult the source code style guide on the course Canvas page.
Rosbag recordings of all topics throughout the entire execution of your program for each of the provided input bags numbered 11 through 20. The directory of each bag file must be named with your TAMU netid. followed by a dash, followed by the number of the input bag file. For example, your instructor's submission would include bag directories called
jokane-11
,
jokane-12
, and so on. Incorrectly named bags cannot be graded.

One optional part:

A short video demonstrating your system in some way that may be helpful in grading.