WORK IN PROGRESS
An autonomous mobile robot that utilizes real-time visual tracking and SLAM-based navigation to follow the fast, erratic motions of a Felis catus in a real, unmapped and obstacle-ridden environment. Specifically, this robot will be tracking my own cat, Calypso, around my room and the hallways of the floor where I live.
Architecture
Desktop (ROS2/SLAM) <--Wi-Fi/ROS2--> Raspberry Pi 3B+ <--UART--> Arduino Uno R3 <--PWM--> TB6612FNG <--> 4x DC Motors
▲
│ CSI
Camera (OV5647)
Roadmap
Hardware: Data Exchange
- Verify TB6612 (motor driver) wiring on breadboard
- Connect motor driver to Arduino Uno R3 using protoshield
(need copper wire, soldering iron stand, solder sucker, cleaning sponge) - Attach Uno to chassis, and connect DC motors to Uno through protoshield
- Attach battery pack to chassis, and connect it to DC motors (as their power source) through motor driver
- Verify that Uno is able to control all 4 wheels while attached to chassis
- Test UART communication only from Raspberry Pi 3B+ to Arduino Uno R3
- Using a breadboard, test UART communication from the Uno to Pi with a level shifter from 5V to 3.3V
- Solder level shifter to protoshield and set bi-directional UART communication through protoshield
- Verify communication between Pi and Uno
- Create script for Uno to receive commands through Serial and write to motors
- Verify that Pi is able to control all 4 wheels using Uno as intermediary
- Figure out ROS2 communication between desktop and Raspberry Pi 3B+ over Wi-Fi
(possibly need a router) - Create bridge node on Pi for translating ROS2 Twist messages to workable PWM values that can be sent to Arduino
- Verify that Pi is able to subscribe to topics, receive Twist messages, and use it to control the wheels
- Verify full communication architecture with Hand Controller
- Figure out how to send video feed from onboard camera to desktop
Timeline
8/2/26 - Attempted to permanently set wiring between TB6612 and Arduino using a protoshield
Bought some protoshields for the Arduino Uno R3, but they were physically incapable of seating on top of the Uno due to the heights of the ethernet port and power jack. To fix this, I used V-scoring to cut off an unnecessary part of the shield (Figure 8.2-1).
Figure 8.2-1. Results of cutting protoshield; the red shield on top shows the original length.
After that, I soldered header pins onto the protoshield so that I could plug it into the female pins on the Arduino (Figure 8.2-2). The protoshield has a partner hole directly next to each solder joint, giving access to the underlying Arduino pin.
Figure 8.2-2. Protoshield attached by header pins to the Arduino; the holes near each solder joint allow access to the actual Arduino pins.
Notably: For some of the pins, a bit of solder fell and clogged their partnered hole due to lack of experience. In the future, I should obtain a solder sucker to fix mistakes like this.
I then soldered the motor driver onto the protoshield and attempted to use lines of solder to replicate the wiring between the motor driver and the Arduino. On the surface, solder connects the partner holes to holes near the motor driver; underneath, solder connects the holes near the motor driver to the motor driver's pins (Figure 8.2-3).
Figure 8.2-3. Motor driver soldered onto protoshield; the raised lines of solder are used as wire to bridge the motor driver and Arduino.
Notably: Lacking equipment such as a sponge to clean the soldering iron and a stand to hold it while hot made this very difficult and time-consuming. Without being able to clean the iron of buildup, it was hard to make tiny, precise connections without accidentally creating a short circuit. In the future, I should obtain a soldering iron stand. Additionally, using solder as both the wire and the connector is difficult — in the future, I should obtain and use copper wire instead.
Ultimately, this attempt failed. I'll get the proper equipment and supplies before trying again.
7/31/26 - Verified TB6612 (Motor Driver) control logic on breadboard
Bought a TB6612 Motor Driver and soldered the header pins onto it. I tested the wiring between the Arduino, the motor driver, and one of the car's motors using a breadboard. Then, I wrote a script to test the motor driver's control logic (Figure 7.31-1).
TB6612.Control.Logic.Test.mp4
Figure 7.31-1. Motor driver control logic test — STBY, AIN1/AIN2, and PWMA signals verified with a multimeter before connecting battery power.
Issue: After wiring in battery power, STBY unexpectedly read 0V. STBY needs to constantly be set to HIGH, otherwise the motor driver operates in sleep mode. Isolated the fault via systematic voltage tracing using a multimeter and found a cold solder joint on the STBY header pin. Reheating the joint solved the issue.
7/26/26 - Redesigned robot control architecture
Initially thought to establish communication with a host computer running ROS2 to the onboard Arduino using an ESP32-S3 microcontroller (included with the kit) as the intermediary. Found that the I/O Expansion shield (placed on top of the Arduino) and the ESP32 were too customized/undocumented to extend for this project. Decided to scrap both parts, and instead use a different microcontroller as the intermediary.
Notably: Because of this replacement, I lost access to the motor driver (TB6612FNG) attached to the I/O Expansion Shield, so I would need to wire in one on my own.
For the intermediary, I chose to use the Raspberry Pi Model 3 B+ (Figure 7.26-1). This Pi was chosen mainly due to budget constraints. Since the project will initially run most computations through my desktop, the Pi only needs enough power to broadcast images over Wi-Fi, run ROS2 to receive commands, and translate those commands into workable Serial that can be written to the motors. Though a stronger Pi could run the computations itself, it is too expensive at the moment. The final structure will look like:
Host Computer <---ROS2 Messages---> RPi 3B+ <----Serial----> Arduino
Figure 7.26-1. Raspberry Pi Model 3 B+, chosen as the desktop to Arduino intermediary.
7/1/26 - Built smart car from kit
Initially decided to purchase a cheap autonomous vehicle kit (Figure 7.1-1). This would've allowed me to focus on writing the software for the project and not have to worry about custom-built hardware.
Figure 7.1-1. ELEGOO Smart Robot Car Kit V4.0, as originally assembled.