The Model

Overview

Up to now, when you wanted the robot to drive somewhere, you guessed at a tick count and tested until it looked right. That works, but it’s slow — and the ticks mean nothing to a human. Today you’ll teach your robot something powerful: the relationship between ticks and inches. Once it knows that, you can tell it to drive “12 inches” and it will predict the right number of ticks on its own. You’re building a model — and that’s one of the most important ideas in all of robotics and AI.

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

• Use division to build a number with a decimal part, and understand why that precision matters.
• Explain what ticks_per_inch is and why it’s a model.
• Build a calibration function that measures your robot’s ticks_per_inch.
• Write a Drive(inches) function that predicts ticks from inches, converting the result deliberately.

Phase 1 — New Tool: Division Keeps Its Decimal

print(250 / 6)    # The decimal is kept: 41.666666666666664.

print(type(250))          # <class 'int'>
print(type(250 / 6))      # Division produced a float: <class 'float'>.

print(int(41.7))     # This prints 41 by removing everything after the decimal point.
print(round(41.7))   # This prints 42 by rounding to the NEAREST whole number.

Why would using int() to convert every predicted tick count introduce a small, consistent error in one direction? Use the 41.7 example.

Phase 2 — Concept: A Model Is a Relationship

ticks_per_inch = ____   # the MODEL: ticks in a single inch

ticks = inches * ticks_per_inch   # predict ticks for ANY distance

In your own words, what does ticks_per_inch let the robot do that a plain tick count never could?

Phase 3 — Build: The Calibration Function

To find your robot’s ticks_per_inch, you let the robot measure itself. Set the robot against the back wall of the right starting box, with the black line ahead of it. The robot drives straight forward until its Tophat sensor reaches the black line, counting ticks the whole way. You measure the real distance it traveled, in inches, and the function does the division.

#!/usr/bin/python3

# Unit 4, Big Idea 1: The Model

# Name: _______________________   Date: ___________

import os, sys
sys.path.append("/usr/lib")
import _kipr as k

MIDPOINT = ____       # your Tophat threshold from before
ticks_per_inch = 0    # Calibration will set this model value.

def main():
    global ticks_per_inch
    # robot starts against the back wall of the right starting box
    calibrate_ticks_per_inch(____)   # pass in YOUR measured inches to the line
    print(f"ticks_per_inch = {ticks_per_inch}")  # see your model

def calibrate_ticks_per_inch(inches):
    global ticks_per_inch
    k.cmpc(0)                            # clear the tick counter
    while k.analog(0) < MIDPOINT:         # drive while sensor sees WHITE (low)...
        k.motor(0, 50)                   # ...straight forward...
        k.motor(3, 50)
                                          # ...stops when it hits BLACK (high)
    k.motor(0, 0); k.motor(3, 0); k.msleep(50)   # brake

    ticks_per_inch = k.gmpc(0) / inches      # MODEL = ticks measured / inches known

main()

Remember your convention: black reads higher than white, so k.analog(0) < MIDPOINT is true on white and the robot keeps driving — then stops the instant it crosses onto black.

Record Your Calibration

Phase 4 — Build: The Drive Function

Now the payoff. With ticks_per_inch known, Drive takes a distance in inches, predicts the ticks, and drives. You command in human units; the model handles the rest. Notice the predicted ticks come out as a decimal — Drive has to deliberately convert that before it can count against it.

def Drive(inches):
    ticks = round(inches * ticks_per_inch)   # PREDICT ticks from the model, then round to a whole tick
    k.cmpc(0)                                # clear the counter
    while k.gmpc(0) < ticks:                  # drive until we reach the predicted ticks
        k.motor(0, 50)
        k.motor(3, 50)
    k.motor(0, 0); k.motor(3, 0); k.msleep(50)   # brake

Test it: after calibrating, call Drive(12.0) and measure how far the robot actually went. Then try a few more distances.

How close was the actual distance to what you asked for? If it was off, what might make the prediction imperfect?

Phase 5 — A Model Can Go Stale

Your robot was driving perfectly last week, but today it always stops a little short. Nothing in your code changed. What probably happened, and what should you do?

Phase 6 — Add to Library & Connect

Add ticks_per_inch, calibrate_ticks_per_inch, and Drive to your library, fully commented. From now on you can drive in inches in any mission.

You just built a model and used it to predict. This is everywhere in intelligent systems: a weather model predicts tomorrow’s temperature; a self-driving car models how far it travels at a given speed; an AI predicts the next word from patterns it measured. And like your ticks_per_inch, real models must be recalibrated when the world changes — a model trained on old data slowly stops matching reality. Measuring a relationship, using it to predict, and refreshing it when conditions shift is the heartbeat of how machines reason about the world.

Read each scenario. Think it through, then write your answer.

A plain tick count only works for one exact distance. Why is a model like ticks_per_inch more powerful than memorizing tick counts for each distance?

Real AI models also go stale and need retraining when the world changes. How is that like recalibrating your ticks_per_inch?

Phase 7 — Individual Reflection

Complete this section on your own.

1. Why does dividing with / keep the decimal automatically, but converting a decimal back to a whole tick count take a deliberate choice? Why did Drive use round() instead of int()?

2. Explain how the calibration function builds the ticks_per_inch model.

3. How does Drive use the model to predict ticks from inches?

4. Complete in 2–3 sentences: “Intelligent systems use models to predict what should happen next. This means a robot can plan its actions by…”

Extension Challenges

Finished early? Try one or more of these.

Extension A — Calibrate Twice

• Run your calibration two or three times and compare the ticks_per_inch values. Are they identical? What does the spread tell you about measurement?

Extension B — Low Battery Test

• If you can, calibrate with a full battery and again with a lower one. Did ticks_per_inch change? By how much?

Extension C — A Turn Model

• Your turns still use raw ticks. Could you build a ticks_per_degree model the same way, so you could call Turn(90.0)? Sketch how you’d measure it.

Extension D — Rewrite a Mission in Inches

• Take your double-stack mission and replace the raw Tick_Drive calls with Drive in inches. Is the mission easier to read and plan now? Why?

Extension E — The Same Idea, Somewhere Else

• The calibration idea you built today — measure once, build a numeric model from that measurement, then reuse the model going forward — isn’t unique to robots.
• Name two other fields (cooking, medicine dosing, engineering, sports, anything) where that same idea would apply, and explain one of them in 2-3 sentences.

Extension F — Average Your Calibration

• You calibrated 2-3 times in Extension A and got slightly different ticks_per_inch values each time. Write a few lines of code that take those readings and compute their average (sum divided by count) instead of eyeballing which one to use.
• Use that averaged value as your real ticks_per_inch going forward. Does it change your accuracy on a test drive?

Extension G — Type In a Test Value

• This extension requires running the program manually via SSH or the terminal. While testing (not during a competition run), use input() to read a number typed by a teammate instead of hard-coding it. input() always gives you back text, even if someone types a number — wrap it in float() to turn that text into an actual decimal number you can do math with.

distance = float(input("Enter a distance to drive (inches): "))
Drive(distance)

• Try it for a couple of different distances. Why is typing in a test value faster for testing than editing your code and re-running it each time?