A note on the name: “EduBot” is a working placeholder, not the project’s real name - I’m still working that out. This page will be updated once a real name is settled.

What it is

A robot designed to teach the fundamentals of robotics, built to be as low-cost as possible without sacrificing the quality of the learning experience. It won’t be the fastest, most precise, or most durable robot - that’s not the point. It’s aimed at a wide range of learners, from middle school through university, as well as hobbyists and maker/robotics enthusiasts.

Why I’m building it

EduBot is built around a few core objectives: low cost, no proprietary lock-in, and a modular design that can grow and adapt over time. There are already a number of low-cost robot platforms out there, but few manage to fulfill most or all of these objectives at once - many lack a real curriculum ecosystem, aren’t modular, are proprietary, or leave too much unstructured for a beginner to get started. EduBot aims to make thoughtful, comprehensive decisions about those tradeoffs.

The idea originated while mentoring a high school robotics team. Two things stood out to me. With around 20 students on the team, there was plenty for everyone to do while the robot was being built - but once competition season started, only a few students were needed to actually operate it. A low-cost robot that each student could own individually seemed like a natural way to keep the whole team engaged throughout the season, not just during the build phase. I also noticed that competition, in general, rewards mechanical engineering, integration-level electronics and software, and teleoperation very well, but leaves comparatively little room to explore autonomous operation in depth.

Cost and openness mattered too. Some required competition hardware is expensive and proprietary, which limits what teams - and individual students - can afford; my own team could only afford a single robot, which isn’t quite representative of how a real engineering team would work. That experience shaped EduBot’s focus on minimizing cost and avoiding lock-in to single-source components.

What started as an idea for one high school team quickly grew into something much broader. EduBot isn’t tied to any particular competition or set of rules, so students and hobbyists alike can explore whatever area of robotics interests them - from middle school through university, and for maker/robotics enthusiasts more generally.

Photos

View all photos

Design goals

  • Low cost - Basic configuration BOM cost is under $100; a fully loaded, ROS-capable configuration is around $300 - roughly a tenth the cost of comparable ROS-oriented educational robot platforms. This figure covers the robot’s own bill of materials only - the full-ROS configuration relies on an external computer (e.g. a laptop) connected over WiFi to run ROS2, and that computer’s cost isn’t included here.
  • Modular - built around a central controller board. Future versions may use a different microcontroller (e.g. RP2350) without redesigning the whole platform.
  • Multi-language, multi-platform - initially built on the ESP32, supporting C/C++ and MicroPython across Espressif IDF, Arduino IDE, and MicroPython development environments.
  • Scales across skill levels - block-based programming and game-like activities for younger learners; Micro-ROS support, with full ROS2 running on an external computer over WiFi, for higher education and more advanced users.
  • Curated openness - Custom hardware designs may eventually be open-sourced, deliberately staged to establish a stable, compatible foundation first. More on this approach →

Current status

I’m on the third prototype. All parts are laser cut - nothing is 3D printed. The motor brick design is complete, aside from minor changes still planned to the mounting hole pattern.

The main controller board is currently a soldered breadboard prototype, and it’s working well - nothing about it suggests any obstacle to achieving the full set of learning objectives. That said, not everything is implemented and tested yet; the camera, IMU, lidar, and Micro-ROS support are all still to come. What is working: two completely independent software implementations - one in MicroPython, one in C/C++ with FreeRTOS via the Espressif IDF - both demonstrating full closed-loop PID control of the wheels and teleoperation over UDP via WiFi.

Next step: produce the first functioning controller PCB, functionally identical to the breadboard version - no bodge wires or modifications needed to work correctly.

Once the controller PCB is functional, I’ll begin seeking outside help - mechanical, electronics, software, systems, and manufacturing engineering, as well as curriculum development and outreach/ promotion. It’s likely the PCB design will go through at least one more revision after that point, incorporating changes or improvements identified once others are actually using the board.

Construction methods will diversify from there too. Initial collaborators would receive laser-cut robots, but one early goal would be a 3D-printable version alongside it. Other construction methods could follow - cardboard, common household items, and others. After initial production for wider release, a version using a stamped or bent sheet-metal chassis is also a possibility.

Still outstanding before wider release:

  • Camera system selection and full integration
  • IMU integration
  • Lidar integration
  • Micro-ROS support

Once these are complete, the project will likely be ready for a wider release - full robots, kits, and individual parts - which is also roughly when open-sourcing the design might begin.

Further out, exploratory:

  • Balancing in a “wheelie” position
  • First-person-view camera feed to operator goggles (including designing the goggles)
  • An inexpensive R/C-car-style controller
  • NeoPixels and a speaker
  • Motor current sensing and battery voltage monitoring
  • A simple line-following accessory

Curriculum (planned)

ROS - University, advanced high school, or makers

Robot Operating System (ROS) is a framework providing a very capable set of software, libraries, and tools for implementing robots of many types. It’s very popular in universities and robotics research, and also used by some in industry and by robot enthusiasts.

Using Micro-ROS, Pico-ROS, or similar approaches to integrate a microcontroller-based robot into a full ROS2 ecosystem, EduBot would leverage ROS to enable related projects and education. Part of the curriculum would introduce ROS and provide a quick start to using EduBot with ROS. ROS has a relatively steep learning curve, so documentation that provides a reliable, proven way to get started is essential. A functioning, tested set of EduBot firmware, along with a Docker image for the main ROS computer, would likely be developed and maintained. Some basic ROS demos would be provided, such as using SLAM to map and localize within a new environment, coordinating multiple EduBots to work together (e.g. a simple drone show), and running EduBot in simulation.

Tutorials on robotics basics

Relatively standalone tutorials with relevant code examples, covering topics such as sensors and actuators, microcontrollers, programming languages, closed-loop control (servo systems, PID, etc.), kinematics, odometry, machine/computer vision, basic electronics (voltage, current, resistance, etc.), communication (serial UART, I2C, SPI, WiFi, Bluetooth, TCP/IP, Modbus, etc.), AI (LLMs, VLA, perceptrons, etc.), and batteries (chemistries, charging, BMS, etc.)

  • too much to list exhaustively, but using EduBot hardware, many fundamentals can be taught with practical lab exercises alongside lecture material.

Introductory programming for young learners

Block programming languages can be used with EduBot. One interesting approach could use physical blocks labeled with commands like “Move forward,” “Rotate clockwise,” “Stop,” or “Loop,” corresponding to typical blocks in the programming language. Each block would carry a QR code. The blocks could be physically arranged in sequence, then scanned using the robot’s camera to input the program. The program could then be executed directly, and/or exported to a computer for presentation or modification in a desktop application. The block language could translate into traditional programming languages such as Python or C, providing a bridge into those languages. Various programming challenges or projects would guide learning along the way.

Engagement for all ages

Complete, ready-to-run programs could provide robotics engagement and fun for their own sake - line-following robots, simple “battle bots” (each robot carries a balloon and a popping stick, drivers try to pop opponents’ balloons), first-person-view racing or maze-solving (robot camera feed to goggles), combat challenges, and more. Participants could also express creativity by building custom bodies that attach over EduBot, using craft techniques and materials like papier-mache, cardboard, and acrylic paints.

Get involved

Right now, what I’m most interested in is well-reasoned feedback - not quick gut reactions, but real thinking about what’s been presented here: what resonates, what doesn’t, what’s missing, what you’d change. Share your thoughts - I read everything, and the goal over time is for this to grow into a proper moderated discussion space as the project and its audience develop.

As the project moves through its roadmap, the kind of collaboration I’m looking for will shift with it - right now, reasoned feedback is what’s most valuable; later phases will call for mechanical, electronics, software, and manufacturing help, as described under Current status.

EduBot is also loosely connected to the employee-owned automation company I’m working on - it’s a plausible first product and source of revenue for that effort, though nothing here commits either project to that path.