I wanted to learn robotics by making one complete physical robot, not by stopping after a motor test or a sensor experiment. AMSAN started as a breadboard, loose wiring, motors, and a lot of separate parts that didn’t yet feel like one system.
Joining the phone and the robot
I used an Android phone for the face, voice, memory, games, and higher-level behaviour. An ESP32 handled the motors, sensors, arms, RGB ring, and physical safety. Getting those two sides to communicate reliably was a big part of the project.
Movement came first. I added front and rear obstacle sensing, edge detection, motor stops, and recovery behaviour before spending too much time on personality features.
Problems that changed the design
The servo arms caused brownouts, so I had to improve the power distribution and common-ground arrangement. The motor watchdog also exposed a timing problem: Android wasn’t refreshing active commands quickly enough. I changed the command timing and kept the watchdog instead of removing a useful safety layer.
Obstacle recovery was another difficult part. AMSAN could detect something and stop, but sometimes it stayed stopped or tried the blocked direction again. I eventually traced that to the way fresh distance data was clearing the recovery state too early.
Voice and audio
Voice conversation worked, but at first the sound came through the phone’s earpiece. That wasn’t useful for a robot. I changed the audio routing so it used media output and could return to the phone speaker when an external speaker was removed.
What I removed
Near the end, I experimented with camera and machine-learning features. The tests worked, but the complete app became less reliable on the physical phone. I removed camera and ML from V1.
That decision stayed with me. Adding another feature isn’t always progress. Sometimes the better engineering choice is to remove the part that makes everything else less dependable.
Freezing V1
AMSAN V1.0 is now a completed, frozen prototype. It combines movement, safety, an expressive phone face, arms, RGB, local games, memory, and intentional voice conversation. It also has clear limits, which are just as important to record as the features.