Chapter 02

Turn the maths into robot motion

Learn to predict where a rigid robot part is, which way it faces, and how joint motion changes the tool position. The goal is not to memorize symbols: it is to build a small set of spatial tools that you can draw, calculate, test, and later recognize inside tf2, RViz, robot models, calibration, and motion software.

Before you start

Read a point or arrow on an x-y grid and keep its unit and coordinate frame attached.
Add vectors component by component and multiply a 2×2 matrix by a 2D vector one row at a time.
Distinguish a robot configuration (joint values) from a workspace point (tool location).

By the end

Rotate and translate a 2D point while stating the order, units, and input/output frames.
Compose and invert a short frame chain and verify it with an identity round trip.
Check whether a 3×3 matrix is a proper rotation and explain why a reflection is not.
Explain Euler-angle singularity and use a normalized quaternion without mixing component order.
Build and apply an SE(3) homogeneous transform to both points and directions.
Calculate two-link forward kinematics and measure model error on a cardboard arm.
Explain a Jacobian column, run bounded numerical inverse kinematics, and report failure honestly.

The field story

The Camera-Crane Recovery

The parcel station adds a tiny camera crane above the sorting desk. During its first rehearsal, the camera points at the correct box but reports the wrong room location, and an operator cannot tell whether the fault came from angle units, transform order, an orientation convention, or the arm model. You inherit the paper arm from Chapter 1 and must rebuild the spatial chain deliberately, starting with a marked point on a tray and ending with a bounded attempt to place the camera over a requested target.

The Camera-Crane Recovery is one investigation, not seven unrelated formula drills. Every day preserves the same base, two links, camera mount, desk frame, and measurement sheet. New mathematics earns its place by resolving the next observation: a turn, a frame path, a valid 3D orientation, a complete pose, a predicted tool point, and finally a solver trace. The mission finishes only when forward calculations round-trip, reachable targets meet a declared residual, unreachable targets stop within budget, and no result is mistaken for a safe hardware trajectory.

Why this chapter now: The course is about to use frames and motion everywhere; learners need one checked spatial model before software can hide convention mistakes.
Ignore for now: Ignore dynamics, collision planning, motor commands, and symbolic proofs. Work with rigid paper geometry, bounded calculations, and named conventions.
This unlocks: tf2, URDF, calibration, state estimation, MoveIt planning, and every sensor-to-tool relationship.
Proof you will leave with: Save tray measurements, transform-chain diagrams, SO(3) and quaternion checks, SE(3) point/direction tests, FK residuals, bounded IK traces, starter output, and one convention failure.

Environment contractPaper frames, ruler, calculator or browser notebook, and repository-supported Node.js 22.13.0 or newer. No ROS 2 or powered arm is required.

Compatibility boundary: Calculations use column vectors, radians in code, ROS-style quaternion field order only when explicitly named, and metres for geometry. Other conventions require an isolated conversion test.
Smoke check: Save the starter as week-02-camera-crane.mjs, run node week-02-camera-crane.mjs, and verify the FK point, identity round trip, and unreachable status exactly.
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 Camera-Crane Recovery starts with a sticker on the camera tray. Turn the tray, carry it across the desk, and predict the sticker’s room coordinate before measuring. The crane’s first failure report used degrees inside a radians-based function and changed operation order while debugging, so today’s record must name angle unit, source frame, destination frame, and rotate-then-translate convention.

Why now: A rigid 2D move is the smallest complete case that joins angles, sine, cosine, rotation, and translation.
Ignore today: Ignore 3D orientation and multi-link arms until this known tray case passes.
Unlocks next: A trustworthy transform edge for the crane’s frame tree.

Understand

Build the physical picture first

Imagine a sticker on a tray. Turning the tray changes the sticker's direction around the tray origin; carrying the tray shifts everything by the same amount. A 2D rigid transform records those two operations without bending or stretching the tray.

A point tells only where something is. A pose tells where it is and which way its attached axes face. In a flat world, a pose therefore needs an x position, a y position, and one angle. A transform is the rule that converts coordinates described in one pose or frame into coordinates described in another; it is not just a bag of three unrelated numbers.

Angles may be written in degrees or radians. Degrees split a turn into 360 parts. Radians measure the arc length divided by the circle radius, so one full turn is 2π radians and 180° is π radians. Most programming-language sine and cosine functions expect radians. The conversion is radians = degrees × π / 180.

Sine and cosine are not magic buttons. For a unit arrow at angle θ, cosine is its horizontal component and sine is its vertical component. The 2D rotation matrix R(θ) uses those two values to rotate every input arrow by the same angle while preserving its length. For a point p in the local frame and a local-frame origin at translation t in the world frame, the common column-vector rule is p_world = R p_local + t.

Order matters. In p_world = R p_local + t, rotate the local coordinates first and then place the rotated point at the translated world origin. Translating first and then rotating usually gives a different point because matrix operations do not generally commute. A reliable implementation names both frames, declares degrees or radians, and checks a known case such as 0°, 90°, or a forward-then-inverse round trip.

Words you need

Name each idea precisely

Pose: A description containing both position and orientation.
Physical example:
A book can occupy one desk position while facing north, east, south, or west.
Radian: An angle unit equal to arc length divided by radius.
Physical example:
An arc as long as a wheel's radius spans one radian at the wheel centre.
Sine: The vertical component of a unit arrow at an angle in the x-y plane.
Physical example:
It tells how much of a sloping paper link points upward.
Cosine: The horizontal component of a unit arrow at an angle in the x-y plane.
Physical example:
It tells how much of the same paper link points to the right.
Rigid transform: A rotation and translation that preserve distances and angles.
Physical example:
Moving a solid tray changes every sticker position but not distances between stickers.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalStart at zero: turns, triangles, and pose chains

A joint turn becomes a tool position only after we define the angle, split a link into horizontal and vertical parts, and follow frame order.

θ: theta: the amount a joint has turnedUnit: degrees (°) or radians (rad)
cos θ, sin θ: horizontal and vertical fractions of a turned unit linkUnit: no unit
Tᴬ_B: position and direction of frame B described by frame AUnit: unitless rotation + metres

A full turn is 360° = 2π rad, so 90° × π/180 = π/2 rad. π is about 3.1416.
For a 1 m link at 90°, x = 1 cos 90° = 0 m and y = 1 sin 90° = 1 m.
For several frames, follow the physical path in order. Multiply transforms only when the touching frame names match, then verify by reversing the path.

Programmer analogy

Like nested UI transforms, each child inherits its parent's transform; unlike UI, the order can move metal into an obstacle.

What are x and y for a 2 m link at 0 rad?

x = 2 cos 0 = 2 m; y = 2 sin 0 = 0 m.

For angle $\theta$ ,

R(\theta)=\begin{bmatrix}\cos\theta&-\sin\theta\\\sin\theta&\cos\theta\end{bmatrix},\qquad \mathbf p'=R\mathbf p+\mathbf t.

Here $R$ turns, $\mathbf t$ shifts, and $\mathbf p'$ is the output point. At $90^\circ=\pi/2$ rad, $(1,0)$ rotates to $(0,1)$ .

Rotate a tray point and place it in the room

A point is p_tray=(0.20, 0.00) m. The tray is rotated +90° and its origin is t_room=(0.50, 0.30) m.

Convert 90° to radians: 90 × π/180 = π/2 rad.
Use cos(π/2)=0 and sin(π/2)=1, giving R=[[0,-1],[1,0]].
Rotate the local point: R(0.20,0.00)=(0.00,0.20) m.
Add the room translation: (0.00,0.20)+(0.50,0.30)=(0.50,0.50) m.
Check rigidity: the point remains 0.20 m from the tray origin after rotation.

Result

The point is at (0.50, 0.50) m in the room frame.

What this proves

Rotate a local quantity in its declared frame, then translate the rotated point into the parent frame.

Physical examples

Where this appears in real life

Parcel on a turntable

A parcel corner is 20 cm along the turntable's local x-axis. The turntable rotates 90° and its centre is 50 cm right and 30 cm above the room origin.

Look for:

The local corner first becomes 20 cm along local/world y, then translation places it at room coordinate (50 cm, 50 cm).

Camera marker on a floor rover

A camera reports a marker 0.4 m straight ahead of the rover while the rover faces 30° from the room x-axis.

Look for:

The same 0.4 m appears as both an x and y component in the room; the rover translation must be added only after rotating the local observation.

Hands-on exercise

Make the idea observable

Use graph paper, a rectangular paper tray, a ruler, and a pen. Do not use powered hardware.

Draw a local x-y frame on the paper tray and mark a point 4 cm along +x.
Draw a separate room x-y frame on graph paper and mark the tray origin at (6 cm, 3 cm).
Rotate the tray +90° without moving its marked origin and predict the point's room coordinate.
Place the tray on the graph, measure the point, and record prediction error in millimetres.
Repeat with -90° and 180°; write every calculator angle in both degrees and radians.
Perform one deliberately wrong translate-then-rotate calculation and explain why its result differs.

Observe

Rotation changes the point relative to the tray origin; translation moves the whole rotated arrangement. Distance from point to tray origin stays constant.

Done when

Three predicted coordinates match the drawing within 2 mm and the wrong-order case is labelled with its exact cause.

Build today

Extend the browser notebook into a two-link arm visualizer with frame composition, forward kinematics, and a bounded numerical IK trace.

Evidence to save

DONE when the learning log explains “2D rotation, translation, transforms, degrees, radians, sine, and cosine” in five precise points and a checked example produces the predicted output.

Common mistakes

Catch the wrong mental model

Wrong

Passing 90 directly to a sine function that expects radians.

Better

Convert first: 90° = π/2 rad, and encode the unit in names or types.

Wrong

Adding translation before rotating a local point.

Better

For p_parent = R p_local + t, calculate R p_local first, then add t.

Wrong

Rotating the translation vector accidentally.

Better

Write the frame-labelled equation before coding and test a known pose.

Wrong

Dropping metres or centimetres from intermediate values.

Better

Convert all distances to one unit before addition and display the unit in results.

Job connection

How this becomes employable evidence

An operator map receives robot-local obstacle or tool coordinates. The engineer must convert them into the map frame before drawing, planning, or sending a target; a degree/radian or operation-order mistake can put the displayed or commanded point in the wrong place.

Relevant target roles

Robot HMI / Control & Monitoring Engineer
Robotics Application / ROS 2 Integration Engineer
Robotics Software Engineer — ROS 2 / AMR

Chapter 02 interview drill

Interview questions: 2D rotation, translation, transforms, degrees, radians, sine, and cosine

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 rover at (2,1) m faces +90°. Its sensor sees an object 0.5 m straight ahead. Explain the frame conversion, result, units, and two checks you would add.

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

Q1What extra information turns a 2D position into a 2D pose?

Model interview answer

An orientation angle, interpreted using a stated sign convention and frame.

Q2Why does a rotation matrix not change an arrow's length?

Model interview answer

Its axes are orthonormal, so the dot product—and therefore squared length—is preserved.

Q3A local point is at the frame origin. What does R p + t become?

Model interview answer

Because p=(0,0), R p=(0,0), so the parent-frame point is exactly t.

Chapter references

Modern Robotics — Rotation MatricesDays 8 and 10: rotation-matrix meaning, orthonormal columns, determinant +1, transpose inverse, length preservation, and non-commutative composition.
Modern Robotics — Homogeneous Transformation MatricesDays 9 and 12: frame-labelled transform composition, inversion, homogeneous points, SE(3), and the difference between left and right multiplication.
ROS 2 documentation — Quaternion fundamentalsDay 11: normalized quaternion use, roll-pitch-yaw conversion, and the ROS message component order (x, y, z, w).
Modern Robotics — Forward Kinematics ExampleDay 13: treating forward kinematics as an ordered map from joint configuration to end-effector pose.
Modern Robotics — Numerical Inverse KinematicsDay 14: Jacobian linearization, pseudoinverse update, dependence on the starting guess, singular cases, and bounded convergence checks.