Chapter 01

Meet the robot, then build its mathematical language

Begin with real mechanisms and measurements, then introduce only the mathematical ideas needed to describe a robot's body, possible shapes, locations, directions, and simple coordinate operations.

Before you start

Count whole numbers and use the four basic arithmetic operations.
Measure a short distance with a ruler.
Draw on squared paper; no algebra, linear algebra, or robotics experience is assumed.

By the end

Trace a complete sense–decide–act–observe loop and name the physical responsibility of each part.
Identify links and common joints, then count independent degrees of freedom without confusing them with motors.
Keep configuration space, workspace, joint limits, and topology separate.
Use signed coordinates and SI units to record physical measurements without ambiguity.
Draw and calculate 2D vectors, including addition, subtraction, norm, and dot product.
Describe one physical point in named coordinate frames and detect a handedness or frame mismatch.
Apply small 2×2 matrices one row at a time and explain the physical action represented by each matrix.

The field story

The Parcel-Sorting Desk Robot

A small parcel station has one awkward problem: boxes reach the end of a desk, but the cardboard sorting arm cannot yet describe what it senses or how it may move. You have been asked to turn that mute mechanism into an inspectable robot on paper. The station manager does not want equations pasted over uncertainty. She wants a causal map showing which part observes the parcel, which part decides, which joint permits motion, and which measurement proves that the arm actually changed the parcel’s route.

Across this chapter, the Parcel-Sorting Desk Robot gains its language one physical need at a time. A ruler gives positions and units, arrows describe intended movement, attached maps prevent frame confusion, and small number grids describe repeatable actions. Each day revisits the same arm and parcel instead of starting an unrelated puzzle. By the finish, another engineer should be able to inspect the drawings, reproduce the arithmetic, deliberately introduce a sign or handedness fault, and explain exactly why the wrong parcel lane would be selected.

Why this chapter now: Every later controller, transform, planner, and model assumes that physical parts, quantities, directions, units, and frames already have unambiguous meanings.
Ignore for now: Ignore calculus, 3D motion, motor wiring, ROS 2, and powered hardware. This chapter needs only safe household mechanisms, paper, measurement, and small arithmetic.
This unlocks: A reliable vocabulary for transforms, forward kinematics, feedback, robot descriptions, sensor messages, and every later evidence report.
Proof you will leave with: Save the annotated robot loop, joint and configuration sheet, measured coordinate grid, vector calculations, frame drawing, matrix table, starter output, and one planted-failure explanation.

Environment contractPaper, ruler, squared paper, a modern browser, and the repository-supported Node.js 22.13.0 or newer. No ROS 2, simulator, network service, or powered mechanism is required.

Compatibility boundary: The paper work is platform-independent. Run the starter with the repository Node.js baseline; other JavaScript runtimes are outside this chapter’s checked path.
Smoke check: Run node --version, confirm it is at least 22.13.0, save the starter as week-01-parcel-sorter.mjs, and run node week-01-parcel-sorter.mjs.
Contract reviewed: 2026-07-25
Runtime evidence: The dependency-free starter is executed by repository tests on the supported Node.js baseline. Chapter-specific ROS 2, Gazebo, model, dataset, checkpoint, and hardware environments are learner-created unless the repository supplies an explicit asset; run the smoke check and preserve its versions and output before claiming runtime compatibility.
Drift risk: low

Today in the field story

One problem, then the next

The Parcel-Sorting Desk Robot begins as a silent cardboard body beside an incoming box. Trace the parcel reflection into the distance sensor, the reading into a threshold decision, the decision into a motor request, and the wheel or arm motion back into a fresh observation. This opening establishes the causal spine that every later drawing and calculation must serve.

Why now: The project needs a complete physical loop before it needs mathematical notation.
Ignore today: Do not choose motors, write control code, or claim that a sent command moved anything.
Unlocks next: A responsibility map for diagnosing missing data, missing power, missing motion, or missing feedback.

Understand

Build the physical picture first

A robot is a physical loop, not a magic box: information travels inward from sensors, a decision becomes a command, and an actuator pushes the real world.

Start with the body. A small rover may have a chassis, wheels, motors, a battery, a distance sensor, and a computer board. The sensor converts a physical condition—such as reflected light or wheel rotation—into data. Software on the controller reads that data and chooses a command. An actuator converts electrical energy into force or torque. The links and wheels carry that effort into visible motion. This sense–decide–act picture is a useful engineering model, although not every machine is autonomous and not every robot has every part arranged in one box.

Information and energy are different flows. A sensor signal can tell the controller that a wall is 18 cm away, but that signal cannot turn a wheel. The battery and motor driver supply energy to the motor; the controller supplies only the command describing what should happen. Keeping those flows separate makes wiring diagrams, software interfaces, and fault diagnosis clearer. If the controller sends a valid command but the battery is disconnected, the information path worked while the energy path failed.

Acting once does not automatically create feedback. A timer can run a motor for one second without checking where the rover ended; that is open-loop action. A feedback loop measures the result, compares it with the desired result, and chooses the next command. The return measurement might come from a wheel encoder, camera, or limit switch. For now, learn to ask four questions: what was sensed, what decision was made, what physically acted, and what measurement confirmed the result?

Robotics software crosses a boundary that ordinary screen software often does not: a bad output can move mass. A safe diagram therefore includes command limits, a way to stop, and an observed result. Your first notebook entry should show both the normal loop and one missing-part failure. That habit—drawing the whole causal path before coding—is the beginning of production robotics engineering.

Words you need

Name each idea precisely

Sensor: A device that turns a physical condition into data the controller can read.
Physical example:
A distance sensor reports an estimate of how far a box is from the rover.
Controller: The computing part that reads inputs and selects commands according to software.
Physical example:
A microcontroller compares measured distance with a 20 cm stop threshold.
Actuator: A device that converts supplied energy into physical effort or motion.
Physical example:
A DC motor produces wheel torque when its driver supplies current.
Link: A body part treated as rigid so its shape does not change during the motion being studied.
Physical example:
The solid strip between two hinges in a cardboard arm is one link.
Feedback: A new measurement of the result that is used to decide the next command.
Physical example:
An encoder reports that the wheel turned less than requested, so the controller adjusts.

Visual model

See the relationship

Swipe the technical canvas horizontally on a small screen.

Day 1 · Concept — The robot senses, decides, acts, and observes the result. Measured anchor: 3 roles connected.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalStart at zero: counting, units, and coordinates

No maths is assumed. First give every robot number a physical meaning, a unit, a zero point, and a positive direction.

N: a count, such as number of jointsUnit: no unit
x: one position measured from a chosen zeroUnit: centimetres (cm) or metres (m)
Δx: change in x; Δ means changeUnit: same unit as x

Draw a number line. Put the origin at 0 cm, choose right as positive, and place the robot at x = 20 cm.
Move 30 cm right, so Δx = +30 cm. Predict x_new = 20 cm + 30 cm = 50 cm.
Measure to check, then convert with 100 cm = 1 m: 50 cm = 0.50 m. Never add centimetres directly to metres.

Programmer analogy

A variable is like a named field in code, but a robot field must also say its physical unit and what zero means.

A robot starts at x = 40 cm and moves 15 cm left. What is its new x coordinate?

Left is negative, so Δx = -15 cm and x_new = 40 - 15 = 25 cm.

For this first lesson, mathematics means careful counting:

N_{\text{parts}}=N_{\text{sensors}}+N_{\text{actuators}}+N_{\text{controllers}}+N_{\text{body parts}}.

Here $N$ means “number of.” A count has no physical unit.

Trace a rover stopping before a wall

A rover should stop at 20 cm. Its sensor reports 18 cm while both wheels are moving forward.

Name the sensed quantity: distance to wall = 18 cm.
Name the rule: if distance is less than or equal to 20 cm, request zero wheel speed.
Write the controller output: left command = 0 and right command = 0.
Follow the energy path: the motor drivers remove drive effort and the wheels slow.
Measure again with the sensor or wheel encoders to confirm that motion actually stopped.

Result

The loop is complete only after the stopped state is observed; sending two zero commands is not physical proof.

What this proves

A command is an intention. Feedback provides evidence about what the body really did.

Physical examples

Where this appears in real life

Automatic sliding door

A presence sensor detects a person, a controller checks the door state, and a motor opens the panels.

Look for:

Identify the closing safety sensor and explain why the motor command alone is not proof that the doorway is clear.

Two-wheel desk rover

A front distance sensor reports a nearby book; the controller stops one wheel and runs the other to turn away.

Look for:

Separate the distance reading, software decision, motor-driver command, battery power, wheel motion, and follow-up reading.

Hands-on exercise

Make the idea observable

Use paper, a toy vehicle or drawn rover, and a pen. Do not power a motor for this exercise.

Draw the environment, sensor, controller, motor driver, motor, wheel, and power source as separate labelled blocks.
Use one arrow style for information and a different style for electrical or mechanical energy.
Add the rule “stop at 20 cm” inside the controller block.
Add a return arrow that measures the changed world after the wheel command.
Cross out one block at a time and write the visible symptom caused by its absence.

Observe

Different missing parts produce different evidence: no data, no decision, no effort, no power, or unverified motion.

Done when

Another person can follow the two flows and correctly diagnose at least three removed-part failures from your drawing.

Build today

Build a paper two-link robot and a browser notebook that shows its parts, allowed motion, coordinates, vectors, frames, and matrices.

Evidence to save

DONE when the learning log explains “Robot anatomy: sense, think, act, links, and actuators” in five precise points and a checked example produces the predicted output.

Common mistakes

Catch the wrong mental model

Wrong

Calling every electronic board a sensor.

Better

Name what physical quantity the device measures; a controller board that only computes is not itself that measurement.

Wrong

Treating “command sent” as “motion happened.”

Better

Measure the physical result with an independent sensor or state signal.

Wrong

Drawing signal arrows but omitting power and mechanical motion.

Better

Show information, electrical energy, and physical action as distinct paths.

Job connection

How this becomes employable evidence

Build an operator screen and validation trace that distinguish requested velocity, driver acknowledgment, measured wheel velocity, stale sensor data, and stopped state.

Relevant target roles

Robot HMI / Control & Monitoring Engineer
Robotics Deployment, Integration & Validation Engineer
Robotics Application / ROS 2 Integration Engineer

Chapter 01 interview drill

Interview questions: Robot anatomy: sense, think, act, links, and actuators

Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.

Primary interview scenario

A UI says “stop sent,” but the robot keeps rolling. Walk through the information path, energy path, and measurements you would inspect before naming a cause.

Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.

Technical follow-up questions

Q1Why is a motor an actuator rather than a controller?

Model interview answer

It converts electrical energy into physical torque; the controller chooses the command sent to it.

Q2What is missing if a timed motor command never measures its result?

Model interview answer

Feedback is missing, so it is open-loop action even if the command is generated by software.

Q3What evidence is stronger than a log line saying “stop sent”?

Model interview answer

A fresh measured wheel speed or other independent physical-state signal showing that motion reached the stopped condition.

Chapter references

Modern Robotics — degrees of freedom of a rigid bodyDefinitions of links, configurations, configuration space, and degrees of freedom.
Modern Robotics — degrees of freedom of a robotCommon joint freedoms, motion constraints, and the warning that simple DOF counts need independent constraints.
Modern Robotics — configuration-space topologyWhy rotational coordinates wrap around and why an unrestricted planar two-revolute-joint arm has torus topology.
NIST — SI unitsAuthoritative SI unit names, symbols, and the distinction between base and derived units.
OpenStax Precalculus — vectorsGeometric vectors, components, magnitude, addition, subtraction, and dot product.