How to Teach School Students to Work in Design Groups Using Multi-Board Projects

Introduction

Imagine a classroom where students don’t just listen to a teacher but actually build a working robot arm — with multiple microcontrollers communicating in real time. This scenario is no longer a futuristic dream. According to a recent article on Habr, educators are increasingly turning to multi-board projects to teach school students the fundamentals of teamwork, system design, and collaborative problem-solving. The key idea is simple: instead of having each student work alone on a single microcontroller, you split a complex project across several boards — each handled by a different student or small team. This forces students to negotiate interfaces, share data, and debug integration issues together.

Multi-board projects mimic real-world engineering, where products are rarely built by one person. They teach students how to coordinate, divide labor, and communicate technical decisions. In this guide, I’ll walk you through how to design and implement such projects in a classroom setting, based on practical cases and proven methods. You’ll learn how to choose hardware, structure group roles, avoid common pitfalls, and assess student collaboration — all while keeping the experience engaging and educational.

Why Multi-Board Projects Work for Teaching Design Collaboration

Traditional robotics or coding classes often give each student a single Arduino or Raspberry Pi. The result: students work in isolation, focusing only on their own code. They rarely need to discuss architecture or agree on data formats. Multi-board projects change that. When a project requires two or more boards to communicate — say, one sensor board sends data to a motor controller — students must define a protocol, handle timing, and test integration. This mirrors how real engineering teams operate.

A research paper from MIT’s Lifelong Kindergarten group (Resnick et al., 2009) emphasizes that collaborative constructionism — learning by building together — is more effective than individual tasks for developing systems thinking. Multi-board projects naturally create opportunities for peer teaching, negotiation, and shared debugging. Teachers report that students who struggle with solo coding often thrive when they have to explain their part to a teammate.

Step 1: Define a Multi-Board Project That Requires True Collaboration

Choose a project that cannot be done on a single board — at least not easily. Examples from the Habr article include:

• Distributed weather station: One ESP32 collects temperature and humidity from a sensor, another ESP32 reads wind speed from an anemometer, and a third ESP32 aggregates data and displays it on an OLED screen. Each board communicates via I2C or serial.
• Multi-robot coordination: Two or more Arduino-based robots that must synchronize movement to carry a load. Each robot has its own motor driver and ultrasonic sensor, but they share a common goal via wireless (nRF24L01 modules).

Make sure the project has a clear system diagram. Students should see how data flows between boards. The teacher can draw a block diagram on the whiteboard before any coding begins.

Step 2: Assign Clear Roles and Interfaces

Divide the class into groups of 3–4 students. Each group is responsible for one board. Define explicit interfaces between boards — e.g., one board must send a JSON string over UART at 115200 baud, with a specific message format. Provide a simple interface contract in a shared document:

{
  "type": "sensor_data",
  "temperature": 25.3,
  "humidity": 60.1
}

Students must adhere to this contract. If someone changes the format, all groups must agree. This teaches version control and API thinking — skills rarely taught in standard curricula.

Step 3: Use a Common Communication Protocol

For simplicity, start with wired serial (UART) between boards. Later, introduce wireless (ESP-NOW or nRF24). The Habr article highlights a case where students used I2C with a shared bus — but caution is needed because address conflicts can cause frustration. In my experience, UART is easier to debug because each connection is point-to-point.

Example code stub for sending data from sensor node (ESP32):

#include <HardwareSerial.h>

HardwareSerial mySerial(2); // Use UART2

void setup() {
  mySerial.begin(115200, SERIAL_8N1, 16, 17);
}

void loop() {
  float temp = readTemperature();
  float hum = readHumidity();
  mySerial.print("{\"type\":\"sensor_data\",\"temperature\":");
  mySerial.print(temp);
  mySerial.print(",\"humidity\":");
  mySerial.print(hum);
  mySerial.println("}");
  delay(2000);
}

The receiving board parses the JSON and acts accordingly. Students quickly learn that if the JSON is malformed, the system breaks — a powerful lesson in data integrity.

Step 4: Integrate Incrementally — First in Simulation, Then on Hardware

Before connecting real boards, use a simulator like Wokwi (wokwi.com) to test individual modules. Each student group can simulate their part and verify the output format. Then, physically connect the boards. This two-step process reduces hardware debugging time and builds confidence.

A real case from a school in Germany (documented in the Habr article) involved 8th graders building a smart greenhouse. They spent two weeks simulating each sensor and actuator on Wokwi, then one week integrating on actual ESP32 boards. The teacher reported a 40% reduction in integration errors compared to previous cohorts who went straight to hardware.

Step 5: Teach Debugging as a Team Sport

When the system doesn’t work, students often blame each other’s code. Turn this into a learning opportunity. Introduce a “debugging protocol”:

1. Each group checks their own board’s output in isolation (using a serial monitor).
2. If the output is correct, they send a test message to the next board.
3. The receiving group uses a logic analyzer or serial monitor to verify the incoming data.
4. If data is missing or corrupted, they check wiring, baud rate, and voltage levels.

This systematic approach mimics industrial debugging. It also teaches patience and respect for teammates’ work.

Step 6: Assess Collaboration, Not Just Technical Output

Traditional grading focuses on whether the code compiles or the robot moves. In multi-board projects, assess teamwork separately:

• Did the group document their interface contract?
• Did they communicate changes to other groups?
• Did they help debug another group’s issue?

Use a simple rubric: each student submits a one-paragraph reflection on what they learned about collaboration. Teachers can also observe group dynamics during integration sessions.

Common Pitfalls and How to Avoid Them

• Pitfall 1: One student dominates. The teacher should rotate roles mid-project. For example, after two weeks, sensor group members swap with motor group members.
• Pitfall 2: Interface mismatch. Require groups to test their interface with a “fake” partner board before integration. Provide a simple test harness.
• Pitfall 3: Power issues. When multiple boards share a power supply, voltage drops can cause resets. Use separate USB power banks or regulated supplies.
• Pitfall 4: Overcomplexity. Keep the initial project small. A two-board system with one sensor and one actuator is enough for a first attempt.

Real-World Case: The Distributed Traffic Light System

A high school in Singapore implemented a multi-board traffic light project for 10th graders. Four groups each controlled one intersection with three LEDs and a push button. The intersections had to coordinate to create a green wave. Students used ESP-NOW for wireless communication. The project took six weeks, and the teacher noted that students learned more about timing, acknowledgments, and retransmission than any textbook could teach. The source article on Habr provides full details: Source.

Tools and Resources for 2026

• Hardware: ESP32 boards are still the most cost-effective choice (around $5 per board). Arduino Uno R4 WiFi is another option with built-in Wi-Fi.
• Simulation: Wokwi (free) supports multi-board simulation with virtual UART connections.
• Learning platforms: ASI Biont supports connecting to ESP32 and Arduino boards through API — detailed at asibiont.com/courses. This allows you to log student project data, monitor progress, and even trigger automated tests.
• Curriculum: The Raspberry Pi Foundation offers free lesson plans for multi-board projects in their “Physical Computing” course.

Conclusion

Multi-board projects are a powerful tool for teaching school students how to collaborate in design teams. By forcing students to divide a complex system into parts, define interfaces, and debug together, you build skills that are directly transferable to real engineering careers. The approach is scalable — from simple two-board sensor networks to multi-robot coordination systems. Start small, use simulation, and emphasize communication over coding speed. The results will surprise you: students who once dreaded group work become the ones asking to do more.

For a deeper dive into specific project examples and code, check the full article on Habr. And if you want to track your students’ progress through APIs, explore how ASI Biont can help connect their boards to a central dashboard.