I built the A.R.C. Personal Command Terminal as my final project during Columbia University Pre-College’s Arduino Fundamentals: Programming and Hardware Essentials course from August 3–7, 2026.
The finished system used an Arduino UNO R4 WiFi with an MFRC522 RFID reader, I²C LCD, OLED display, Bluetooth, red and green LEDs, audio output, and a custom phone app named ARC-Terminal.
The useful part of the project was not that every idea worked. It was learning which idea to stop defending.
The input problem
I initially explored keypad and MPR121-based input. In the neat version of the story, that method would have worked and the rest of the project would have progressed in a straight line.
It did not. Continuing to debug it would have protected the plan at the expense of the project, so I moved remote input into the phone app through Bluetooth.
Memory becomes a design constraint
Once several modules, displays, and sound were competing inside one system, flash-memory limits became a problem. Audio had to be reduced and tested alongside the rest of the code.
Sound, LEDs, compile issues, and module integration did not fail one at a time. I learned to isolate one signal, confirm it, and then add the next part without assuming the previous success would survive.
The final version
By the end, RFID, displays, Bluetooth input, the companion app, LEDs, and audio worked together. I am proud of the finished object, but more interested in the path to it: several approaches had to be changed or simplified.
The course connected software to physical constraints in a way a normal app rarely does. Wiring is visible. Memory is finite. A module either responds or it does not. That made every architectural decision unusually concrete.