We are developing a simple, programmable robot buggy designed to make robotics accessible to a much wider audience. The core idea is to replace traditional text-based coding with tangible, tile-like objects that represent commands and actions. By arranging these tiles in sequence, users can create programs without needing prior programming knowledge. This approach lowers barriers to entry, supports inclusive learning, and empowers individuals, especially those with learning disabilities or limited technical experience, to engage creatively with robotics. Our goal is to transform programming into an intuitive, hands-on activity that fosters participation, exploration, and confidence.
The buggy is a modified Cybot (which stems from around 2001) and adapted to use an Arduino Uno R4 Wifi microcontroller. The big grey box underneath the Uno is the rechargeable battery:
This project aims to democratize robotics education by creating a simple, programmable robot buggy that can be controlled using tangible, tile-like objects instead of traditional text-based coding. The core concept is to design a physical programming system where each tile represents a specific command or action, such as ‘move forward’, ‘turn left’ or ‘pause’. Users can arrange these tiles in sequence to form a program, which the robot interprets and executes. This approach removes the cognitive and technical barriers often associated with conventional programming, making robotics accessible to individuals with diverse abilities, including those with learning disabilities or limited digital literacy.
The system will integrate a robust yet intuitive interface that translates tile arrangements into executable instructions for the robot. By leveraging inclusive design principles, the project seeks to foster creativity, problem-solving, and confidence among users who might otherwise be excluded from STEM activities. The tangible programming paradigm encourages hands-on engagement, collaboration, and experimentation, transforming programming into an approachable and playful experience.
Ultimately, this project envisions a platform that can be used in educational settings, community workshops, and maker spaces to promote equitable participation in technology. By bridging the gap between physical interaction and computational thinking, the robot buggy serves as a stepping stone toward a more inclusive future in robotics and programming.
The body of the Robot Buggy is based loosely upon the robot ‘tortoises’ by Grey Walter (with a little modification to the body shape and the addition of a speaker:
First Steps
The first step in this process is a robot that receives simple forward, left, right and stop commands via a hand-held bluetooth controller. Pressing a button on a controller moves the robot a fixed distance. This has some advantages in that it provides:
Immediate Feedback: Pressing a button and seeing the robot move a fixed distance creates a clear cause-and-effect relationship, which is fundamental to understanding programming logic.
Discrete Actions: Each button corresponds to a single command (forward, left, right, stop), which mirrors the idea of individual instructions in a program.
Sequencing: Even though the user is pressing buttons manually, they are effectively creating a sequence of actions. For example, forward, then turn, then stop. This helps build the mental model of how instructions combine to form a program.
Scaffolding: Starting with direct control via Bluetooth provides a low-barrier entry point. This can then be followed by providing tiles that represent these same commands, reinforcing the concept of sequencing without overwhelming the learner.
This approach is very much aligned with constructivist learning principles – learners first experience the concept physically, then abstract it into symbolic representation (tiles), and eventually into digital or text-based programming.
Bluetooth Control
Not the easiest thing to program, especially when using two distinctly different microcontrollers using two different programming languages and different bluetooth libraries. The first problem here was figuring out which of the devices, using bluetooth terminology, has the role of ‘central’ and which should be ‘peripheral’. A little research on the web gave some answers, and this is what I found out.
In Bluetooth Low Energy (BLE), the roles of central and peripheral are about who initiates the connection and who advertises availability:
Peripheral: This device advertises its presence and waits for a central to connect. Typically, peripherals are simpler, low-power devices like sensors.
Central: This device scans for peripherals and initiates the connection. Centrals usually have more processing power and act as the ‘controller’.
So the robot itself will act as the ‘central’ device, whilst the controller will be designated as a peripheral.
The controller is a simple four button circuit board connected to a Rapberry Pi Pico 2 W and powered by a tiny Lipo battery with USB charger:
It communicates with the Robot Buggy by sending simple integer values as instruction codes: 1: Turn right, 2: Go forward, 3: Stop, 4: Turn left. We’ll use a minimalistic protocol where each command is a single character sent over Bluetooth:
2 → Move forward a fixed distance (e.g., 10 cm)
4 → Turn left by a fixed angle (e.g., 90°)
1 → Turn right by a fixed angle (e.g., 90°)
3 → Stop immediately
This keeps communication lightweight and easy to parse on both devices.
The simplified robot interface will be trialled by non-programmers by constructing simple sequences of instruction to move the robot around an obstacle course fro a starting location to a given target location.