Written in Front

• • What is Arduino used for

• • We understand that it is used to reduce complexity and help us better connect different devices

• • Before it, there were various boards, but they were too difficult for ordinary people

• • What is the relationship between the R4 board and the servo

• • A servo is just an ordinary peripheral, a flowing device with a solid board

• For most people, writing a Python program is as difficult as making an app

• • Where is the bottleneck in AI programming

• • If the error message is something AI has never encountered

• • If the programming language is unfamiliar to it

• • If we ourselves don’t know what to do

This unexpected experience, last month in programming, I basically had very little personal input, completely let AI take the lead, high efficiency, good results. In recent days, past thoughts and experiences have slowly resurfaced, and the desire to participate has increased a lot, but the results have also become more unsatisfactory. This also confirms the previous idea about how to get along with AI, letting go of arrogance and relinquishing power. At a certain stage, there will be a strong desire to participate, but in reality, this is futile, and we need to find a better way.

Project Background and Origin

In the first half of the year, among AI hardware, different from AI Pin’s “small gadgets,” a desktop pet—LOOI emerged. With the support of AI, it can move freely on the desktop, capture actions, recognize faces, occasionally throw a tantrum, and sometimes enhance the atmosphere between couples. Its emotional value is indeed provided, and technically, it has indeed made quite a splash.

Far across the ocean, the self-proclaimed liberal arts major robot master—Garman (overly modest), keenly captured its companionship value as an emotional support in modern fast-paced life. In countless shares, he emphasized this point, which is rarely seen among technical people.

Then, the price of over 1500, for many people, the inner monologue is probably: I! Have no emotional demand, none!

Garman began to self-learn Python, self-learn Arduino programming, self-learn robot development. After countless attempts, he managed to drive the price down to less than 200, achieving LOOI’s freedom. What is commendable is that afterwards, he selflessly contributed his results and shared in the community. In no time, it became a hot commodity, almost everyone had a set of equipment. However, the threshold is not low. After listening to the sharing, a casual hiccup could lead to another R4 board gathering dust at home.

During this AIPO university event, based on the experience of AI programming co-learning, I made an installation tutorial for Arduino (because at that time I thought this was the main development tool), and fortunately became Garman’s assistant. Under the teacher’s watchful eye, I watched helplessly as the wires were plugged in incorrectly, not knowing how the students in the live broadcast were progressing.

After returning, I thought:

• • Is Arduino supposed to be written in assembly language?

• • What role does Python play in this?

• • Why can’t Android phones work, only iOS can?

• • What does flashing mean?

• • As an experienced productivity tool user, I hope to solve the problem of writing down the serial number.

With these questions, I began this journey, and the current results are roughly like this:

• Currently, there are still 2 unresolved issues:

• • How to link with the phone and send messages

• • Camera following

If interested friends leave a message in the backend, I’ll pull you to the GitHub repository to tinker and improve together.

Source Code Analysis, Interaction Logic Between Devices

Before this practice, I had no experience with Arduino operation and knew nothing about hardware. My understanding of wiring was still at the software level, which is indeed a completely different field.

Analyzing Existing Code Logic—Claude

This part is mainly implemented with Claude, below is the core logic from Teacher Garman

Honestly, the last time I saw this diagram was half a year ago, thinking it shouldn’t be too difficult, just 3 files, I could probably manage it, but I ended up chewing on it for half a year with no progress. This time, with Claude’s help, I finally had some insights.

For hardware parts, please refer to Teacher Garman’s co-learning video. Search Garman in the waytoagi knowledge base.

Overall Logic

Based on the original diagram, I reorganized a timing diagram, and from the arrows below, you can roughly see the flow of information. The process of each session is roughly as follows:

• • Start 2 programs on the computer, which are chat and head. Start face on the phone

• • Input information in chat, it will tell AI, and AI will give a sound and an emoji

• • Then chat sends it to the phone, after the face on the phone receives this information, it plays the sound and displays an emoji

That’s it. Then we look at head, its role is to constantly capture the camera, analyze the characters’ actions, and adjust the servo.

Another version of the flowchart

Internal Logic of 3 Modules

Head (Runs on Computer)

Face (Runs on Phone)

Chat (Runs on Computer)

So far, the logic of the entire robot software part has been sorted out. The principle of AI programming is to avoid programming if possible, but unfortunately during the live broadcast, it worked, but when I got home, it just wouldn’t work. I wondered if I could write it without Python? Could it be done with nodejs?

What I Hope to Achieve

• • First, I hope to have a UI interface, trying to avoid opening the command line

• • Secondly, all configuration information should be extracted for easy switching later

• • It would be best to see some intermediate processes to facilitate problem locating

Start Modifying

After more than 50 sessions, I roughly figured out its logic

What is the Relationship Between the Servo and the Board and Arduino?

To facilitate troubleshooting whether the board is successfully connected to the computer and whether it can control the servo normally, I thought of a way to let AI help write a small program for testing. It was also through this experience that I understood the logic behind it.

Arduino Code

#include <Firmata.h>
#include <Servo.h>
  
Servo myservo; // Create servo object
int servoPin = 9; // The pin the servo is connected to
int minAngle = 0; // Minimum angle
int maxAngle = 180; // Maximum angle
int delayTime = 1000; // Delay time after each movement (milliseconds)
boolean isRunning = true; // Control whether the servo is running

void setup() {
Firmata.setFirmwareVersion(FIRMATA_FIRMWARE_MAJOR_VERSION, FIRMATA_FIRMWARE_MINOR_VERSION);
Firmata.attach(ANALOG_MESSAGE, analogWriteCallback);
Firmata.begin(57600);
myservo.attach(servoPin); // Attach the servo object to the specified pin
Serial.begin(9600); // Initialize serial communication for control
Serial.println("Enter 's' to stop the servo, enter 'r' to restart the servo");
}

void loop() {
while(Firmata.available()) {
Firmata.processInput();
}

// Check serial input
if (Serial.available() > 0) {
char input = Serial.read();
if (input == 's') {
isRunning = false;
Serial.println("Servo has stopped");
} else if (input == 'r') {
isRunning = true;
Serial.println("Servo has restarted");
}
}

if (isRunning) {
// Move the servo to the minimum angle
myservo.write(minAngle);
delay(delayTime);
// Move the servo to the maximum angle
myservo.write(maxAngle);
delay(delayTime);
}
}
  
void analogWriteCallback(byte pin, int value) {
if (pin == servoPin) {
myservo.write(value);
}
}

It needs to be executed in the Arduino IDE

Node Code (arduino_servo_control.js)

const { SerialPort } = require('serialport');
const { ReadlineParser } = require('@serialport/parser-readline');
  
// Replace with your serial port name (e.g., COM3 or /dev/ttyUSB0)
const port = new SerialPort({ path: '/dev/cu.usbmodemF0F5BD543E182', baudRate: 9600 });
const parser = port.pipe(new ReadlineParser({ delimiter: '\n' }));
port.on('open', () => {
console.log('Serial port opened');

// Send command to move the servo to the specified position (e.g., X: 45 degrees, Y: 135 degrees)
const position = '45,135\n';
port.write(position, (err) => {
if (err) {
return console.log('Error on write: ', err.message);
}
console.log('Command sent: Move to position 45,135');
});
});
  
port.on('error', (err) => {
console.log('Error: ', err.message);
});
  
parser.on('data', (data) => {
console.log('Received data from Arduino: ', data);
});

When running, you first need to install the dependencies, then run

 npm install serialport
 node arduino_servo_control.js

The final execution result is as follows:

What kind of logic is it? Actually, the board is in a dead loop waiting for messages

The information I currently understand is roughly like this.

My current understanding is roughly as follows:

• • The purpose of the Arduino board is to simplify the difficulty of dealing with different devices

• • It helps us do a lot of interfacing

• • It acts as a transfer station

• • Only one program can run on Arduino at a time, each upload overwrites the previous one

• • So there is no concept of version

• • There is also no situation of interference between different programs

Of course, this is just our understanding, but it has opened a window, laying a foundation for the simple test code above.

Overall Program Architecture Analysis

Based on the previous interface logic, with Claude’s help, I quickly wrote a client program. The reason for choosing a client program instead of a webpage is that it needs to interact with hardware, and permissions in the browser are limited. This point was also mentioned in the initial interaction with Claude.

The chosen client program architecture consists of a JavaScript interface display and Rust hardware control. Don’t be fooled by these two terms, they are all codes written by AI, we just copy and paste, and when there’s an error, we ask it to fix it because, honestly, we don’t understand it!

This structure may seem complicated, but if we get confused, we can just tell AI what files we should have and ask it to give us the latest file structure.

This process is a typical physical labor, filled with endless frustration, lacking any aesthetic value, and aside from losing a few more hairs, there’s hardly any gain.

During the process, some errors repeatedly occurred because changes would break things, but it was impossible to understand its logic, so I could only keep asking AI.

Difficulties and Insights Encountered

Origin

The motivation for this project originated from the fact that it has been dragging on for over half a year, and I wanted to produce something. Additionally, Garman had taught me step by step, and I still hoped to make it. Another reason was to lower its difficulty a bit so that cloud desktops could intervene in this scenario, trying to simplify the software part.

Hardship Experience – 5 Days of Hellish Life

This project lasted for 5 days, but it was not ultimately completed. In fact, the current amount of code has far exceeded the initial Python version, and if everything were implemented in Python, it would probably be much simpler and more efficient.

The most time-consuming part was about the camera capture. The Python version used OpenCV, and the facial recognition part did not use external content.

However, after switching to Rust and Node.js,

• • The OpenCV for Rust is not supported on our Mac, requiring self-compilation

• • Compiling requires the CMake tool, so I had to install CMake first, but the pkg package method couldn’t install it

• • So I had to compile and install CMake, and to compile it, I had to install LLVM

• • However, when installing LLVM via brew, it kept throwing errors

• • So I switched to MacPorts to install them

• • Finally, LLVM was installed, but it couldn’t compile the OpenCV version

• • The reason was that the Mac version was too low; OpenCV required installation via brew to be before January 2024

• • As a result, I changed the OpenCV source code version more than 10 times, and each compilation took over half an hour, mostly failing at around 60%

• • Asking Claude about this error was also futile, which was very frustrating

Fortunately, after a sleep, I looked back at the goals I communicated with Claude, which were to achieve face capture. After understanding the Arduino principles, I decided to let go and focus on solving the TTS and servo control issues. During this process, I encountered the situation where Firmata was not well supported in Rust.

So I adopted the Serial Port communication method, abandoning Firmata, which allowed me to understand the principles of the Arduino board. With AI’s help, I completed this part of the code.

Once all these contents were completed, I returned to solve the camera issue, and I felt much calmer.

Next Thoughts

First, I still want to complete Teacher Garman’s content, noticing that the mobile end opens a port listener. In this case, we can consider:

• • Opening a listener task through an app, because with Claude’s help, writing an app and writing a Python script is equally challenging for most people

• • Through a webpage, presenting emojis and playing audio, the content can be dynamically polled or long-connected.

• • Our desktop program sends information to that webpage

In this way, the next co-learning through cloud desktops will lower the difficulty even more.

Gains and Insights

This experience was mostly completed with the help of AI, but for deep-level problem troubleshooting and optimization, I must say that it still relied on some past experiences, although not much, but still present. I can roughly sense where issues might arise.

Although the code is still incomprehensible due to the complexity of Rust syntax, and the JavaScript related to Rust is not much simpler. Overall, I have a basic concept of the layout of files and other aspects.

We hope to use this case to illustrate that AI programming greatly reduces difficulty, but it has not met our expectations. Being a complete novice is not easy; although the possibility is very low, it is not zero. We still hope to contribute some strength to reduce the difficulty in this area.