| ID | Requirement | How we verify |
|---|---|---|
| R1 | Runs at least 30 minutes on one battery pack | Test: timed run with logging |
| R2 | Stops within 1 s when the stop switch is pressed | Test: 10 presses at full speed |
| R3 | Drives 1.0 m straight in 5 s or less, within 5 cm of the line | Measurement: tape and stopwatch, 5 runs |
| R4 | Uses only batteries up to 9 V | Inspection: parts list and wiring |
Robots as systems: requirements and architecture
A robot is like a team of friends carrying a sofa. One looks where to go, one thinks about the plan, and the others lift. If they do not agree first on who does what and how they will talk, the sofa hits the wall. Engineers write that agreement down before they build.
- Before this course: Embedded Systems: microcontrollers and sensors (course 15.7.3), which came after Robotics Basics (15.8) and Electricity & Electronics Basics (15.7). You already know Ohm's law, millis() timing, state machines, pull-ups, debouncing, interrupts, ADC calibration, UART/I2C/SPI and power budgets. This course is about whole robot systems, testing them like a professional, and leading and teaching a team.
- Sense, think, act: every robot reads sensors, decides in software and moves with actuators. A system is all of these plus power, the frame and the people who use it.
- Subsystems: split the robot into parts one person or pair can own: power, drive (motors and drivers), sensing, control software, frame and mechanics, and user interface (buttons, lights, display).
- Requirements say what the robot must do, in a way you can test. Give each a number. Bad: "The robot should be fast." Good: "R3: The robot drives 1.0 m in a straight line in 5 s or less, ending within 5 cm of the target line."
- Each requirement needs a verification method: test, measurement, inspection or demonstration. If you cannot say how you would check it, rewrite it.
- Interfaces are where subsystems meet: a connector, a voltage, a pin, a message format. An interface table lists each one, for example "Drive board to controller: PWMA on pin 5, AIN1 on pin 7, AIN2 on pin 8, common ground."
- A block diagram shows subsystems as boxes and power and signals as arrows. Draw power arrows and signal arrows in different colours.
- Trade-offs: faster usually means less torque and more current; more sensors mean more code, wiring and power. Write down why you chose each option, so the team does not argue about it again later.
- Write the robot's mission in one sentence: what it does, where, and for whom.
- List the subsystems: power, drive, sensing, control, frame, interface.
- Write at least six numbered requirements, each with a number and a unit.
- Add a verification method to every requirement.
- Draw a block diagram with power arrows in one colour and signal arrows in another.
- Fill in an interface table: every pin, connector, voltage and message between subsystems.
- Check: every requirement can be tested, and every arrow on the diagram appears in the interface table.
Videos by other creators on YouTube, for reference. They are not made by or affiliated with The Future Market.
Read the video script
[Host next to a small two-wheeled robot] "This robot is not one thing. It is six subsystems that have to agree."
[Screen: block diagram with power arrows in red and signal arrows in blue] "Draw the boxes. Draw power in one colour and signals in another."
[Text on screen: Bad: should be fast. Good: 1.0 m in 5 s.] "Then write requirements with numbers, so you can test them."
[Screen: interface table with pins and voltages] "Every place two parts meet goes in the interface table."
[Host] "Agree on paper first. It is the cheapest place to fix a mistake."
Pick a robot you could build (for example a line follower or a rover that maps a room). Write its mission, six numbered requirements with verification methods, a block diagram and an interface table.
ClaudeStuck? Copy a ready-made prompt for Claude
Copy this, open Claude, paste it, and Claude will walk you through the lesson step by step.
For a grown-up: Claude is for adults (18+). Copy this, paste it into Claude, and use the answer to explain the lesson to your child.
I'm learning "Robotics Engineering: systems and teams" on The Future Market. Lesson 1: "Robots as systems: requirements and architecture". What the lesson teaches: - Before this course: Embedded Systems: microcontrollers and sensors (course 15.7.3), which came after Robotics Basics (15.8) and Electricity & Electronics Basics (15.7). You already know Ohm's law, millis() timing, state machines, pull-ups, debouncing, interrupts, ADC calibration, UART/I2C/SPI and power budgets. This course is about whole robot systems, testing them like a professional, and leading and teaching a team. - Sense, think, act: every robot reads sensors, decides in software and moves with actuators. A system is all of these plus power, the frame and the people who use it. - Subsystems: split the robot into parts one person or pair can own: power, drive (motors and drivers), sensing, control software, frame and mechanics, and user interface (buttons, lights, display). - Requirements say what the robot must do, in a way you can test. Give each a number. Bad: "The robot should be fast." Good: "R3: The robot drives 1.0 m in a straight line in 5 s or less, ending within 5 cm of the target line." - Each requirement needs a verification method: test, measurement, inspection or demonstration. If you cannot say how you would check it, rewrite it. - Interfaces are where subsystems meet: a connector, a voltage, a pin, a message format. An interface table lists each one, for example "Drive board to controller: PWMA on pin 5, AIN1 on pin 7, AIN2 on pin 8, common ground." - A block diagram shows subsystems as boxes and power and signals as arrows. Draw power arrows and signal arrows in different colours. The exercise I'm working on: Pick a robot you could build (for example a line follower or a rover that maps a room). Write its mission, six numbered requirements with verification methods, a block diagram and an interface table. --- I'm stuck. Please: 1. Explain the main idea in plain, simple words with one everyday example. 2. Walk me through the exercise one small step at a time. Ask me what I've done so far before giving the next step. 3. Don't just give me the final answer. Help me do it myself, and check my work when I share it.
I'm a parent helping my child (about 8 years old) with a lesson called "Robots as systems: requirements and architecture" from the course "Robotics Engineering: systems and teams". Here's what the lesson says: A robot is like a team of friends carrying a sofa. One looks where to go, one thinks about the plan, and the others lift. If they do not agree first on who does what and how they will talk, the sofa hits the wall. Engineers write that agreement down before they build. The activity: Pick a robot you could build (for example a line follower or a rover that maps a room). Write its mission, six numbered requirements with verification methods, a block diagram and an interface table. --- Please explain this so an 8-year-old understands: short sentences, a fun everyday example, and no hard words. Then give me 3 simple questions I can ask my child to check they understood, and a way to do the activity together, one tiny step at a time.
Motors, drivers and PWM
This lesson is part of full access: every course and every level for one payment.
Encoders and feedback control (PID)
This lesson is part of full access: every course and every level for one payment.
Power systems and electrical safety
This lesson is part of full access: every course and every level for one payment.
Sensors, filtering and knowing where you are
This lesson is part of full access: every course and every level for one payment.
Testing, failure analysis and safety stops
This lesson is part of full access: every course and every level for one payment.
Leading the team: reviews, version control and teaching others
This lesson is part of full access: every course and every level for one payment.
Final project
This lesson is part of full access: every course and every level for one payment.
Quiz
What makes a requirement good?
It has a number, a unit and a way to verify it, such as a test or measurement.
What is an interface table for?
It lists every pin, connector, voltage and message where two subsystems meet.
Why can a microcontroller pin not drive a motor directly?
A pin can give only a small current (about 40 mA at most); a motor needs a driver.
What does an H-bridge let you do?
Run a DC motor forward or backward by switching which pair of switches is closed.
A motor has a 4 ohm winding on a 6 V supply. What is its stall current?
About 1.5 A (6 / 4).
What does analogWrite(pin, 127) do on a 6 V motor supply?
Gives about a 50% duty cycle, roughly 3 V on average.
A 6,000 rpm motor has a 48:1 gearbox. How fast does the wheel turn?
125 rpm, with about 48 times the torque minus losses.
What does the I term in a PID controller fix?
An error that stays, such as always running a little slow.
Why give motors their own supply and join the grounds?
So motor current surges do not make the logic voltage sag and reset the board.
What should a hardware stop switch do?
Cut motor power directly, so it works even if the code freezes.
Why does dead reckoning drift?
Small errors such as wheel slip and uneven wheels add up over distance.
How is an FMEA risk priority number calculated?
Severity x occurrence x detection.
What does this course say about mains (wall-power) wiring?
It is off limits; building wiring is work for licensed electricians under your country's rules.
Final exam
This lesson is part of full access: every course and every level for one payment.
Certificate
This lesson is part of full access: every course and every level for one payment.