IoT for Robotics

An eight-week remote cohort course. Learners start by switching on an LED and finish by driving a WiFi-connected robot through a live telemetry dashboard at a public Demo Day.

See the weeks View Demo Day

Duration: 8 weeks plus Week 0
Delivery: Fully remote
Pace: 2 to 4 hours a week

How the course works

The course is built around one narrow outcome. By Week 8 every learner has a robot that reports its own status to a live dashboard, and that can be driven remotely through the same dashboard. Every week adds exactly one new capability to that same robot.

Format

Duration 8 weeks, plus a mandatory Week 0 hardware bootcamp
Pace One live theory and demo session plus one hands-on lab session each week
Delivery Fully remote, with instructor demos on a dual camera showing the face and an overhead bench view
Outcome A working, WiFi-connected, dashboard-operated robot, demonstrated live on Demo Day

Who it is for

A mixed-level cohort of students, working technicians and career switchers. Little prior coding experience is required, and no electronics experience is assumed.

A laptop that can run the Arduino IDE and a modern web browser
A stable internet connection for live sessions and for the robot's own WiFi during labs
Willingness to buy the standard hardware kit (about ₦60,000) before Week 0

Cohort structure

Learners form pods of 3 to 4 from Week 0. Pods mix backgrounds where possible, for example a technician with a student or a coder. They stay together for the whole course and become the Demo Day teams in Week 8.

Two touchpoints a week

Live theory and demo session (60 to 90 minutes). Concepts, live-coded demos and Q&A. Recorded for asynchronous viewing.
Hands-on lab evening (60 to 150 minutes). Pods work on hardware while the instructor and teaching assistants help with live troubleshooting.

Course philosophy

The biggest failure in technical teaching is introducing vocabulary before the learner has felt the problem it solves. These principles are there to prevent that.

Problem before term. Every concept is introduced only after learners have hit the problem it solves. Pub/sub, for example, is taught through a physical note-passing exercise before any code is written.
One robot, growing every week. The same physical robot gains one new capability per week, so new material always connects to what learners have already built.
Hands-on every session. No concept is taught without a same-session demonstration on hardware or in the simulator. Passive lecture time is kept to a minimum.
Public, objective checkpoints. Progress is verified by visible behavior, such as "show me your sensor reading live", not by written tests. A learner either made the machine talk or they did not.
Failure is normalized and staged. The instructor demonstrates deliberate failures on camera, such as dropped WiFi or a missing resistor divider, before learners meet them blind. A weekly "failure of the week" share keeps debugging framed as the skill being taught.
Mixed levels by design. Every week ships a core task and a stretch task. Pods pair a stronger coder with a stronger hands-on learner, so peer teaching does work the instructor cannot do one to one over video.

Remote hardware teaching

A dual camera setup puts one camera on the instructor and one on the bench, so learners see hands touching wires.
Every physical demo has a matching Wokwi version, so a learner with a hardware failure can still follow along.
Every live session ends with the "show me yours" ritual, where each pod holds its robot or screen up to the camera. It doubles as attendance and progress tracking.

Kit discipline

Kit inconsistency is the biggest risk to a remote hardware course, because the instructor cannot resolve mismatched parts over video.

One exact bill of materials with specific purchase links, sent before Week 0
A bundled order through one main vendor where possible
Week 0 as a mandatory bootcamp and diagnostic gate
An instructor-held spares pool of duplicate core components

By the end of the course a learner can

Explain, in plain language, what an IoT device is and how physical signals become data
Wire and read digital and analog sensors on a microcontroller, including handling logic-level mismatches
Write and upload microcontroller code to control motors and read sensors (Arduino and C++ basics)
Explain the publish/subscribe messaging model and implement it with MQTT
Build a live monitoring and control dashboard in Node-RED
Implement basic device robustness: reconnection logic, status signaling and failure handling
Operate and troubleshoot a small WiFi-connected robot end to end, independently

Curriculum at a glance

Each card shows the week's deliverable. Pick a week to jump to its full plan.

0
Hardware Bootcamp and OnboardingA screenshot of the diagnostic pass report and confirmation of pod assignment.
1
Hello, Machine: Code Meets the Physical WorldA video clip (15 to 30 seconds) of the LED blinking, plus a serial monitor screenshot.
2
The Robot Feels: Sensors and Analog InputA serial monitor recording showing distance changing as a hand moves.
3
The Robot Moves: Motors and PowerA video of the robot completing a forward, stop and turn sequence.
4
The Robot Speaks: Introduction to MQTTA screen recording of the phone MQTT app showing live incoming data from the learner's robot.
5
The Robot Listens: Bidirectional ControlA video of a teammate driving the robot live using only a phone MQTT app.
6
The Dashboard: Node-REDA screen recording of the dashboard driving the robot and displaying live telemetry at the same time.
7
Make It RobustA video showing the WiFi drop and recovery sequence with the status LED visibly changing state.
8
Mission Demo DayA live demo, plus a one-page project summary per pod covering what they built, what broke and what they would do differently.

Week 0 to Week 8

Every week lists objectives, concepts, session activities, a core task and a stretch task, the deliverable, and homework.

Week 0

Hardware Bootcamp and Onboarding

Nobody starts broken.

Session activities

Live unboxing walkthrough on the overhead bench camera, with every learner following along part by part
Install the Arduino IDE and the ESP32 board manager together, screen-shared, with live troubleshooting
Flash the instructor-provided diagnostic firmware to each board
The firmware blinks the onboard LED, prints board info to the serial monitor and checks the WiFi radio; learners screenshot the pass or fail report
Introduce pods of 3 to 4 learners, the cohort channel and the "failure of the week" ritual

Learning objectives

Every learner has a verified, working kit before any content begins.
Learners can install and use the Arduino IDE (or PlatformIO) and the ESP32 board package.
Learners understand the cohort's tools, channels, rituals and expectations.

Key concepts introduced

What a microcontroller is, in one sentence: a tiny computer that can sense and act on the physical world
Anatomy of the ESP32 board: USB port, voltage regulator, GPIO pins, boot and enable buttons
The difference between a data cable and a charge-only cable

Core task

Flash the diagnostic firmware, produce a passing screenshot and post it to the cohort channel.

Stretch task

Modify the diagnostic sketch to blink in a custom pattern and share the .ino file.

Deliverable

A screenshot of the diagnostic pass report and confirmation of pod assignment.

Homework

Read the board pinout diagram and label VIN, GND and three GPIO pins from memory.

Week 1

Hello, Machine: Code Meets the Physical World

Code makes physical things happen.

Session activities

Live-coded blink sketch, built line by line with the group
Breadboard basics: what the rails mean and how a circuit completes
Wire an external LED with a resistor; learners explain why the resistor is there
Print the internal temperature to the serial monitor once per second

Learning objectives

Learners write and upload their first original sketch.
Learners understand GPIO as a controllable on/off switch.
Learners read a single value from the ESP32 itself, with no external sensor yet.

Key concepts introduced

Digital output: HIGH and LOW, pinMode(), digitalWrite()
The upload cycle of write, compile, flash and run, and what the errors at each stage look like
Reading the ESP32's internal temperature sensor as a first reading
The serial monitor as a window into a running device

Core task

Blink an external LED at a fixed interval and print a changing sensor value to the serial monitor.

Stretch task

Encode a name or message in Morse code using LED timing, and add a second LED with independent timing.

Deliverable

A video clip (15 to 30 seconds) of the LED blinking, plus a serial monitor screenshot.

Homework

Sketch on paper a circuit for two LEDs blinking alternately and bring it to the Week 2 lab.

Week 2

The Robot Feels: Sensors and Analog Input

The physical world becomes numbers.

Session activities

Wire the HC-SR04 with the resistor divider on Echo and read distance in cm on the serial monitor
Wire the joystick module (or a potentiometer) to an ADC1 pin and read raw analog values live
Guided exercise: move a hand toward and away from the sensor and correlate it with the printed numbers
Common failure clinic: reversed trig and echo, a missing divider, the wrong GPIO. The instructor demonstrates each failure on camera

Learning objectives

Learners wire and read an ultrasonic distance sensor.
Learners understand analog and digital signals.
Learners understand why a voltage divider is needed between 3.3V logic and a 5V sensor.

Key concepts introduced

Analog input: the ADC, its resolution (0 to 4095 on the ESP32), and potentiometers as a tactile example
Digital sensor timing: the HC-SR04 trigger and echo pulse, and how distance is calculated from time
Logic-level mismatch: why a 5V sensor output can damage a 3.3V GPIO pin, and how a resistor divider fixes it
Noise and jitter: why raw sensor readings wobble, and a first taste of averaging

Core task

Print live distance readings from the HC-SR04 to the serial monitor, updating at least twice per second.

Stretch task

Add a second sensor (DHT11, DHT22 or MPU6050) and print both readings on the same line, comma-separated.

Deliverable

A serial monitor recording showing distance changing as a hand moves.

Homework

Write in plain English what would happen if the Echo pin were wired directly without the divider.

Week 3

The Robot Moves: Motors and Power

The fun week, and the first real power lesson.

Session activities

Assemble the chassis (if it is not pre-assembled) and mount the L298N and ESP32
Wire the motor channels and live-test each direction on its own before combining them
Write reusable functions: forward(), reverse(), turnLeft(), turnRight(), stop()
Mandatory live battery safety briefing before any battery is connected
Group challenge: navigate a simple taped course on the floor using only pre-written code, with no live driving yet

Learning objectives

Learners wire the L298N motor driver to the chassis motors.
Learners write functions for forward, back, left, right and stop.
Learners understand current draw and why power design matters.

Key concepts introduced

H-bridge basics: how IN1 to IN4 and ENA and ENB control direction and speed
PWM for speed control (analogWrite, or ledcWrite on the ESP32)
Power budgeting: why motors and WiFi together can brown out a weak supply
Safe handling, charging and storage of Li-ion cells (with an AA fallback)

Core task

The robot drives forward, stops and turns on command from a fixed test sketch.

Stretch task

Add speed control through PWM and complete the taped course in the fewest lines of code.

Deliverable

A video of the robot completing a forward, stop and turn sequence.

Homework

List three things that could make a robot behave unpredictably on battery power compared with USB power.

Week 4

The Robot Speaks: Introduction to MQTT

My robot is on the internet.

Session activities

Conceptual demo: the classroom note-passing exercise, revisited and mapped onto MQTT terms
Connect the ESP32 to WiFi and a shared MQTT broker, and publish distance readings on a timer
Install a free MQTT client app on phones, subscribe to the pod's topic and watch live data arrive
Debug clinic: WiFi connection failures, broker connection refused, topic typos

Learning objectives

Learners understand publish/subscribe messaging conceptually and in code.
The robot publishes live sensor data to a broker.
Learners watch their own data arrive on a phone MQTT client.

Key concepts introduced

Pub/sub as a walkie-talkie model: topics as channels, with no direct connection between devices
Anatomy of an MQTT topic path, for example cohort/podX/robot/distance
The broker's role: a public test broker compared with a private one, and why production systems avoid public brokers
Payload design: readable values (numbers or JSON) compared with raw bytes

Core task

The robot publishes distance readings to a unique per-pod topic at least once per second, and the learner confirms receipt on a phone MQTT app.

Stretch task

Publish a second telemetry channel (a battery voltage estimate or IMU data) as a structured JSON payload.

Deliverable

A screen recording of the phone MQTT app showing live incoming data from the learner's robot.

Homework

Write out, in the topic-path format taught, the topic you would use for a kitchen fridge temperature sensor at home.

Week 5

The Robot Listens: Bidirectional Control

Now it talks back.

Session activities

Wire up the subscribe logic and test it with manually published messages from a phone app
Implement forward, back, left, right and stop over MQTT
Add the mandatory safety feature: auto-stop if no command arrives within a set window
Pair driving exercise: one learner drives from a phone while teammates watch the robot respond in real time

Learning objectives

The robot subscribes to a command topic and acts on incoming messages.
Learners implement a safety timeout for lost connections.
Learners drive their robot remotely for the first time.

Key concepts introduced

Subscribing and callback functions: what happens when a message arrives
Command design: simple string commands compared with structured JSON commands
Real-world engineering: what should a robot do when WiFi drops mid-command? A fail-safe stop
Latency and its practical effect on driving feel

Core task

The robot responds correctly to all five commands published from a phone MQTT app, and stops automatically if commands stop arriving.

Stretch task

Add speed as a parameter in the command payload, for example "forward:150".

Deliverable

A video of a teammate driving the robot live using only a phone MQTT app.

Homework

Describe in plain language one real-world industrial scenario where a lost-connection safety stop matters, such as a crane or a conveyor.

Week 6

The Dashboard: Node-RED

From messages to a mission control screen.

Session activities

Install Node-RED locally, run as a mini-bootcamp that echoes Week 0
Guided build: an MQTT-in node into a gauge node, watching data appear live
Add a joystick or button widget wired to an MQTT-out node that publishes commands
Stretch track: learners who use function nodes transform incoming JSON, add thresholds, or build a custom web page instead

Learning objectives

Learners install and navigate Node-RED.
Learners build a live dashboard with gauges and a driving control.
Beginners and coders both ship a working dashboard, each at their own depth.

Key concepts introduced

Node-RED's flow model: nodes and wires as a visual pub/sub pipeline
MQTT-in and MQTT-out nodes, and how they map to what was hand-coded in Weeks 4 and 5
Dashboard nodes: gauges, charts, buttons and a joystick widget
Where beginners stop (drag-and-drop wiring) and where coders extend (function nodes with JavaScript)

Core task

A working Node-RED dashboard showing live distance (and/or battery) and a working drive control that moves the robot.

Stretch task

Add a data logging chart of the last 5 minutes of readings, or build the control page as custom HTML and JavaScript instead of default widgets.

Deliverable

A screen recording of the dashboard driving the robot and displaying live telemetry at the same time.

Homework

Sketch, on paper or in Node-RED, what a low-battery warning flow would look like.

Week 7

Make It Robust

Demos work once; products work always.

Session activities

Instructor-led deliberate failure: disconnect WiFi mid-operation, observe the unhandled failure, then patch it live
Implement auto-reconnect for WiFi and MQTT
Add a status LED with distinct patterns for connected, reconnecting and low battery
Stretch lab: wire the MPU6050 and publish a tilt or impact event to its own MQTT topic

Learning objectives

Learners add reconnection logic for WiFi and MQTT.
Learners add a low-battery alert and a physical status indicator.
Learners understand the gap between a fragile demo and a dependable device.

Key concepts introduced

Reconnection patterns: detecting a dropped connection and retrying without a manual reset
Status signaling: an onboard LED or buzzer that communicates device state without a screen
Threshold alerts: battery voltage estimation and a simple alerting rule
Optional stretch concepts: IMU-based tilt and impact detection, and encoder-based speed measurement

Core task

The robot automatically reconnects after a simulated WiFi drop, and a status LED reflects connection and battery state accurately.

Stretch task

Publish an IMU-based "collision detected" event that shows up on the Week 6 dashboard as an alert.

Deliverable

A video showing the WiFi drop and recovery sequence with the status LED visibly changing state.

Homework

Write the mission-day operating checklist for your own robot, in your own words.

Week 8

Mission Demo Day

Telemetry isn't decoration, it's how you win.

Session activities

Mission format: one pod member operates the robot through a course seeing only the Node-RED dashboard, while teammates coach using only verbal telemetry descriptions
Each pod gives a 3 to 5 minute demo and explanation to invited guests (family, hiring partners, press if available)
Instructor demo: the "hero" robot arm or second-device showpiece, framed as where this goes next
Certificates, a group photo and a cohort retrospective

Learning objectives

Pods complete a live operator challenge using only the dashboard.
Learners present their build to invited guests.
The cohort has a public, memorable close.

Key concepts introduced

Recap of the full data journey from a physical sensor to a decision made on a screen
What is next: a light preview of where this connects to broader IoT and industrial systems

Core task

Complete the operator mission course using dashboard telemetry only.

Stretch task

Pods that finish early attempt an optional obstacle-avoidance or timed-course variant.

Deliverable

A live demo, plus a one-page project summary per pod covering what they built, what broke and what they would do differently.

Homework

None. The course is complete.

Hardware and bill of materials

Each learner buys a standard kit from a published bill of materials before Week 0. Item-level pricing, vendor links and procurement notes are kept in a companion spreadsheet.

Core electronicsESP32 dev board, L298N motor driver, HC-SR04 ultrasonic sensor, 2WD chassis kit₦28,500
Power2× 18650 cells with holder, charger, data cable₦14,000
Wiring and prototypingBreadboard, jumper wires, resistor kit, LEDs, buttons₦9,800
Optional and stretchDHT22 sensor, MPU6050 IMU, screwdriver setup to ₦9,500

Kit totals

Core kit total (required): ₦52,300

With optional and stretch items: ₦61,800

Recommended learner budget (core plus a 15% buffer): ₦60,000

Instructor-side equipment

A shared robot arm and a second WiFi-enabled device are used for demonstrations only and are not part of the learner kit. That keeps mechanical-arm cost and complexity off the learner.

Tools and platforms

Arduino IDEWriting and flashing microcontroller code (Weeks 0 to 7). Free.
WokwiBrowser-based ESP32 simulator, used for homework and as the hardware-failure fallback. Free.
Mosquitto or a public test brokerThe MQTT message broker for pub/sub communication (Weeks 4 to 8). Free.
MQTT phone clientLearner-side visibility into the robot's messages, for example IoT MQTT Panel. Free.
Node-REDThe visual dashboard and control-flow builder (Weeks 6 to 8). Free, installed locally.
Node.jsThe runtime needed to install Node-RED locally. Free.

Why Node-RED

Node-RED was chosen over industrial platforms such as ThingsBoard because its drag-and-drop flow model teaches the data pipeline as learners build it. It also scales across mixed skill levels: beginners wire up a working dashboard, while stronger coders extend it with JavaScript function nodes in the same tool. A short instructor demo of an industrial SCADA or dashboard screen in Week 7 or 8 lets learners map what they built onto professional tooling.

Assessment and risk

The course avoids written tests. Progress is tracked through visible checkpoints that are hard to fake and quick to verify remotely.

Weekly checkpoint model

Each week has one core task, which is required, and one stretch task for faster learners.
Each week ends with a deliverable, usually a short video or screenshot posted to the cohort channel.
The "show me yours" live-camera ritual works as attendance and as a real-time progress check.

Gating into Week 8

Only pods that have completed the core deliverable for Weeks 1 to 7 take part in the public Demo Day as full mission teams. That protects the quality of the event and gives every pod a reason to keep pace.

How the course handles risk

Inconsistent learner hardwareA single published bill of materials with exact purchase links, and a bundled vendor order where possible.
Dead or damaged componentsThe Week 0 diagnostic gate catches failures early, and an instructor spares pool allows rapid replacement.
A learner falls behind after a hardware failureWokwi mirrors every physical lab, so learners can continue without working hardware.
Li-ion battery safetyA mandatory safety briefing in Week 3 before any battery is connected, with an AA fallback.
Remote debugging difficultyA dual-camera bench view, pods that pair stronger and weaker learners, and teaching assistants on lab evenings.
Cohort attrition over 8 weeks and moreTwo touchpoints a week, a visible progress wall, persistent pods, and a Demo Day announced from Week 0.
3.3V and 5V logic mismatch damaging boardsTaught explicitly as a concept in Week 2 rather than hidden as a wiring instruction, with divider resistors in the kit.

Demo Day

Demo Day closes Week 8 as a live mission rather than a static showcase, so that telemetry is needed and not just decoration.

Mission format

One pod member operates the robot through a taped course using only the Node-RED dashboard, with no direct line of sight to the robot.
Teammates act as spotters. They watch the physical robot and coach the operator verbally, without touching the controls.
Success is measured by course completion and by the pod's ability to explain what the dashboard told them at each decision point.

Presentation

Each pod gives a 3 to 5 minute demo and explanation to invited guests, such as family, hiring partners and press where possible.
The instructor closes with a short demo of a shared "hero" device, for example a WiFi-controlled robot arm, as a preview of where these skills lead.
Certificates and a group retrospective close the cohort.

Under review: a shared robot arm

A proposal, not part of the confirmed course. One instructor-owned arm would join WiFi and MQTT as its own IoT device, and learners would take turns sending it commands from their own dashboards while watching it respond on camera. It would show several independent clients commanding one shared physical asset, and why commands must be queued or arbitrated safely. It would be piloted on the instructor's bench first. The course stands complete without it, because Demo Day already includes an instructor-only arm demo.