Lab 3: Finite State Machines and Sensing

This lab will cover Finite State Machines to manipulate the robot using the bumper sensors on the iRobot.

Introduction

In this lab we will continue to build upon autonomous navigation. In the previous lab you managed to get the iRobot moving in a certain path using loops. Now we will make the robot’s motion more robust and responsive to sensory data. The goal of this lab is to use the robot’s bumper sensors to navigate a maze (or follow a wall).

Finite State Machines

A Finite State Machine (FSM) is a model to design computer programs. Most of robots use FSM to complete certain tasks. In this lab, you will be using the iRobot’s bumper sensors to define certain actions when the bumper sensors are triggered.

One problem with loops that can be solved with finite state machines is being able to look at sensory data at the same time. When the program is in a loop, only that loop is being executed. In a finite state machine, when we are transitioning to the next state, the sensory data has a chance to update. This comes in useful for actions that we want to repeat until we tell it to stop, unlike previous examples of loops you have seen where the loop runs only for a certain amount of time.

An interesting application of finite state machines is having a robot navigate through a maze.

One simple (but not very efficient) solution of any maze is the ‘right hand rule’, where the person navigating the maze always keeps their right hand on the wall no matter where they move. By doing so, the exit will definitely be found (eventually). While this right hand rule is easy to describe for a person, how would a robot keep their right ‘hand’ on the right wall?

Your robot is equipped with several sensors, which you have explored in the previous lab. In this one, we will be focusing on the front left and front right cliff sensors and using them to help guide our robot around the maze. In this lab, the walls of the maze are modeled with tape on the floor. Thus, instead of following a line between two sensors, you will have your robot follow a line from one side, thus keeping its ‘hand’ on one wall.

Feel free to explore different ways of keeping the robot’s hand on the wall. We recommend you try having at least three states for this part, one where your robot searches for the wall, and one checks for the wall, and one where it responds to having found the wall.

Preliminaries

Use the instructions from the Getting Started lab in order to connect to the create base and launch the iRobot drivers. The teleop keyboard will not be needed

Examining the Sensor Messages

The ROS driver for the iRobot Create is publishing a stream of sensor data whenever its connected to the robot.To start, we’ll use ROS’s command-line tools in order to see the data stream that ROS is providing. These “data streams” we’ve been using are known as topics in ROS terminology.

• At your Terminal run rostopic to see all the different ROS provided commands related to topics.

    $ rostopic
  

• In particular, run rostopic list to see all the topics available at the momment. Which are the ones you are interested in.

    $ rostopic list
  

• If you do not see the topic mobile_base/sensors/core, try reconnecting your iRobot following the lab 1 commands.

• To print the data flowing through Terminal, we will be using echo command.

    $ rostopic echo mobile_base/sensors/core
  

• Try echoing the sensor messages and gently tap the bumpers of your iRobot. This should trigger different sensor messages on your Terminal.

• The bumper sensors can be found under the robot. It is labeled as “Contact Points for Home Base”.

Sensor Subscribers

ROS’s fundamental capability includes easy communication among distinct programs. Previously, we went over the communication using publisher. This lab will introduce to a different way of communication called subscriber.

• If a program wants access to a streaming data, it uses subscriber to access them

The subscriber, like the word indicates, subscribes to a message to access the data. In this lab, we require the bumper sensor data. So previously, we saw the ROS topics through your Terminal, but those data printed on the Terminal is not necessary being used in the program. So in order to access the data, we use the subscriber in our codes to listen to the topics. The example of how subscribers are used is present on the skeleton code that is provided for you.

Getting Started

Download the started code into your src directoru of your workspace. From the root of your directory run catkin_make. The example code includes few functions that will help you make up your FSM. These functions should include:

• state_start

• state_forward

• state_backward

• state_bumper_triggered

Read over the functions and determine the relationship among the states. The transition between the states are triggered by external events, such as elapsed time or a sensor trigger.

Wall following with FSM

Let’s get moving! Use the functions above to determine the states needed for your state machine. Change the code in the goRobotGo function in RoboState.cpp so the robot can follow the walls of the lab.