Representative case study · Arduino Remote Studio

How a Dhaka STEM club drove 14 Arduino robots in one workshop — without anyone writing app code

The club — we'll call it the "Dhanmondi Maker Circle" — runs a Saturday robotics track for students aged 13–17. About 30 active members, two volunteer instructors, both engineers at day jobs. The room is the back of a coaching centre off Road 27, with eight long tables, mediocre wifi, and a power-strip situation that would make an electrical inspector weep.

The signature event each term is "Robot Saturday": every student team gets a chassis kit, an Arduino UNO, two DC motors, an L298N driver and an HC-05, and by 4 p.m. their bot has to make it through a tape-on-the-floor course. The hardware side has been running smoothly for two years. The controller side hasn't.

The problem the instructors had given up on

The course of a typical Robot Saturday, before this term, looked like this:

• 10:00 a.m. — Hardware assembly. Goes well. Kids love wiring things.
• 11:30 a.m. — Arduino sketch. Most teams get through it with help. By 12:30, sketches compile.
• 12:30 p.m. — Lunch. Plus the "controller app" problem.
• 1:30 p.m. — The controller app problem.
• 3:55 p.m. — Five minutes left. Maybe four robots running.

The lead instructor — call him Saif Bhai — had tried roughly everything to solve the controller problem:

1. Recommend a free Play Store "Arduino Bluetooth Controller". Every term, two or three apps that had worked last term were either gone, ad-saturated, or no longer compatible with the version of Android the kids' phones ran. About a third of students always ended up on incompatible apps.
2. Pre-flash a "club controller" APK. Saif Bhai spent a weekend building one in Android Studio in 2024. It worked. Then Android 14 changed Bluetooth permissions, the APK silently broke on newer phones, and rebuilding it for every Play Services update became a second job.
3. Teach app development as part of the workshop. Briefly considered. Discarded: a Robot Saturday cannot also be an Android Studio Saturday. The room would lose four hours and the bots wouldn't move.

By early 2026, the practical compromise was painful: students drove robots with whatever fixed-layout app happened to work on their phone, and the lesson on "designing your own controller" never happened. The kids who finished early just sat around watching the kids whose apps had crashed.

The first Robot Saturday with a no-code remote

Saif Bhai found Arduino Remote Studio on a Reddit thread about HC-05 alternatives and ran a pilot on two teams the Saturday before the main event. Both teams had their robots driving in about 20 minutes. He restructured the next workshop around it.

9:45 a.m. — Setup, before students arrive

The instructors pre-installed the app on the two demo phones and exported a "Club Starter" template: joystick, slider, big red Emergency Stop, battery gauge bound to BATT. They put the .json file in a shared WhatsApp group titled "Robot Saturday Files". One file, 4 KB, that any student phone could import in seconds.

This is the small choice that made the rest of the day work. Without a shareable template, every team would have built a different layout from scratch and the instructors would have lost half their time troubleshooting widget configs.

10:00–11:30 a.m. — Hardware (unchanged)

Same as always. Chassis, motors, driver board, HC-05 wired to pins 10/11 via SoftwareSerial. The senior teams help the new teams. Two robots are wired backwards; one HC-05 won't pair because someone held the AT-mode button while powering on. Standard.

11:30 a.m.–12:30 p.m. — Sketch

Saif Bhai gave out a single sketch on a USB stick. It reads commands of the form X:{x},Y:{y} from the joystick and SPEED:{value} from the slider, plus a one-letter S for the Emergency Stop. It also prints back BATT:{percent} every second so the in-app gauge has something to display. Total: about 80 lines including comments. The students typed in their own pin numbers and uploaded.

12:30–1:00 p.m. — Lunch (the controller problem doesn't happen)

The instructors made every student do one thing before eating: open the app, import the Club Starter template from the WhatsApp group, and pair their phone with their HC-05. The pair step is the only one with friction — three Android 14 phones needed permission dialogs unblocked in Settings. Two students were on Xiaomi devices that needed Bluetooth privacy permissions re-toggled. All 14 phones were connected by 1:05.

1:00–2:00 p.m. — First drive, on the table

Each robot drove on its own table first, wheels in the air, while the team checked which direction the motors were spinning. About six teams needed to flip a motor wire because their L298N was wired with the channels swapped. This was the same problem they always had, but it surfaced 90 minutes earlier than usual because the controller wasn't blocking it.

2:00–3:30 p.m. — Course time

Robots went on the floor. The instructors stopped trying to manage 14 simultaneous controllers; they just refereed the course. Two robots had genuine joystick mapping bugs (sign of Y flipped on one team's sketch). One Bluetooth disconnect mid-run was caught instantly by the in-app failsafe — the robot stopped 30 cm short of a table leg, and the team learned about why the failsafe matters more durably than they would have from a slide.

3:30–4:00 p.m. — The bit that didn't used to happen

With 14 robots running and 30 minutes left, Saif Bhai ran an unplanned exercise: customise your controller. Three teams added a horn button (mapped to a piezo). Two added a "spin in place" macro that fired two motor commands in sequence. One added a slider for servo angle and used it to wave an arm at the audience. None of this needed a new APK. The point of the workshop — "you can shape the tool to your project" — landed for the first time in eight terms.

What changed (numbers)

• Robots driving by 4 p.m.: ~4 / 14 → 13 / 14. The fourteenth team had a snapped motor wire on the chassis, not a controller problem.
• Instructor time spent on controller troubleshooting: ~2 hours per Saturday → ~25 minutes. The bulk of remaining time is Android Bluetooth permissions, not the app itself.
• Students who left having designed something (not just driven something): 0–2 / Saturday → 7 / 14. Adding a horn or a macro counts.
• Saturdays that overran past 4 p.m. because of "the app problem": about every third → zero so far in the new term.
• WhatsApp messages from parents at 5 p.m. asking why their child wasn't home yet: anecdotally, dropped to roughly none.

"The controller used to be the thing that ate the afternoon. Now it's the thing we use to start a project the kids actually want to extend."
— composite reflection from the lead instructor

The four details that made this work

1. One shared template, distributed before the day started

Building a controller from a blank canvas in a classroom of 14 teams would have replaced the Android Studio problem with a "where do I drop the joystick" problem. A single .json template, pre-tested by the instructors, removed that. Customisation happened after a working baseline existed — which is the correct order.

2. A standard payload format committed to in the sketch

Because the sketch shipped to all teams used the same command keys (X, Y, SPEED, S, BATT), one template fit every team. When a student wanted to add a custom widget, they only had to add one else if branch to their sketch — they didn't have to redesign the controller protocol from scratch. The shared vocabulary is what made the customisation step quick instead of intimidating.

3. The Emergency Stop and failsafe were on by default

The instructors had previously banned anything heavier than a 200 g robot on the floor course. The reason was a real incident in 2024 — a robot at full throttle drove off a table and a soldering iron stand. With a per-template Emergency Stop and a disconnect-failsafe that fires S automatically, the weight ban came off for this workshop. It hasn't needed to come back.

4. The instructors stopped owning the controller layer

The hidden win, only visible in retrospect, is that Saif Bhai is no longer the maintainer of a private APK. He doesn't need to rebuild for Android 15 in October. He doesn't need to apologise to a student whose phone is on an OEM Bluetooth stack he's never tested against. That weight off his evening is the reason the club is now planning a second weekly track.

What we'd do differently next time

1. Run a 10-minute Android Bluetooth permissions clinic at the very start

The 25 minutes still spent on controller troubleshooting is almost entirely Android 12+ Bluetooth permission prompts on certain OEMs (Xiaomi, Realme, Oppo). A scripted "open Settings → Apps → Arduino Remote Studio → Permissions → Bluetooth scan + connect → Allow" walkthrough at 11:00 a.m. would drop that to zero.

2. Pre-pair the HC-05 modules at the kit-prep stage

Eight of the 14 teams' HC-05 modules came out of the box with default name HC-05 and PIN 1234. Instructors had pre-renamed two of them and forgotten the rest. Renaming each module to BOT-01 through BOT-14 at the start of the term would have made "find your robot in the Bluetooth list" a non-event.

3. Show the import/export step on day one of the term, not workshop day

Several teams hadn't realised they could save their own customised layout and re-import it next Saturday. Treating the template file as a first-class artefact — the way you treat a sketch .ino — would let students build up a controller across multiple workshops.

The transferable lessons for any STEM workshop

This club's situation is specific. Three things generalise to any robotics or microcontroller workshop:

1. Keep the tool stack as flat as possible. Every additional layer (Arduino IDE, Android Studio, a vendor configurator, a flashing utility) is a chance for a student's environment to break in a way the instructor didn't predict. A no-code controller removes an entire layer.
2. Ship a working baseline before asking anyone to customise. "Build your own controller from scratch" is intimidating. "Open this layout and add one button" is approachable. The difference is whether students see customisation as a creative act or as homework.
3. Build safety into the template, not into the rules. An Emergency Stop button on the layout is taken more seriously than a paragraph in the workshop handbook. So is a failsafe that fires automatically when Bluetooth drops.

For instructors looking at the broader research on what actually makes school-age technical workshops effective, UNESCO's digital education resources are the canonical free starting point — the failure modes they catalogue (cognitive overload, tool friction, inequitable device access) line up surprisingly well with what this Dhanmondi club had been quietly battling on Saturday afternoons.

Arduino Remote Studio was built specifically to take the controller layer off the instructor's plate. The workshop above is one of several Dhaka clubs running it this term — quietly, on their own terms, without losing what already worked about Saturday robotics.