AlphaBot: Autonomous Lane Guidance with ArduCam

Abb. 1: Kamerasensor Arducam Mini 2MP

Autor:	Bertrand Mungu Cho
Art:	Project Work
Starttermin:	05.10.26
Abgabetermin:	20.01.27
Betreuer:	Prof. Dr.-Ing. Schneider
Sprache:	🇩🇪  🇬🇧

Introduction

The AlphaBot is a small, programmable mobile robot used for educational projects in robotics, embedded systems and autonomous navigation. It moves using two independently driven wheels and changes direction by varying their relative speeds. This differential-drive arrangement provides a practical platform for investigating how sensor measurements can be used to control a robot's movement.

This project develops camera-based autonomous lane guidance for the AlphaBot using an ArduCAM Mini 2MP Plus camera. The objective is to enable the robot to observe a marked lane, estimate its position and heading relative to that lane, and adjust its motion to follow the intended path. The project brings together mechanical design, image acquisition, image processing and feedback control.

The work includes designing and 3D printing a camera mount, commissioning the camera with an Arduino, and transferring captured images to a PC running MATLAB. Image processing is used to identify the lane and estimate the lateral and heading errors. These estimates provide the input to the lane guidance controller, while gyroscope measurements are intended to provide feedback on the robot's turning rate. The resulting left and right motor commands are sent to the Arduino, which controls the motors through the motor driver.

Development proceeds from individual component tests to integration and evaluation of the complete system. MATLAB/Simulink supports algorithm and controller development, while practical experiments assess image-transfer reliability, processing time and lane-following performance. This article documents the design decisions, implementation steps and experimental results.

Table 1: Funktional Requirements 

Req.	Beschreibung	Priorität
FR-01	The ArduCam must acquire images of the track and transmit them to MATLAB via Arduino and Wi-Fi/UDP.	1
FR-02	The camera images must be corrected for lens distortion where required.	1
FR-03	The image-processing algorithm must detect the lane markings and estimate the desired path.	1
FR-04	The system must determine the lateral deviation of the AlphaBot from the desired path.	1
FR-05	The system must determine the heading error relative to the lane direction.	1
FR-06	MATLAB must calculate the desired yaw rate and forward speed from the lane-tracking errors.	1
FR-07	The system must acquire, bias-correct, and filter the gyroscope yaw-rate measurement.	1
FR-08	The AlphaBot must follow the lane autonomously using camera and gyroscope feedback.	1
FR-09	The system shall stop the motors if lane detection becomes invalid or control references are no longer received within a defined timeout.	1
FR-10	The system shall stop the motors immediately, if the emergency stop switch in Simulink is presses.	1
FR-11	The system must record relevant sensor data, estimated errors, reference values, and motor commands for evaluation.	1
FR-12	The AlphaBot must drive in direction of the driven wheels. The ball must be in the back.	1
FR-13	A Platform must be designed with a camera mount in the front and a Prism-mount für the reference prism.	1
FR-14	The Platform must allow an easy change of batteries.	1

Table 2: Non-Funktional Requirements 

Req.	Beschreibung	Priorität
NFR-01	The control system must operate in real time at defined and documented image-processing and control update rates.	1
NFR-02	The lane-following system must achieve stable tracking on straight sections and curves of the defined test track.	1
NFR-03	The lateral tracking error must remain within a defined tolerance during successful operation.	1
NFR-04	The yaw-rate controller must provide stable steering without sustained oscillations under the defined test conditions.	1
NFR-05	The communication system must detect stale or missing control references within a defined timeout.	1
NFR-06	The system must produce reproducible lane-tracking results in repeated tests under comparable conditions.	1
NFR-07	The maximum stable driving speed must be determined experimentally and documented.	1
NFR-08	The MATLAB/Simulink models and source code must be structured, readable, and documented.	1
NFR-09	The system performance shall be evaluated using recorded measurements and clearly defined test criteria.	1

Table 3: Constraints 

Req.	Beschreibung	Priorität
C-01	Die Masse muss mit der Wägezelle HX711AD mittels Arduino und Simulink ermittelt werden.	1
C-02	The Arducam-Mini-5MP-Plus (B0067) specified for the project must be used for lane detection.	1
C-03	The Arduino Uno R4 WiFi must be used as the embedded controller, subject to confirmation of the final hardware configuration.	1
C-04	MATLAB must be used for image processing and lane-guidance calculations.	1
C-05	Simulink must be used for model-based development and evaluation where applicable.	1
C-06	Camera images must be acquired via SPI and transferred to MATLAB over WiFi using UDP.	1
C-07	The camera mount must be designed in CAD with SolidWorks, 3D-printed, and securely attached to the AlphaBot.	1
C-08	The available processor resources, communication bandwidth, motor interfaces, and sensor interfaces must be respected.	1
C-09	Source code, CAD files, models, and documentation must be maintained in the designated SVN repository and HSHL Wiki.	1

Tasks

1. Familiarization with the topics Arduino, Arducam Mini 2MP
2. CAD design and 3D printing of the camera mount
3. Commissioning of the camera
4. Image processing for lane detection
5. Autonomous lane following (control)
6. Model-based development with MATLAB^®/Simulink
7. Testing and scientific documentation
8. Proof of functionality as a wiki article with animated GIF

Getting Started

1. Transponder for the Student Lab from Mr. Ebmeyer
2. Security Infomation for the Student Lab (from Mr. Ebmeyer)
3. Wiki Access (from Mr. Schröder)
4. Plan your task with working packages and dependencies as a gantt chart.
5. Get started with programming the ArduCam with Arduino.
6. Document your steps in this article: Arducam Mini 2MP
7. Design mount for ArduCam. Reuse or optimise the existing design.
8. Print the mount an attach it to the AlphaBot.
9. Document the new mount in SVN and your Wiki Article.
10. Research how to programm the ArduCam via MATLAB/Simlink.

System Design

The proposed system uses the ArduCAM to capture lane images and a gyroscope to measure the AlphaBot’s yaw rate. The Arduino Uno R4 WiFi transfers these data to a PC through a wireless router. MATLAB processes the images to estimate the robot’s position and heading relative to the lane. The guidance and yaw-rate controllers calculate left and right motor commands, which are sent back to the Arduino for execution. This process repeats continuously to maintain lane following.

Mechanical Design and Camera Mount

Back view of the camera mount.	8-pin connector for connecting the ArduCAM camera to the Arduino.

The CAD designs for the camera mount and connector support are available in the SVN repository:

CAD designs – camera mount and connector support

• Strain relief: ???

Camera Commissioning

Camera commissioning was carried out to verify the connection between the ArduCAM Mini 2MP Plus B0067 and the Arduino UNO R4 WiFi, configure the camera library, and confirm successful image capture. Initial testing was performed over USB before integration with the AlphaBot.

Preconditions

• ArduCAM Mini 2MP Plus B0067
• Arduino UNO R4 WiFi
• Connection/Cable Plan? Image?
• Library Link?? Version?
• Source code? Link??
• USE SPI Connector
• Move with versioning to c-files.

Hardware Setup and Pin Assignment

The test setup consisted of the ArduCAM B0067 camera, an Arduino UNO R4 WiFi, a breadboard, jumper wires and a USB connection to a Windows PC. The camera uses I2C for sensor configuration and SPI for capture control and image readout.

The following pin assignment was used:

ArduCAM B0067 to Arduino UNO R4 WiFi pin assignment

ArduCAM pin	Arduino pin	Function
VCC	5V	Camera power supply
GND	GND	Common ground
SDA	SDA	I2C data for sensor configuration
SCL	SCL	I2C clock
MOSI	D11	SPI data from Arduino to camera
MISO	D12	SPI data from camera to Arduino
SCK	D13	SPI clock
CS	D7	Camera chip select

Wiring changes were made with USB power disconnected. Short jumper wires were used to reduce connection problems during SPI communication.

ArduCAM Library Configuration

The ArduCAM library was configured for the Mini 2MP Plus by enabling the following definition in its memorysaver.h file:

#define OV2640_MINI_2MP_PLUS

The other camera-platform selections in the same section were commented out. The additional sensor-selection section for ArduCAM Shield models was left unchanged.

Arduino UNO R4 Compatibility Adaptations

The installed library initially failed to compile because it did not define regtype and regsize for the UNO R4 architecture. A second error occurred because the example's variable name CS conflicted with a definition in the UNO R4 board package.

The sketch's chip-select variable was therefore renamed to CAMERA_CS, while retaining D7 as the physical connection:

const int CAMERA_CS = 7;
ArduCAM myCAM(OV2640, CAMERA_CS);

The corresponding setup instructions were updated:

pinMode(CAMERA_CS, OUTPUT);
digitalWrite(CAMERA_CS, HIGH);

The following architecture-specific definitions were added to ArduCAM.h, before the existing AVR definitions:

#if defined(ARDUINO_ARCH_RENESAS_UNO)
#define regtype volatile uint32_t
#define regsize uint32_t

#define cbi(reg, bitmask) digitalWrite(bitmask, LOW)
#define sbi(reg, bitmask) digitalWrite(bitmask, HIGH)
#endif

In the constructor in ArduCAM.cpp, defined(ARDUINO_ARCH_RENESAS_UNO) was added to the condition selecting the branch that assigns B_CS = CS;. This makes the library store the chip-select pin number and use digitalWrite() instead of direct port-register access.

A further correction was made in the example sketch's resolution-selection code. Under case 4, the camera-selection condition was changed to:

#if defined(OV2640_MINI_2MP_PLUS)

After these changes, the sketch compiled and uploaded successfully. The modified library files were retained with the project source code so that the tested setup could be reproduced.

Communication Test

After uploading the sketch, the Arduino Serial Monitor was opened with a baud-rate setting of 921600. The following startup messages were observed:

ACK CMD ArduCAM Start! END
ACK CMD SPI interface OK.END
ACK CMD OV2640 detected.END

The SPI test verified that the Arduino could write and read a test register on the camera module. The sensor-identification routine also reported detection of the OV2640. These checks were followed by image capture to verify the complete acquisition path.

Image Capture Test

The ArduCAM Host V2 Windows application was used to request and display images over the USB serial connection. Serial Monitor was closed before opening the host application to avoid simultaneous access to the same port.

The following settings were used:

Parameter	Setting
Serial port	COM5 in the test setup
Baud-rate setting	921600
Camera sensor	OV2640
Image resolution	320 × 240 pixels
Capture mode	Single capture
Image format	JPEG; SetToBMP unchecked

The COM port may differ on another computer and must be checked before connecting. The application sent the capture request, received the image data and displayed a photograph.

Test image captured with the ArduCAM Mini 2MP Plus during camera commissioning.

Commissioning Outcome

Successful image display confirmed that camera configuration, capture, buffer readout and USB transfer operated together with the modified UNO R4 library.

Occasional corrupted images and cases where capture completed without image display were also observed during testing. Therefore, successful initial capture was treated as a functional check rather than proof of continuous reliability. Repeated image acquisition was subsequently tested in MATLAB, as described in the following section.

Control System

The control loop uses camera images to estimate the AlphaBot's position and heading relative to the lane. MATLAB calculates a desired turning rate and compares it with the yaw rate measured by the gyroscope. The resulting steering command is converted into left and right motor commands, which are sent to the Arduino.

1. Lane Position and Heading Errors

$e_y=y_{\mathrm{r}\mathrm{e}\mathrm{f}}-y_{\mathrm{m}\mathrm{e}\mathrm{a}\mathrm{s}}$

The lateral error $e_y$ describes the difference between the desired lateral position $y_{\mathrm{r}\mathrm{e}\mathrm{f}}$ and the position estimated from the camera image $y_{\mathrm{m}\mathrm{e}\mathrm{a}\mathrm{s}}$. When the lane centre is the reference, $y_{\mathrm{r}\mathrm{e}\mathrm{f}}=0$. An error of zero means that the robot is at the desired lateral position.

$e_{\psi }={\mathrm{wrap}}_{[-\pi ,\pi )}({\psi }_{\mathrm{r}\mathrm{e}\mathrm{f}}-{\psi }_{\mathrm{m}\mathrm{e}\mathrm{a}\mathrm{s}})$

The heading error $e_{\psi }$ describes the difference between the desired heading ${\psi }_{\mathrm{r}\mathrm{e}\mathrm{f}}$ and the measured heading ${\psi }_{\mathrm{m}\mathrm{e}\mathrm{a}\mathrm{s}}$. Both headings must use the same reference frame. The wrapping operation expresses the difference between $-\pi$ and $\pi$ radians, preventing an unnecessarily large correction when an angle crosses the boundary.

2. Lane Guidance

$r_{\mathrm{r}\mathrm{e}\mathrm{f}}=k_y{e}_y+k_{\psi }{e}_{\psi }$

The lane guidance equation converts the lateral and heading errors into a desired yaw rate $r_{\mathrm{r}\mathrm{e}\mathrm{f}}$. Yaw rate describes how quickly the robot turns around its vertical axis. The gains $k_y$ and $k_{\psi }$ determine how strongly the robot responds to each error.

The lateral term guides the robot towards the desired lane position, while the heading term helps align it with the lane direction. With both errors equal to zero, this equation requests zero yaw rate.

3. Yaw-Rate Error

$e_r=r_{\mathrm{r}\mathrm{e}\mathrm{f}}-r_{\mathrm{m}\mathrm{e}\mathrm{a}\mathrm{s}}$

The yaw-rate error $e_r$ compares the desired turning rate with the actual turning rate $r_{\mathrm{m}\mathrm{e}\mathrm{a}\mathrm{s}}$ measured by the gyroscope. The gyroscope reading is corrected for bias and filtered before being used as feedback.

4. Yaw-Rate PI Controller

$u_{\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{e}\mathrm{r}}(t)=K_p{e}_r(t)+K_i\underset{0}{\overset{t}{\int }}{e}_r(\tau )\mathrm{d}\tau$

The proportional-integral (PI) controller calculates the steering command $u_{\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{e}\mathrm{r}}$. The proportional term, controlled by $K_p$, responds to the current yaw-rate error. The integral term, controlled by $K_i$, accumulates the error over time and helps reduce persistent differences between the desired and measured turning rates.

The steering command is a motor-control correction, rather than a physical steering angle, because the AlphaBot turns by driving its two wheels at different speeds.

5. Motor Mixing and Limits

$u_L=\mathrm{limit}(u_{\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{w}\mathrm{a}\mathrm{r}\mathrm{d}}-u_{\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{e}\mathrm{r}})$

$u_R=\mathrm{limit}(u_{\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{w}\mathrm{a}\mathrm{r}\mathrm{d}}+u_{\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{e}\mathrm{r}})$

The motor mixer combines the forward command $u_{\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{w}\mathrm{a}\mathrm{r}\mathrm{d}}$ with the steering correction to obtain the left motor command $u_L$ and right motor command $u_R$.

When the steering correction is zero, both motors receive the same command. A non-zero correction increases one motor command and decreases the other, causing the robot to turn.

The limiting function keeps each command within the permitted motor-command range:

$\mathrm{limit}(u)=\min (u_{\max },\max (u_{\min },u))$

The command bounds depend on the chosen direction and PWM representation. The Arduino converts the received motor commands into direction signals and PWM outputs for the motor driver.

Closing the Feedback Loop

The motor commands change the AlphaBot's motion. The camera observes the resulting lane position and heading, while the gyroscope measures the resulting yaw rate. MATLAB uses these updated measurements to calculate the next correction.

All position, heading, yaw-rate and motor-direction signs must follow a consistent convention so that the controller reduces the errors. Lateral position may initially be expressed in image pixels; expressing it in metres requires a calibrated image-to-ground mapping. Heading is expressed in radians and yaw rate in radians per second.

Appendix

A Gantt Project Chart

Gantt chart 1

Gantt chart 2

The Gantt chart outlines the project activities, dependencies and milestones, from camera mount design and commissioning to lane detection, controller development and final testing. It is updated regularly to reflect progress and changes to the schedule.

B Requirements for student skills

The project requires prior knowledge in the following subject areas. If you do not meet these requirements, you must acquire the necessary knowledge independently during the course of the project using literature and online courses.

1. CAD design with SolidWorks
2. 3D printing
3. Image processing
4. Optional: Model-based development with MATLAB^®/Simulink
5. Document versioning with SVN
6. Documentation using Word and the HSHL Wiki

C Requirements for the Scientific Work

• Scientific approach (project plan, etc.), useful article: Create a Gantt chart
• Weekly progress reports (informative); update the meeting minutes – live meeting with Prof. Schneider
• Project presentation in the Wiki
• Daily backup of work results in SVN
• Daily documentation of the hours worked
• Student Projects with Prof. Schneider
• Requirements for a Scientific Paper
• The Scientific Method and the Importance of Documenting Results

---

→ back to the main article: Student Work