Deciding What to Do

Try It — Sabotage Your Own Robot

Load your Project 12 program — the blue pom run. Before you press start, move the first pom about four inches to one side.

Now run it and watch closely.

Something goes slightly wrong in a real match — a cube got bumped, your robot drifted an inch. How much of your run is ruined?

You do this all day

You never follow a plan blindly. You check things and pick.

Fill in what you would do:

Learn It — Ask Once, Then Choose

An if statement asks a question and only runs its block when the answer is true.

if (digital(bump) == 1)
{
	printf("I am touching something!\n");
}

The condition in the parentheses is written exactly the same way as a while condition — same symbols, same rules, same == trap.

The one difference that matters

while — Keeps asking

while (digital(bump) == 0)
{
	motor(left, 50);
	motor(right, 50);
}

Checks, runs the block, checks again, runs again… until the answer changes.

if — Asks once

if (digital(bump) == 0)
{
	motor(left, 50);
	motor(right, 50);
}

Checks once. Runs the block once if true, skips it if false. Either way the robot moves on immediately.

Multiple checks

Two separate if statements

if (shoes are on)
{
    go for a walk;
}

if (I am hungry)
{
    eat a snack;
}

Two questions about different things. Both can be true. Both can be false. They do not affect each other.

if / else

if (shoes are on)
{
    go for a walk;
}
else
{
    watch TV;
}

Exactly one of these always runs. else has no condition — it means “every other possibility.”

if / else if / else

if (shoes are on)
{
    go for a walk;
}
else if (shoes are by door)
{
    put them on;
}
else
{
    watch TV;
}

Checked top to bottom. The first true one runs and the rest are skipped, even if they are also true.

A decision inside a decision

You can put an if inside another if. This is called nesting.

// Did I grab something?
if (digital(claw_switch) == 1)
{
	// Am I far enough along?
	if (gmpc(left) > 3000)
	{
		release();
	}
	else
	{
		drive_forward(1000);
		release();
	}
}
else
{
	printf("Grab failed - trying again\n");
	grab();
}

Nesting more than two deep gets hard to read fast. If you need three, that is usually a sign the code wants to be a function.

Do It — Make It Choose

Step 1 — Your first decision

Create a new project called Choices. Write a program that checks the touch sensor once and prints a different message either way.

if (digital(bump) == 1)
{
	printf("Something is there\n");
}
else
{
	printf("Nothing there\n");
}
msleep(3000);

Run it twice — once holding the sensor pressed, once not.

• I get a different message depending on the sensor

Step 2 — Swap if for while and watch what breaks

Change your if to a while. Leave everything else alone. Run it without TOUCHING the sensor.

What happened?

Change it back. You have just seen the difference from the inside.

Step 3 — Pick a side with a button

Real teams run one program from either starting box. The driver presses a button to say which side.

printf("Press A for left box, B for right\n");

while (a_button() == 0 && b_button() == 0)
{
	// Wait for either button
	msleep(10);
}

if (a_button() == 1)
{
	run_left_plan();
}
else
{
	run_right_plan();
}

The && means “and” — keep waiting while neither button is pressed. You do not need to master it today; copy the pattern and it works.

• One program runs from either starting box

Step 4 — Did I actually grab it?

This is the fix for what you saw in Try It. Put a touch sensor where a held cube presses it, or check whether the claw closed further than it should have.

grab();

if (digital(claw_switch) == 1)
{
	printf("Got it\n");
	carry_to_basket();
}
else
{
	printf("Missed - backing up to retry\n");
	drive_backward(300);
	grab();
}

Now sabotage it again — move the pom aside like you did in Try It.

What did the robot do differently this time?

• My robot notices a failed grab and does something about it

Step 5 — A three-way choice

Use else if to pick between three actions based on how far along the robot is.

if (gmpc(left) < 1000)
{
	printf("Barely started\n");
}
else if (gmpc(left) < 3000)
{
	printf("About halfway\n");
}
else
{
	printf("Nearly there\n");
}

Swap the first two conditions around and run it again. What goes wrong, and why?

Step 6 — Mission 3 Advanced — two opposite stacks for 13 points

Where the decisions go. This run has four grabs and four placements in a row. If grab two fails and the robot does not notice, everything after it is wasted. Put a check after each grab — the pattern from step 4 — so a miss costs you one cube instead of the whole mission.

• I have two mixed-colour stacks
• The two stacks are arranged opposite ways round
• No cube is shared between the two stacks

Step 7 — Run it five times

Score It — Checkpoint

My score

if or while?

For each one, say which you would use and why.

Spot the bug

Can you do it again?

• I can write an if statement with a condition and a block
• I can explain the difference between if and while
• I know that else takes no condition of its own
• I can write an else if chain and put the conditions in a sensible order
• I can nest one decision inside another
• I check whether a grab worked instead of assuming it did
• I can write one program that runs from either starting box

Think about it

In Try It your robot carried nothing across the field and placed it carefully in a basket. Would you call that a mistake by the robot, or a mistake by the programmer?

A robot that checks its own work looks smarter than one that does not. Is it actually smarter, or is it something else?

Every decision you made today came from a switch — pressed or not pressed. What kinds of choices could your robot make if it could tell how much of something there is, instead of just yes or no?

Next

Everything your robot senses right now is on or off. The field is not like that — a black line and a white mat are not two states of a switch, they are two brightnesses.

In Project 14 — Seeing Light and Dark, your robot gets a sensor that answers with a number instead of a yes.

KIPR · Botball Explorer — Discovery Projects · © KISS Institute for Practical Robotics 1997–2026