Planning an Autonomous Mission

Autonomous vs remote-controlled

There are two ways a robot can do a job. When it is remote-controlled, a person steers it in real time, deciding every move. When it is autonomous, the robot runs its own program and uses its sensors to decide for itself, with no one steering.

This week is about autonomous missions, because next week you will build a robot that has to do its job by itself. That means all the deciding has to be planned ahead of time and written into the program.

For example: Autonomous: a robot vacuum, a Mars rover doing a planned drive, a delivery robot on a sidewalk; Remote-controlled: an RC car, a camera drone on a joystick, a rescue robot a person drives by video

Requirements, constraints, and criteria

Before you build, you plan. A requirement is what the robot MUST do - 'carry the block to the blue zone'. A constraint is a limit you have to work inside - 'in under 30 seconds', 'using only one sensor', 'no bigger than a shoebox'. Criteria are how you will judge success - 'stops inside the zone' and 'never bumps the wall'.

Writing these down first keeps a plan honest. If you can't tell whether the robot did the job, your criteria aren't clear enough yet.

For example: Requirement: 'find the target and stop'; Constraint: 'finish in under one minute'; Criteria: 'stops within 5 cm of the target'

Trade-offs and the engineering design process

You almost never get everything at once. A trade-off is giving up some of one thing to get more of another. A robot that drives fast might miss the sensor reading and crash; slowing it down trades speed for reliability. There is rarely one 'right' answer - you choose the trade-off that best fits your requirements and constraints.

Engineers handle this with the engineering design process: plan, build, test, improve - then go around again. Each trip around is an iteration. You also think about efficiency: doing the job with fewer steps, less time, or less energy, without breaking your criteria.

For example: Fast vs reliable; Simple program vs handling more obstacles; Fewer steps (efficient) vs more careful checks

Flowcharts: mapping the program before you code it

A flowchart is a picture of your program's steps. Actions go in rectangles ('drive forward', 'stop'). Decisions go in diamonds and ask a yes/no question ('Wall ahead?'), with one arrow out for 'yes' and one for 'no'. Arrows connect the boxes so you can follow the path the robot will take.

Drawing the flowchart first lets you find problems before you build. A good autonomous flowchart always includes a loop that keeps checking a sensor and a clear ending - which is where your safe stop goes.

For example: Rectangle = action; Diamond = a yes/no decision; Arrows = the order of steps

Safe stopping and responsible robotics

An autonomous robot decides on its own, so it needs a way to stop safely - a programmed behavior that halts it when the job is done or when something (or someone) is in the way. Without a safe stop, an autonomous robot can keep driving into a wall or a person.

This is part of responsible robotics: thinking about safety and about when a human should stay in control. Autonomous robots are great at dull, repeating jobs, but for anything risky - near people, or where a mistake could hurt someone - a person should be able to supervise, take over, or shut it down.

Responsible designers also think about privacy - a robot with a camera or microphone collects information about people, so you only collect what the job truly needs. They plan for failure: if a system breaks, who is responsible, and does it fail safely by stopping rather than charging ahead? And they decide which jobs a robot should only assist a person with instead of controlling alone - a robot might hand a nurse a tool, but a person makes the medical decision.

Finally, good robots are designed for different users and needs - the people who use them may be young or old, may not read the same language, or may need larger buttons, sound, or lights. Designing for real, varied users is part of doing robotics responsibly.

For example: Robot vacuum stops and backs up at a stair edge; A delivery robot pauses when a person steps in front; A person keeps a hand near the stop button during testing; A home robot only records what it needs and asks before it does; An alert uses both a light and a sound so more people can notice it

Autonomous robots in the real world

Autonomous robots already do real jobs - almost always dull, dirty, or dangerous ones, and almost always with people supervising. Looking at real examples helps you plan your own mission: each one senses the world, decides with a program, acts, and has a way to stop safely.

As you read these, notice the pattern from Week 1: input (a sensor), processing (a decision), output (an action) - plus a safe stop and a human who can step in.

For example: Warehouse delivery robots carry shelves to workers, sensing other robots to avoid bumping; Mars rovers drive planned routes on their own because commands from Earth take minutes to arrive; Agricultural robots roll down crop rows to check plants or pull weeds; Search-and-rescue robots enter rubble or smoke that is too dangerous for people; Underwater inspection robots check pipes, hulls, and cables where a diver cannot safely go; Factory robotic arms weld and assemble the same part precisely, over and over, behind a safety guard; Robotic surgical tools let a surgeon work with steadier, smaller movements - the surgeon stays in control the whole time

Practice mission vs its criteria

Run the guided practice mission from the same start each time. For each run, record what happened and check it against the success criteria in your brief.

Measure: Whether each success criterion was met, and what to change for the final project