Let's start this section with an example. Let's assume there's a restaurant that uses robots as its waiters to help serve food to customers. Let's say that once the customer has taken their seat, they call the waiter by pressing a simple button on their table. The waiter robot understands the call and navigates to the table, takes the order from the customer, goes to the kitchen to place the order to the chef, and delivers the food to the customer once food is ready. Here, the robot tasks are to navigate to the customer's place, take the order, go to the kitchen, and bring food back to the customer. 

A typical approach would be to define a script with multiple functions for individual tasks, put them together through a series of condition or case statements, and run the application. Well, the application might work as expected sometimes, but might not be the same always. Looking at some practical constraints, what if the robot was obstructed by a few people on its course, and what if the robot's battery goes down and so the robot either doesn't deliver the food or take the order on time and the customer leaves the restaurant in dismay? These robot behaviors can't always be achieved with scripts due to redundancy and the complexity of coding but can be sorted out by using state machines.

Considering the preceding waiter robot example, after taking the order from the customer, the robot would need to navigate to various locations. While navigating, the robot navigation may be disturbed by people walking around. Initially, the obstacle avoidance algorithm may help the robot avoid people, but over a certain period of time, there are chances that the robot still might not have reached the goal. This might possibly be due to cases where the robot is stuck in a loop trying to avoid people. In this case, the robot is asked to traverse to the goal without any feedback mechanism, because of which it got stuck in a loop trying to reach the destination. This is time-consuming and the food might not be delivered to the customer on time. To avoid such situations, we can use an ROS concept called actions (http://wiki.ros.org/actionlib). ROS actions are a type of ROS implementation for achieving time-consuming or goal-oriented behavior. They're more flexible and powerful to use with complex systems with just a little more effort. We'll look at how they work in the upcoming sections.