Design an Autonomous Behavior
Engineering a robot behavior is not just writing code — it is a design process. You must understand the environment, identify what the robot needs to perceive, define the decisions it must make, choose what actions it will take, and think ahead about what could go wrong. This lesson puts you in the role of the robotics engineer. You will design a complete autonomous behavior from scratch, applying the concepts from this entire module.
The Design Challenge
Good autonomous behavior design starts with a clear goal statement and a thorough analysis of the environment. What does success look like? What are the constraints — physical limits, safety requirements, time deadlines? What can the robot sense, and how reliable are those sensors? What actuators does it have, and what are their limits? Answering these questions before writing a single line of logic prevents a mountain of problems later.
When writing a behavior specification, describe what the robot should achieve and under what conditions — not yet how it will do it. For example: 'The robot shall locate every chair in the room and move each one to the wall, without tipping any chair or colliding with any person, within five minutes.' This gives the design space clarity without prematurely locking in implementation decisions.
Mapping the Perceive-Plan-Act Loop for Your Behavior
Once the task is defined, break it into perceive-plan-act cycles. What does the robot need to sense at each stage? What decision does it make based on that sensor data? What action does it take? Draw this as a flowchart or table. Identify the points where uncertainty is highest and decide how the robot should handle it — ask for help, slow down, use multiple sensors, or make a conservative choice. Also identify the error states: what faults could occur, and what recovery behaviors should activate? A well-designed behavior does not just handle the happy path — it plans explicitly for the most likely failure modes.
Design a Full Autonomous Behavior
- THE SCENARIO: You are designing the autonomous behavior for a service robot in a public library. The robot's job is to collect books that have been left on tables by patrons and return them to the correct shelf section (Fiction, Non-Fiction, Reference) based on a barcode scanner on the robot's gripper arm.
- STEP 1 — ENVIRONMENT ANALYSIS (5 minutes)
- List the objects and people the robot must detect and how it will sense each one. Include: books on tables, people in the library, the shelving sections, obstacles like chairs and bags.
- STEP 2 — PERCEIVE-PLAN-ACT BREAKDOWN (10 minutes)
- For each of the four main subtasks below, write one Perceive action, one Plan decision, and one Act command:
- (a) Finding a book on a table
- (b) Scanning the book's barcode to identify its section
- (c) Navigating to the correct shelf section without hitting anyone
- (d) Placing the book on the shelf
- STEP 3 — UNCERTAINTY AND FAILURE PLANNING (5 minutes)
- Identify two sources of uncertainty and two possible faults. For each fault, write a recovery behavior.
- STEP 4 — AUTONOMY LEVEL (2 minutes)
- Decide: what level of autonomy (teleoperation, supervised, or full) is appropriate for this robot operating around children and elderly patrons? Justify your answer in two sentences.
- STEP 5 — PRESENT AND CRITIQUE (class activity)
- Present your behavior design to another group. The other group asks: 'What happens if...' questions to probe edge cases. Update your design based on the critique.
- BONUS: Sketch the robot's decision flowchart as a diagram showing the Perceive-Plan-Act loop for the complete book-retrieval task.
What Makes a Behavior Design Good?
A strong behavior design is complete (it handles every stage of the task), robust (it plans for the most likely failures), appropriately autonomous (it keeps humans involved where judgment matters), and testable (you can describe exactly what a passing test looks like). When you review your design, ask: could a team of engineers implement this without needing to ask you any clarifying questions? If there are gaps, fill them in now — because in real robotics, ambiguous specifications become bugs.
Many experienced robotics teams spend more time on paper design — flowcharts, state machines, scenario analysis — than on writing code. A problem caught on paper costs ten minutes. The same problem caught after six weeks of implementation costs six weeks. Time invested in thorough design pays enormous dividends.
A student's autonomous library robot design includes: find book, scan barcode, navigate to shelf, place book. The design works perfectly in testing with one patron in the library. Why might it fail when the library is busy with many patrons moving around?
Why is it important to write a behavior specification that describes what the robot should achieve rather than immediately describing how it should achieve it?