Every Second Counts

Overview

Every lab so far has asked “did it work?” Today’s question is different: “did it get better?” You can’t answer that without a number. Today you’ll time a real mission run, store repeated timing results the same way you stored pose data in Big Idea 1, and then write code that actually studies that stored data — finding the best and worst runs, and putting them in order.

By the end of this activity you will be able to:

• Use systime() to measure how long a routine actually took.
• Use the modulo operator (%) to turn a raw time value into something readable.
• Store repeated measurements in an array, and use a boolean variable to track a running yes/no answer inside a loop.
• Write a linear search to find the best and worst value in a data set.
• Write a simple sort, and reason about how its cost changes as the data set grows.

Phase 1 — The Mission: Restack & Shelve

This single stacking action scores three things at once: Mission 12’s Base Mission (two spilled cubes forming a valid stack), and Mission 16’s Base and Bonus Mission (one, then a second, spilled cube ON TOP OF the Large Green Cube) — confirmed directly by the rules’ own scoring examples. One clean action, most of the points on the board for these two missions.

Say the mission back in your own words. Why does stacking the cubes on the Large Green Cube, instead of just on each other, matter for how many points you earn?

Phase 2 — Concept: Measuring and Reading Elapsed Time

unsigned long start = systime();
msleep(5000);   // wait exactly 5 real seconds
unsigned long stop = systime();
printf("Difference: %lu\n", stop - start);

What number did you get, and what does that tell you about the unit systime() counts in?

unsigned long init_time = systime();
// ...the routine you're timing goes here...
unsigned long elapsed = systime() - init_time;

unsigned long total_sec = elapsed / 1000;   // whole seconds (adjust if your unit differs)
unsigned long minutes = total_sec / 60;
unsigned long seconds = total_sec % 60;     // <-- THIS % is the modulo operator (math), not the %lu below (text formatting)
printf("Elapsed: %lu:%02lu\n", minutes, seconds);

If total_sec is 197, what do 197 / 60 and 197 % 60 each give you, and what do those two numbers mean together?

Phase 3 — Build: Time the Restack Run

Wrap your Restack & Shelve routine in the timing pattern from Phase 2, using your own library calls.

int main()
{
	enable_servo(0);
	enable_servo(3);

	unsigned long init_time = systime();

	// ===== the mission itself, using your own library =====
	// Drive(...) / Turn(...) to spilled cube 1, pick it up
	// Drive(...) / Turn(...) to the Large Green Cube, place it
	// Drive(...) / Turn(...) to spilled cube 2, pick it up
	// Drive(...) / Turn(...) back to the Large Green Cube, stack it

	unsigned long elapsed = systime() - init_time;
	unsigned long total_sec = elapsed / 1000;   // use what Phase 2 taught you about the unit
	printf("Elapsed: %lu:%02lu\n", total_sec / 60, total_sec % 60);

	return 0;
}

Why does init_time get captured before the mission code runs, and elapsed get calculated after it finishes — what would go wrong if you calculated elapsed too early?

Phase 4 — Run It 4 Times

Reset the 2 spilled cubes to their starting positions between attempts, and run the full mission 4 separate times. Record each printed elapsed time (in seconds — convert from the MM:SS your program prints).

Phase 5 — Concept: Studying Your Own Data

double times[4] =
{
	t1,
	t2,
	t3,
	t4
};  // your 4 recorded seconds from Phase 4

for (int i = 0; i < 4; i++)
{
	// this block runs once for i=0, once for i=1, once for i=2, once for i=3
}

double fastest = times[0];
double slowest = times[0];
for (int i = 1; i < 4; i++)
{
	if (times[i] < fastest) fastest = times[i];
	if (times[i] > slowest) slowest = times[i];
}

double temp = times[i];        // 1. set the first value aside, so it isn't lost
times[i] = times[i + 1];       // 2. copy the second value into the first spot
times[i + 1] = temp;           // 3. copy the saved-aside value into the second spot

Sorting: the simple version

Picture 4 people standing in a line, out of height order. Walk down the line one time: compare each pair of neighbors, and swap them if the left person is taller than the right person. After one full walk, the tallest person has “bubbled” to the top like bubbles rising through water. Do that same walk a few more times, and eventually everyone’s in order. That “bubbling” to the top gives this algorithm its name: bubble sort.

for (int pass = 0; pass < 3; pass++)          // walk down the line a few times
{
	for (int i = 0; i < 3; i++)                // one full walk, comparing neighbors
	{
		if (times[i] > times[i + 1])           // out of order?
		{
			double temp = times[i];               // swap them (see above)
			times[i] = times[i + 1];
			times[i + 1] = temp;
		}
	}
}

Walk through it by hand with 4 index cards showing your own 4 times, out of order. Do the swaps yourself, pass by pass, until they’re sorted. For only 4 values, 3 passes is always enough to guarantee a full sort — that’s why the outer loop stops at pass < 3.

int swapped = 1;                 // start true, just to make sure the loop runs at least once
while (swapped)
{
	swapped = 0;                 // assume this pass finds nothing to fix...
	for (int i = 0; i < 3; i++)
	{
		if (times[i] > times[i + 1])
		{
			double temp = times[i];
			times[i] = times[i + 1];
			times[i + 1] = temp;
			swapped = 1;          // ...unless a swap actually happened
		}
	}
}

Walk through the simple version by hand on paper first, with your own 4 numbers. Then answer: why does checking swapped let the improved version stop early on data that’s already close to sorted? What’s stored in the variable at the moment it does?

Would the search’s work grow by roughly 25× (matching the 25× growth in data, from 4 to 100)? Would the sort’s worst-case work grow by exactly 25×, or by something faster than that? This — how the amount of work grows as the data grows — is what computer scientists mean by algorithm efficiency.

Phase 6 — Build: Analyze Your Times

Using your 4 recorded values from Phase 4, write the full analysis: hardcode the array, search for fastest/slowest, sort it, and report all of it.

double times[4] =
{
	/* your 4 recorded seconds */
};

// ===== SEARCH =====
double fastest = times[0];
double slowest = times[0];
for (int i = 1; i < 4; i++)
{
	if (times[i] < fastest) fastest = times[i];
	if (times[i] > slowest) slowest = times[i];
}
printf("Fastest: %.2f  Slowest: %.2f\n", fastest, slowest);

// ===== SORT =====
int swapped = 1;
while (swapped)
{
	swapped = 0;
	for (int i = 0; i < 3; i++)
	{
		if (times[i] > times[i + 1])
		{
			double temp = times[i];
			times[i] = times[i + 1];
			times[i + 1] = temp;
			swapped = 1;
		}
	}
}
printf("Sorted: %.2f, %.2f, %.2f, %.2f\n", times[0], times[1], times[2], times[3]);

Once your array is sorted, where do the fastest and slowest values sit in it? Could you have skipped writing a separate search entirely, if you’d sorted first?

Phase 7 — Connect & Reflect

Every real engineering team does exactly what you just did: time something, run it more than once, store the results, and actually look at the numbers instead of trusting a gut feeling. A search engine times how long a query takes across millions of runs. A game studio times level-load times across every playtest. None of them trust a single run — and none of them just eyeball the numbers either; they sort them, find the extremes, and watch how those numbers change as the system scales up.

Complete the reflection on your own.

1. Walk through the init_time / elapsed pattern in your own words — what does each line actually do?

2. What does modulo (%) give you that regular division (/) doesn’t?

3. What was swapped actually tracking, and why does a stored boolean matter here in a way that an inline &&/|| check couldn’t?

4. Complete in 2–3 sentences: “A system that never measures its own performance can’t tell whether a change helped. This means that before I claim my robot got faster, I should…”

Extension Challenges

Finished early? Try one or more of these.

Extension A — Time a Different Metric

• Apply the same array + search + sort pattern to a different measurement — for example, how many degrees off-target your last 4 turns landed. What changes in your code, and what stays exactly the same?

Extension B — Watch the Early Exit

• Add a printf inside the while (swapped) loop that prints the value of swapped at the end of each pass. Run your sort on data that’s already close to sorted — how many passes does it actually take before swapped stays 0?

Extension C — Scaling to 8

• If you had 8 trial times instead of 4, how would you need to change the array declaration and the loop bounds? In the worst case, roughly how many more comparisons would the sort need — twice as many, or more than that?