Small robot-car kits are excellent for the first few hours. Screw on the motors, connect an ultrasonic sensor, load a line-following sketch and, with luck, something finally crosses the room without diving under a piece of furniture.
Line following eventually stops being enough. One option is to discard the beginner car and rebuild something more ambitious; Iulia instead asks whether the same machine can grow without returning to a bare chassis.
Iulia's project, featured by Arduino, takes the second route. The starting point is an entry-level Elegoo kit controlled by an Arduino UNO Rev3, with its motor shield and a few sensors. She removes the Rev3, fits an UNO Q onto the same headers, moves the shield across, restores the motors and original functions, then adds a USB webcam and App Lab's Face Tracking Brick.1
At the end, the little car turns to keep a face near the centre of the image and drives towards it. The behaviour is entertaining. The useful part is the sequence: every new capability is placed on top of a layer that already works.
Keep the wheels
A robotics kit deliberately removes several problems from the first lesson. The chassis already exists, motors are mounted, wheels turn, the motor driver has connectors and the supplied programs prove that the electrical system can move forwards, backwards and around a corner.
Arduino describes Iulia's base kit as an UNO Rev3, a shield carrying motor drivers and connections, plus a small set of sensors for jobs such as obstacle avoidance and line following.1 The platform is simple, with one useful advantage: the kit maker has already absorbed many of the annoying mechanical mistakes.
For learning, that already-stable perimeter changes the exercise considerably. If the weekend goal is to understand how camera output becomes motion, spending four hours choosing a gear ratio, printing a battery holder and discovering that one wheel is mounted backwards may teach the wrong lesson first.
The kit provides a verified assumption: this thing can already drive. The next problem can be software and perception.
Swap the board
The board replacement is easy because of a much older Arduino constraint: the headers remain compatible. Arduino notes that UNO Q keeps the familiar UNO form and connectors, which lets Iulia move the existing motor shield directly from the UNO Rev3.12
At the board swap, the first goal is much more modest: recover yesterday's robot with a different controller. Motor commands are restored before anything new is added.1
The sequence feels more like diagnosis than spectacle: change one variable, recover yesterday's behaviour, then open the next door.
UNO Q supplies a very different amount of compute inside that familiar envelope. It combines an STM32U585 microcontroller with a Qualcomm Dragonwing QRB2210 processor capable of running Linux, allowing low-level hardware control and heavier application workloads to coexist.2
Add eyes
Extra compute remains abstract until some new data enters the board. Iulia plugs a standard USB webcam into UNO Q.1
The video then enters App Lab. Arduino describes the environment around reusable Bricks, software building blocks that supply capabilities and can be connected to hardware and the rest of an application.3
In this project, the face-tracking Brick returns the position of a detected face in the frame.1 That is still not a motor command. A very ordinary control layer remains: face too far left, turn left; too far right, turn right; close to the centre, drive forwards.
For someone learning computer vision, this small bridge between coordinates and motors may be the most instructive part of the build. The detection model does not replace the robot logic. It produces an observation, and a few rules turn that observation into movement.
The result is a robot that effectively “chases” the detected person: it tries to recenter the face and then moves in that direction.14 Arduino itself jokes about the slightly aggressive behaviour. This is a demonstration, not a safe navigation system.
The model does not drive
The word “intelligent” quickly blurs the useful boundaries in this build. The camera and Face Tracking Brick add perception, but the robot has not acquired a general understanding of its surroundings.
From the published description, it does not plan a path around obstacles while following someone, reason about the real distance to a face or decide whether a staircase should make it stop. The original kit sensors still exist, but Arduino's demonstration focuses on the visual chase loop.1
That narrow scope makes the example easier to inspect. The boundaries remain visible: the model detects; the control code interprets; the shield drives; the motors move.
When everything is called “AI”, those boundaries disappear and debugging gets worse. When responsibilities stay visible, each failed behaviour points towards a smaller area.
Face detected correctly but the car turns the wrong way? Check coordinate-to-steering logic. Motors stopped responding after the board swap? Return to the shield and low-level control. Detection fails in poor light? Move upwards to the perception layer.
One difficulty at a time
Building a complete robot from scratch remains a good exercise for mechanics, power, motor electronics and fabrication. If the lesson is perception or control, a known rolling base can be more useful.
The evolving-kit route breaks the lesson into smaller moves: start with a known platform that drives, replace its controller without losing the wheels, add a camera, connect a vision Brick, then write one behaviour loop. Each stage can be tested separately, and each failure has a smaller neighbourhood.
It is also closer to how existing objects are upgraded outside a classroom. A workshop or product team does not necessarily throw away the mechanics because a better sensor becomes available. A useful interface may let the limited layer be replaced by itself.
Compatibility teaches
The decisive detail is almost boring: the old UNO shield can move onto the new board.1 Without that continuity, the experiment would begin with an electrical migration before it could explore any new behaviour.
Arduino's physical compatibility is usually sold as a convenient way to reuse shields. In this build it becomes a learning tool. A known system stays underneath while Linux, a camera and a vision pipeline are introduced above it.
The idea travels beyond this exact kit. When a learning object becomes too simple, a complete replacement is not always the most instructive upgrade. A better question is: which layer has become the limit, and can only that layer change?
Iulia's little car is not interesting because it can chase a face. It is interesting because it learns that new trick without ceasing to be the robot that already knew how to drive.