Detailed content
🧭 Class profiles and paths based on needs
This course has no required sequence or fixed number of hours. It has five tracks that build in difficulty, each ending with a working robot, and you choose the section that fits your class. The right question isn’t "where does the course start?" but "what does this class already know, and which robot can they finish?". A high school group that has never seen a resistor starts with Track 1. An engineering class that already programs Arduino can go straight to computer vision or ROS 2.
🌱 New here?
A path is the set of tracks and modules a class takes, in the order that makes sense for them. Path is a course section with six modules and a project at the end (T1 to T5). Module is a page with six topics; each topic has a button to mark it as read, so you can track progress (topic 8).
How to read this map: on the left, in pink, is who the class is; on the right, in cyan, is the course section that usually fits. The arrow isn’t a rule: if half the class already knows T1, split them into two paths and bring everyone together for the final project. The club is highlighted because it’s the only profile that can take its time with the entire course.
Start with Wokwi (a browser-based simulator), then hand out kits. The rover in 1.6 and the line follower in 2.6 are the projects that engage students most and connect with OBR.
Electronics and soldering are already part of their program: move quickly through 1.2 and go deeper into PID, telemetry (T2), and communication between Raspberry Pi and ESP32 (3.5).
Use T1 for self-paced work at home. In class, focus on what requires a lab: ROS 2 with Nav2 (T4) and the SO-101 arm learning by demonstration (T5).
Mixed audience and irregular attendance: each session needs to stand on its own. Keep T1 running as a permanent entry point and let experienced members lead projects from T3 to T5.
💡 First-session check-in
Before choosing a path, ask the class three quick questions: "has anyone programmed before?", "has anyone connected an LED to a board?", "has anyone used Linux?" The answers tell you whether to start with T1, T2, or T3, and who can mentor whom.
Why learn this
The biggest risk in a robotics course is the class getting stuck halfway through a project that’s too big for what they know. Choosing a path based on the class profile helps everyone finish a working robot, which keeps them motivated for what comes next.
Key concepts
🗓️ Formats: from a workshop to an ongoing club
Instead of thinking in hours, think in sessions: each meeting is a session with a beginning, middle, and end, where the group leaves with something working. A fast-paced class completes one module per meeting; beginners may need two or three meetings for the same module. That’s why the course doesn’t set a fixed duration: count meetings and adjust to the class’s actual pace.
How to read this map: Each row is a format, and each column is a track. A full circle means the entire track can be completed. A half circle means only part of it. A dashed cyan line marks an alternative for a class that has already mastered the previous track. Notice the staircase: the more meetings, the further to the right the class gets.
Just one meeting. Goal: everyone leaves having made something work.
A shortened version of Module 1.1, plus an LED blink and distance sensor in Wokwi. If kits are available, use a preassembled rover for the class to program to avoid obstacles.
6 to 10 meetings. Goal: one robot per group.
Complete Track 1, ending with the rover in 1.6. For a class that already knows Arduino: a line follower with PID (2.3 + 2.6).
15 to 20 meetings. Goal: two projects and a portfolio.
T1 + T2 (rover and line follower), or T2 + T3 for technical schools and universities (line follower and a camera-based object-tracking robot).
Meetings with no set end date. Goal: build a community.
Newcomers always start in T1; experienced members work on T3 to T5 projects and prepare for competitions. The most experienced students become mentors.
💡 Set aside a few catch-up meetings
For any format longer than a workshop, set aside one meeting every four or five meetings with no new content. It gives anyone who has fallen behind a chance to catch up, while those who are ahead can try the extra challenge. This is what keeps the slower group from giving up.
Why learn this
The same content can fit very different schedules. Counting meetings instead of promising a set number of hours keeps the plan realistic: you know how many meetings you have and decide how far the class will get without cutting a project short.
Key concepts
🧰 Kits per group, budget, and where to buy
Buy one set for each group of 3 to 4 students, not for each student. Fewer students per group multiply the cost; more leave some with nothing to do. Buy each track’s kit as the class progresses: the T1 kit is inexpensive and provides the foundation for T2. Starting with T3 (Raspberry Pi 5, camera, LiDAR, arm), costs rise, so it makes sense to share equipment among groups or classes.
| Path | Per group (3–4 students) | Estimated cost per group | No kit needed |
|---|---|---|---|
| T1 | ESP32 with data cable, breadboard, LEDs and resistors, HC-SR04, 2 IR sensors, 2 TT motors, TB6612FNG or DRV8833 driver, NiMH or 18650 batteries with BMS, chassis | R$ 200–400 | Wokwi covers 1.1 to 1.4 |
| T2 | T1 kit + IMU (MPU-6050 or ICM-20948), 2 motors with encoders, 5-sensor IR array, microSD module; optional OLED display | + R$ 150–350 | Wokwi for IMU, Wi-Fi, and logic |
| T3 | Raspberry Pi 5 (4 or 8 GB), official 27 W power supply, 32 GB or larger card, active cooler, Camera Module 3; optional AI HAT+ | + R$ 1.100–1.900 | YOLO26 runs on a PC with a webcam |
| T4 | T3 robot + 2D LiDAR (RPLIDAR C1/A1 or LD19) | + R$ 450–1.100 | Gazebo covers the entire track |
| T5 | SO-101 arm (leader/follower pair, Feetech STS3215 servos, 3D-printed parts) + 1–2 USB cameras; GPU or Colab for training | R$ 1.800–4.500 for the leader and follower pair | MuJoCo; one arm per class |
Approximate prices as of Oct/2026, in reais, for the entire group. They vary widely by store, shipping, exchange rate, and import fees: check before buying. From T2 onward, the amount is what you add to the previous kit.
✓ Buying tips
- ✓Buy 10 to 20% extra inexpensive parts (LEDs, resistors, jumpers, IR sensors): they burn out and get lost.
- ✓Use the same board model for the entire class: one tutorial will work for everyone.
- ✓Pack each kit in a numbered box with the contents list attached to the lid.
- ✓Test every board and sensor before the first meeting.
✗ Avoid
- ✗Prepackaged “37-sensor” kits: most of the parts will stay in the drawer.
- ✗L298N driver and 9 V battery for motors (inefficient, as explained in 1.1).
- ✗Buying Raspberry Pi and LiDAR before the class finishes T1.
- ✗USB cables that only charge: the board lights up, but the computer can’t detect it.
Where to buy
Brazilian electronics and robotics stores deliver quickly and issue tax invoices, which makes public-sector purchases easier. Importing through international marketplaces costs less per item, but takes longer, may incur import fees, and doesn’t provide an invoice for expense reporting. A common strategy is to buy T1 and T2 kits from a local store, then get quotes from three suppliers for the expensive parts (Pi 5, camera, LiDAR, arm servos). For the SO-101, the plastic parts can be printed at the school if it has a 3D printer.
💡 Kits shared across classes
The kits are reusable (except for LEDs and jumpers). At the end of each project, ask the group to take everything apart, check the list on the lid, and return the complete kit. That way, the same batch can serve several classes, and the budget only needs to cover replacements.
Why learn this
Buying the wrong parts is the most expensive way to get started: components that don’t fit, incomplete kits on the day of the session, different boards that require different tutorials. One standardized, checked kit per group lets you teach instead of hunting for jumper wires.
Key concepts
📋 Sample session plan
Every session can follow the same five steps: opening (the day’s problem), demonstration (you show it working), hands-on work (groups build and program), challenge (a variation for those who finish) and reflection (the lab journal). The class learns the routine and starts organizing itself. The hands-on work is always the longest step; the others are short.
How to read this map: From left to right is the order of the session. The large, bright box is where the class spends most of the session, hands on the kit. If the opening and demonstration grow until they’re as long as that box, the session has turned into a lecture.
Before the session
Try it yourself first
Run the module example on your kit from scratch, the way a student would. Note where you get stuck: that’s where the class will get stuck too.
Prepare anything that takes time
Installations (Arduino IDE, esp32 package, Python libraries) and large downloads should be ready beforehand. Installing during the session takes up all the hands-on time.
Check the kits
Open each box, test one board per kit, and set aside spare parts on your table.
Goal: a blank plan for any session. Copy and paste it into your text editor and fill in the fields between angle brackets.
MEETING PLAN · Robotics from Zero to Expert
Class: <class name> Meeting no.: <number>
Course module: <e.g., 1.4 Sensors>
Today's goal (one sentence): <what each group will have working by the end>
1. OPENING
Problem question: <e.g., how does the robot know it's about to hit something?>
Connection to the previous meeting: <what they already know>
2. DEMONSTRATION
What I show working: <circuit, code, or video>
What the class should observe: <number on the screen, LED, movement>
3. HANDS-ON (per group)
Steps: <assemble · copy the module's code · upload · verify>
How to tell it worked: <the module's "How to verify" section>
Expected errors: <cable, polarity, port, library>
4. CHALLENGE (for those who finish)
Variation: <change a value, combine two sensors, optimize>
5. RECORD
Logbook: what we did · what went wrong · how we fixed it
Evidence: <photo, short video, or Serial Monitor screenshot>
Safety for today: <battery, soldering, motor, arm: what's relevant today>
Materials per group: <list>How to check
- ✓The “goal for today” fits in one sentence and is something you can see working.
- ✓Item 3 points to the course module’s “How to check” section.
- ✗If item 3 has more steps than item 2 has sentences, that’s great; the opposite is a sign of a lecture-style class.
Example 1 · Track 1: blink an LED and read the HC-SR04
🌱 New here?
O HC-SR04 is an ultrasonic distance sensor: it emits a high-pitched sound that no one can hear and measures how long the echo takes to return. It runs at 5 V, while the ESP32 runs at 3.3 V: that’s why the response pin (Echo) goes through a voltage divider, two resistors that reduce 5 V to a safe level. The Wokwi is the free browser-based simulator where you can build all of this without a kit.
MEETING PLAN · Track 1
Course modules: 1.1 (topic 6) and 1.4 (topic 2)
Today's goal: each group sees the LED blink and the distance in cm in the Serial Monitor.
1. OPENING
Question: "how does a robot vacuum know the wall is close?"
Show a bat or a car's reverse sensor: sound that bounces back.
2. DEMONSTRATION
On the projector: the 1.1 blinking LED running in Wokwi (GPIO 2, 220-ohm resistor).
Then the HC-SR04 in Wokwi: drag the distance control and watch the number change.
3. HANDS-ON
a) Wokwi: copy the 1.1 blinking LED, assemble the circuit, press play.
b) Real kit: build the same circuit on the breadboard and upload with Arduino IDE 2.x.
c) Connect the HC-SR04: VCC to 5 V, GND to GND, Trig to a GPIO,
Echo through the voltage divider to another GPIO (see module 1.4).
d) Copy the code from module 1.4 and open the Serial Monitor.
It worked when: your hand at 10 cm shows as about 10 on the monitor.
Expected errors: charge-only cable, reversed LED, Echo without a voltage divider,
Serial Monitor baud rate different from the one in the code.
4. CHALLENGE
The LED turns on when something is less than 20 cm away (combine the two code examples).
5. RECORD
Logbook + short video of the LED reacting to your hand.
Safety for today: never put 5 V on an ESP32 input pin;
disconnect USB before changing wires.Example 2 · Track 3: detect objects with YOLO26
🌱 New here?
YOLO26 is the current version of Ultralytics’ object detector: it takes an image and returns boxes around what it recognizes (a person, bottle, or phone), each with a confidence score from 0 to 1. NCNN is a format that makes the model faster on the Raspberry Pi 5 CPU. False positive is when the model “sees” something that isn’t there.
MEETING PLAN · Track 3
Course module: 3.3 Detect objects with YOLO26
Goal for the day: each group measures when the detector gets it right and when it gets it wrong.
BEFORE (teacher): Pi 5 with Raspberry Pi OS 64-bit, virtual environment
created and the package already installed (pip install ultralytics), model
yolo26n downloaded, camera tested. Installing it during the meeting won’t work.
1. OPENING
Question: "what does the robot need to know to follow a person?"
Connection: in 3.2 the camera found a color; today it recognizes objects.
2. DEMONSTRATION
Run the module 3.3 example on the Pi 5 with the camera pointed at the room.
Show the boxes, the class name, and the confidence score.
3. HANDS-ON (each group tests and fills in the table)
Objects: bottle, phone, cup, one person from the group.
For each one: good light / dim light · near / far · from the side.
Record: detected? what confidence? did anything appear that wasn’t there?
Success criteria: the group has at least 12 test rows.
4. CHALLENGE
Export to NCNN and compare the speed, as in module 3.3:
yolo export model=yolo26n.pt format=ncnn
How many images per second before and after?
5. LOG
Logbook + the test table + one conclusion:
"under what conditions should our robot NOT trust the camera?"
Safety for the day: Pi 5 with a cooler and official power supply;
do not connect or disconnect the camera while the Pi is powered.How to check: By the end, each group can name one condition in which the detector works well and one in which it fails. This conclusion feeds into project 3.6, where the robot follows an object. Official Pi guide: docs.ultralytics.com/guides/raspberry-pi.
Why learn this
A fixed agenda saves planning time and makes the sessions predictable, so students arrive knowing what to expect. It also protects the most instructive part, the hands-on work, from being swallowed up by too much explanation.
Key concepts
🦺 Safe lab: batteries, soldering, and robotic arms
The real risks in a school robotics lab are few and well known: lithium battery (fire), soldering iron (burns and fumes), utility knife (cuts), motor and arm (pinched fingers). Set up zones in the room and agree on the rules during the first session, before opening any kit.
🌱 New here?
LiPo (lithium polymer) is the lightweight, high-power battery used in drones and robots; if punctured, swollen, or charged incorrectly, it can catch fire. 18650 is a cylindrical lithium cell. BMS is the small circuit board that protects the lithium battery from overcharging, over-discharging, and short circuits. NiMH are common rechargeable AA batteries, much safer to start with.
How to read this map: the pink zones are the risk areas (soldering, lithium charging, and the arm); the charging area glows because it’s the only one that must never be left unattended. The cyan zones are for regular work. The dashed outline around the arm marks the tape on the floor: no one enters that area while the arm is on.
✓ Workbench rules
- ✓Disconnect the battery while working with wires.
- ✓Keep the soldering iron in its stand; wear safety glasses and ensure ventilation.
- ✓Cut away from your body with a utility knife, on a cutting mat.
- ✓Test a new robot with it raised and its wheels off the ground first.
- ✓Tie back long hair and keep loose items away from motors and the arm.
✗ Never in the lab
- ✗Eat or drink at the electronics and soldering workbench.
- ✗Put your hand in the work area of an active robotic arm.
- ✗Connect a motor directly to the ESP32’s 3,3 V pin.
- ✗Leave the soldering iron on when no one is at the bench.
✓ Lithium batteries (LiPo and 18650)
- ✓Charge inside a fire-resistant bag, on a nonflammable surface.
- ✓Use a charger designed for lithium batteries, and always use a BMS with 18650 cells.
- ✓Store them half-charged, in a metal box or a dedicated bag.
- ✓Dispose of a swollen battery properly on the same day.
✗ Never with lithium batteries
- ✗Leave them charging unattended or overnight.
- ✗Puncture, crush, or bend the battery.
- ✗Connect the two terminals with a wire or tool (short circuit).
- ✗Throw them in the regular trash.
⚠️ For younger students, start without lithium
In T1 and T2, 4 NiMH AA batteries provide enough power for the rover without the fire risk of lithium. Save LiPo and 18650 batteries for groups that have learned the rules and for projects that need more current.
Why learn this
An accident involving a battery or soldering can bring robotics projects to a halt across the whole school. Clear zones and simple rules agreed on before opening the kit turn safety into a habit, and habits protect everyone when students are focused and eager to see the robot move.
Key concepts
📝 Project-based assessment: rubric and logbook
In robotics, written tests measure little. What shows learning is the working project e o the path to get there: the attempts, the mistakes, and the fixes. To do this, you use three tools: the project log (a record of each session), the rubric (clear criteria agreed on in advance), and the final presentation (the group shows the robot and explains its choices).
🌱 New here?
Rubric is a table that describes what the work looks like at each level for every criterion. Students know from the start what “proficient” means, and you assess their work by comparing it with the description, not with your impression. Logbook is the group’s notebook, on paper or digital, filled in at every session. Portfolio is a collection of project logs, photos, videos, and project code.
How to read this map: on the left, what the group produces at every session; in the middle, where it all comes together; on the right, where it becomes a grade. The dashed cyan arrow closes the loop: feedback from the rubric doesn’t end the project; it becomes the starting point for the next one.
Project rubric (copy and adapt)
| Criterion | 1 · Beginning | 2 · Developing | 3 · Proficient | 4 · Advanced |
|---|---|---|---|---|
| Functionality | The robot does not complete the task. | Completes it sometimes, with help. | Completes the task consistently. | Completes the task and handles difficult cases (lighting, curves, new obstacles). |
| Documentation | Log has gaps; no code saved. | Complete log, but it only describes what was done. | Log explains mistakes and solutions; code includes comments. | Another group can reproduce the robot using only the materials provided. |
| Teamwork | One person does almost everything. | Roles are assigned, but they don’t rotate. | Everyone takes on a role and can explain how the robot works. | The group helps other groups and resolves conflicts on its own. |
| Safety | Ignores the workbench rules. | Follows the rules when reminded. | Follows the rules without reminders. | Anticipates risks and suggests safety improvements. |
| Creativity | Copies the example without changing anything. | Changes values in the example. | Adds a feature of their own to the project. | Proposes and tests an original solution to a real problem. |
Add the levels (5 to 20 points) or use each row as a separate criterion. Give the rubric to the class at the project’s first session, not the last.
Goal: a project log template for the group to fill in at the end of each session (step 5 of the plan). It works on paper, in a shared document, or in a text file in the project repository.
# Logbook · Group <group name>
Project: <e.g., rover that avoids obstacles (1.6)>
## Meeting <number> · <date>
Roles today: builder <name> · programmer <name>
documenter <name> · tester <name>
Goal for the day: <what we wanted to get working>
What we did: <steps, in short bullet points>
What went wrong: <the symptom, as it appeared>
How we fixed it (or what we’ll try): <cause and fix>
Measurement or test: <Serial Monitor readings, table, video>
Safety: <any special precautions today?>
Next step: <the goal for the next meeting>
Question for the teacher: <if any>How to check
- ✓Every entry has a “what went wrong” and a “how we fixed it”: that’s where the learning happens.
- ✓Roles change from one session to the next.
- ✗“Everything went right today” in every session suggests the log was written to please someone, not to keep a record.
💡 A short presentation with the robot in hand
At the end of the project, each group makes the robot work in front of the class and answers three questions: “What was the hardest part?”, “What would you change?”, and “What can’t the robot do yet?” The third question shows who understood the project and who memorized it.
Why learn this
Assessing only the final robot rewards the group that got lucky with the kit. Assessing the process with a rubric agreed on in advance rewards those who investigated, kept records, and made corrections—the skills this course aims to develop. The rubric also protects you from requests to change grades: the criterion was written down from the start.
Key concepts
🤝 Inclusion and differentiation: simulation, roles, and challenges
Every class has different paces, levels of experience, and access to materials. The course provides three ways to address this: simulation for those without a kit (or while they’re waiting for one), group roles so everyone can participate, and extra challenges for those who finish early.
🌱 New here?
Wokwi simulates ESP32 boards, LEDs, sensors, and servos in the browser, for free; it works for almost all of T1 and much of T2. Gazebo is the robot simulator used with ROS 2: the robot, LiDAR, and environment exist only on the computer, and all of T4 can be done this way. MuJoCo does the same for the T5 arm.
How to read this map: the group’s robot stays in the center, and each role takes care of one part of the work. The cyan circle with arrows shows the rotation: in the next session, each person takes on the neighboring role. In a group of three, the documenter also takes on the tester’s role.
Half the class uses Wokwi while the other half uses the kits, then they switch in the next session. In T4, everyone starts in Gazebo; the real robot is used for the demonstration.
Anyone who finishes early can try the catch-up challenge or mentor another group. Anyone who falls behind can use the open session and study the module at home, at their own pace.
The course pages offer light, sepia, and high-contrast themes, plus adjustable text size (Appearance button). Every diagram has a text description for screen readers.
Without rotation, the student who already knows how becomes the regular programmer while everyone else watches. Make sure girls and shy students get to be builders and programmers, not just documenters.
✓ Make these distinctions
- ✓The same goal for the day, with challenges in steps for anyone who wants to go further.
- ✓Roles recorded by name in the journal and rotated at every session.
- ✓Simulation as a complete learning path, not a “punishment” for students who don’t have a kit.
✗ Avoid
- ✗Permanently dividing the class into “the good ones” and “the others.”
- ✗A group of five or more gathered around a single kit.
- ✗Waiting for everyone to finish before giving the next challenge.
Why learn this
Robotics often ends up being for students who already had access to electronics at home. Free simulation, rotating roles, and step-by-step challenges let students with no experience and no kit complete the project alongside everyone else.
Key concepts
🏆 Competitions, BNCC, and tracking student progress
Three things give the class’s work purpose and continuity: an external goal (a competition or showcase), alignment with the school curriculum (BNCC for Computing), and a simple way to see who is making progress, which the course provides in “My Journey.”
Competitions
Brazilian Robotics Olympiad: it has a theory division and a practical division with autonomous robots. The line follower from 2.6 and the rover from 1.6 are direct foundations for the practical division.
Teams build LEGO robots, develop an innovation project, and present their values. The kit is different, but the journal routine, roles, and rubric in this module work just as well.
Hands-on challenges for basic education students, with categories that accept robots built from freely chosen components.
For more advanced teams (technical schools and universities), with robot soccer, rescue, and service robot leagues. It connects with T3 to T5.
Rules, categories, and schedules change with each edition: always check each competition’s official website before planning for your class.
BNCC for Computing
The BNCC for Computing, the standard that brought computing into basic education, organizes the subject into three strands. The course covers all three, which helps justify the project in the school’s planning:
Breaking down the problem, creating algorithms, state machines (1.6, 2.4), PID control (2.3).
How sensors become data, how hardware runs code, networks, and protocols (1.4, 2.1, 3.5).
AI with limits and safety, privacy for voice processed on the robot itself, sharing, and documentation (5.1, 5.2, 5.6).
My Journey: tracking progress without a server
Every course page has buttons to mark as read e I have a question, and students can highlight passages and write notes. All of this appears in the dashboard My learning journey (button at the top of the page), with the completion percentage for each learning path, a list of questions, and “continue where I left off.” The key detail: this data is stored only in the student’s browser. There is no account, login, or server; no one, including you, can see anything the student hasn’t sent.
How to read this map: Progress is created and stored in the student’s browser (pink). It reaches you only when the student exports the file and sends it (steps 1 and 2); you open that file in an incognito window (cyan) to see that student’s journey. The dashed box marks the boundary: without a server, nothing is sent automatically and nothing is saved elsewhere.
Step by step: tracking a student’s progress
The student exports their data
They open My Journey, click “Export .json,” and get a file with a name like inema-robot-2026-10-17.json. Ask them to rename it with their name and group, because the file doesn’t include anyone’s name.
They send it to you
By email, through the school’s virtual learning environment, or on a USB drive. Set a regular time, such as the end of each project.
You import it in an incognito window
Open an incognito window (or a separate browser profile for this), go to the course, open My Journey, and click “Import .json.” You’ll see that student’s progress by learning path, read topics, questions, and notes.
Close and repeat
Closing the incognito window erases everything. Open a new one for the next student.
⚠️ Why use one window per student
The “Import .json” button sum adds the file’s data to what’s already in that browser (it doesn’t erase anything). If you import student A’s file and then student B’s in the same window, you’ll see a mix of both. If you import files in your regular browser, the students’ progress gets mixed with yours. Use a new incognito window for each file.
✓ What the file shows
- ✓Which topics the student marked as read (and therefore the percentage).
- ✓The questions they marked: a great outline for the next session.
- ✓The passages they highlighted and the notes they wrote.
- ✓Where they left off last time.
✗ What it does not prove
- ✗That the student understood: marking something as read takes one click.
- ✗Who the student is: the file has no name or login.
- ✗That the robot works: that is assessed through the rubric and presentation.
- ✗Nothing in real time: you only see what was exported.
💡 Use questions to plan the session
Ask students to mark “I have a question” while studying at home, then open My journey at the start of the session. Questions that come up repeatedly across groups can become the day’s opening topic. If students share a lab computer, ask each one to export their progress at the end and use their own browser profile so their progress does not get mixed together there either. The notes are written by the student: treat the files as personal data and do not publish them.
Why learn this
An external goal gives the class a deadline and a reason to work; alignment with the BNCC supports the project at school; and My journey gives you a picture of their study outside class, without a paid platform or registration. Knowing its limits helps you avoid drawing conclusions that the file cannot support.
Key concepts
✅ Module summary
To go further
- OBR · Brazilian Robotics Olympiad — rules, categories, and registration
- FIRST (FIRST LEGO League) — an international team program
- Wokwi — an ESP32 simulator in the browser for classes without kits
- Gazebo — a robot simulator used in Learning Path 4
- BNCC Portal (MEC) — the curriculum framework and its supplements
What now?
Go back to the start of the course, choose your class’s learning path, and complete its first module yourself before the first session.