Republic of Tunisia Computer Engineering & Applied

Ministry for Higher Education and of Mathematics Department

Scientific Research

University of Sfax
National Engineering School of Sfax Graduation Project
(ENIS) Serial N°: 2025 / DIMA-061

Graduation Project Report

presented at

National Engineering School of Sfax

(Computer Engineering & Applied Mathematics Department)

in order to obtain the

National Engineering Diploma in Computer Science

by

Ameur GARGOURI

Design, Development and Implementation

of an Autonomous Robot

Defended on 16/06/2025 in front of the committee composed of

Mr Riadh Ben Halima President

Mrs Afef Mdhaffar Reviewer
Mr Bechir Zalila Academic Supervisor
Mr Mohamed Karray Industrial Supervisor
Mr Mohamed Ksantini Industrial Supervisor
 Dedications

I would like to dedicate this work to:

My Parents, Hamadi and Fatma

Your unwavering support and encouragement have been my driving force throughout
this journey. Your belief in me has been the corner stone of my success.

All My Family Members

Your constant encouragement to pursue my studies and strive for greater achievements
has been deeply appreciated.

My Friends

Thank you for your companionship and motivation. Your presence has made this
journey both enjoyable and meaningful.

The ESME Research Lab Team

To my mentors, the ESME Research Lab Autonomous Robot Project Interns, and the
ESME Research Lab Team, thank you for your guidance and support during my intern-
ship. Your insights and encouragement have been instrumental in shaping my perspective
and enriching my learning experience.

This accomplishment stands as a testament to the collective support and belief

of those who have been with me every step of the way.

i
 Acknowledgments

I express my deepest gratitude to all who participated in the successful completion of

this work.

First and foremost, I am extremely grateful to Mohamed Ksantini and Mohamed

Karray, my industrial supervisors, for their continuous guidance, support, and valuable
advice throughout my internship. Their mentorship has had a significant impact on my
learning experience and helped me grow both technically and personally.

I am also very grateful to my academic supervisor, Mr. Bechir Zalila, for his ongoing
support, encouragement, and thoughtful feedback during every stage of this project. His
advice and direction have been essential to my progress.

A very special thanks to the entire ESME Research Lab team for their dedication,
enthusiasm, and collaboration. It has been a pleasure to work with such a motivated and
supportive community of people and has enriched this project’s progress immensely.

I also extend my heartfull thanks to the members of the jury. To Mr. Riadh Ben
Halima, President of the Jury, and Mrs. Afef Mdhaffar, Reviewer. Thank you for your
time, your consideration and the honor of having my work read by you. Your participation
in this process means a lot to me.

Finally, I also wish to express my gratitude to all the teachers at the National En-
gineering School of Sfax for their dedication and the knowledge they’ve instilled in me
throughout my studies. They have been a constant inspiration throughout my academic
journey.

ii
Acronyms

A* A-Star

AGVs Automated Guided Vehicles

AMCL Adaptive Monte Carlo Localization

AMR Autonomous Mobile Robot

CAN Controller Area Network

CNC Computer Numerical Control

COCO Common Objects in Context

CPU Central Processing Unit

CRC Cyclic Redundancy Check

DDS Data Distribution Service

DWA Dynamic Window Approach

DWB Dynamic Window Based-Controller

ENIS National Engineering School of Sfax

ESME Special School of Mechanics and Electricity

FIS Fuzzy Inference System

FreeRTOS Free Real-Time Operating System

GELAN Generalized Efficient Layer Aggregation Network

GPS Global Positioning System

GPU Graphics Processing Unit

iii
 Acronyms

ImageNet ImageNet

IMU Inertial Measurement Unit

IMUs Inertial Measurement Units

IoT Internet of Things

AI Artificial Intelligence

I2C Inter-Integrated Circuit

LiDAR Light Detection and Ranging

ML Machine Learning

NAV2 Navigation 2

NCNN A High-Performance Neural Network Inference Framework

NMS Non-Maximum Suppression

OBB Oriented Bounding Boxes

PGI Programmable Gradient Information

PID Proportional-Integral-Derivative

RPP Regulated Pure Pursuit

RFID Radio Frequency Identification

ROS Robot Operating System

ROS2 Robot Operating System 2

RPM Revolutions Per Minute

RRT Rapidly-exploring Random Tree

RViz2 ROS Visualization 2

SLAM Simultaneous Localization and Mapping

SPI Serial Peripheral Interface

TEB Timed Elastic Band

tf transform

UART Universal Asynchronous Receiver/Transmitter

iv
 Acronyms

UGV Unmanned Ground Vehicle

URDF Unified Robot Description Format

Xacro XML Macros

YOLO You Only Look Once

v
Contents

General Introduction 1

1 General Presentation 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Academic Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Host Organism Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 ESME Research Lab Activities . . . . . . . . . . . . . . . . . . . . 5

1.3.2 ESME Research Lab Location . . . . . . . . . . . . . . . . . . . . . 5

1.4 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Project Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.2 Project Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Project Management Approach and Methodology . . . . . . . . . . . . . . 9

1.5.1 Agile Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.2 Scrum Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

vi
CONTENTS CONTENTS

1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Robotics History 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Autonomous Robotics History . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Al-Jazari’s Hand-Washing Automaton (1206) . . . . . . . . . . . . 14

2.2.2 Leonardo da Vinci’s Mechanical Knight (1495) . . . . . . . . . . . . 15

2.2.3 Jacques de Vaucanson’s Digesting Duck (1738) . . . . . . . . . . . . 16

2.2.4 Charles Babbage’s Analytical Engine (1837) . . . . . . . . . . . . . 16

2.2.5 Walter’s "Tortoise" Robots (1949) . . . . . . . . . . . . . . . . . . . 17

2.2.6 Shakey the Robot (1966–1972) . . . . . . . . . . . . . . . . . . . . . 18

2.2.7 Clearpath Husky UGV (2013) . . . . . . . . . . . . . . . . . . . . . 18

2.2.8 MiR100 Autonomous Mobile Robot (2016) . . . . . . . . . . . . . . 19

2.2.9 Boston Dynamics’ Advanced Robotics (2016) . . . . . . . . . . . . . 19

2.3 Robot Operating System (ROS) . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1 Introduction and System Structure . . . . . . . . . . . . . . . . . . 20

2.3.2 Key Development Tools in ROS . . . . . . . . . . . . . . . . . . . . 21

2.3.3 Advantages of ROS for Autonomous Robotics . . . . . . . . . . . . 23

2.3.4 ROS vs. ROS2 vs. Alternative Methods . . . . . . . . . . . . . . . 24

2.4 Technologies in Autonomous Robots . . . . . . . . . . . . . . . . . . . . . 26

2.4.1 Sensors and Perception Systems . . . . . . . . . . . . . . . . . . . . 26

vii
CONTENTS CONTENTS

2.4.2 Localization and Mapping Techniques . . . . . . . . . . . . . . . . . 28

2.4.3 Navigation and Path Planning . . . . . . . . . . . . . . . . . . . . . 29

2.4.4 Motion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5 Communication Tools and Protocols in Embedded Systems . . . . . . . . . 33

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Software Development of Autonomous Robot 37

3.1 Introduction to the Robot Development Process . . . . . . . . . . . . . . . 39

3.2 Concept Development and Initial Design . . . . . . . . . . . . . . . . . . . 39

3.3 Proposed Modeling and Robot Description . . . . . . . . . . . . . . . . . . 40

3.3.1 Introduction to URDF and Xacro . . . . . . . . . . . . . . . . . . . 41

3.3.2 Designing the Robot’s Physical Model . . . . . . . . . . . . . . . . 41

3.3.3 Integrating Sensors and Actuators . . . . . . . . . . . . . . . . . . . 41

3.3.4 Transformations and Their Applications . . . . . . . . . . . . . . . 42

3.3.5 Validation of URDF Model . . . . . . . . . . . . . . . . . . . . . . 43

3.4 Simulation Environment Development . . . . . . . . . . . . . . . . . . . . . 43

3.4.1 Selection and Setup of Simulation Tools . . . . . . . . . . . . . . . 43

3.4.2 Creating the Virtual Environment . . . . . . . . . . . . . . . . . . . 44

3.4.3 Importing and Configuring the URDF Model . . . . . . . . . . . . . 44

3.4.4 Initial Simulation Tests . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

viii
CONTENTS CONTENTS

3.5.1 Essential ROS2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5.2 Launch Files and Configuration . . . . . . . . . . . . . . . . . . . . 47

3.5.3 Robot Localization in Simulation . . . . . . . . . . . . . . . . . . . 47

3.5.4 Mapping in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.6 Navigation System Implementation . . . . . . . . . . . . . . . . . . . . . . 49

3.6.1 Initialization and Coordination: . . . . . . . . . . . . . . . . . . . . 49

3.6.2 Global Path Planning: . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.6.3 Local Path Planning and Obstacle Avoidance: . . . . . . . . . . . . 50

3.6.4 Costmap Management: . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6.5 Behavior Execution and State Management: . . . . . . . . . . . . . 53

3.6.6 Control and Command Execution: . . . . . . . . . . . . . . . . . . . 53

3.6.7 Transform Integration . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6.8 Feedback and Monitoring . . . . . . . . . . . . . . . . . . . . . . . 54

3.7 Search Mechanism and Custom Search Algorithm . . . . . . . . . . . . . . 55

3.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.7.2 Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.7.3 Algorithm Demonstration . . . . . . . . . . . . . . . . . . . . . . . 56

3.7.4 Complexity Analysis and Interpretation . . . . . . . . . . . . . . . . 57

3.7.5 Algorithm Implementation Details . . . . . . . . . . . . . . . . . . . 58

3.7.6 Coverage Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

ix
CONTENTS CONTENTS

3.8 YOLO Model Integration for Object Detection . . . . . . . . . . . . . . . . 60

3.8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.8.2 Model Selection and Comparison . . . . . . . . . . . . . . . . . . . 60

3.8.3 Integration with Raspberry Pi . . . . . . . . . . . . . . . . . . . . . 61

3.8.4 Detection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.8.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.9 Flutter App Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.9.1 Overview of Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.9.2 Why Choose Flutter? . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.9.3 Flutter App Development for Robot Control . . . . . . . . . . . . . 64

3.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 Hardware Realization and Integration 67

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2 Hardware Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3 ESP32 Firmware for Motor Speed and Communication . . . . . . . . . . . 70

4.3.1 FreeRTOS for Multitasking and Real-Time Execution . . . . . . . . 70

4.3.2 Motor Speed Calculation . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3.3 Motor Speed Regulation Process . . . . . . . . . . . . . . . . . . . . 73

4.3.4 Communication Between ESP32 and Raspberry Pi . . . . . . . . . 80

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

x
CONTENTS CONTENTS

General Conclusion 83

xi
List of Figures

1.1 ENIS logo[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Special School of Mechanics and Electricity (ESME) Research Lab logo[2] . 4

1.3 General Project Architecture Diagram . . . . . . . . . . . . . . . . . . . . 7

1.4 Robot Architecture Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Agile Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6 Scrum Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.7 Project Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Al-Jazari’s hand-washing automaton (1206). . . . . . . . . . . . . . . . . . 15

2.2 Leonardo da Vinci’s Mechanical Knight (1495). . . . . . . . . . . . . . . . 16

2.3 Jacques de Vaucanson’s Digesting Duck (1738). . . . . . . . . . . . . . . . 16

2.4 Charles Babbage’s Analytical Engine (1837). . . . . . . . . . . . . . . . . . 17

2.5 Grey Walter’s Elmer and Elsie "tortoise" robots (1949). . . . . . . . . . . . 17

2.6 Shakey the Robot at SRI International (1966–1972). . . . . . . . . . . . . . 18

2.7 Clearpath Husky UGV in outdoor environments (2013). . . . . . . . . . . . 18

xii
LIST OF FIGURES LIST OF FIGURES

2.8 MiR100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.9 Boston Dynamics’ Spot and Atlas robots. . . . . . . . . . . . . . . . . . . . 20

2.10 General structure of ROS communication between nodes [20]. . . . . . . . 21

2.11 RViz logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.12 Interface of RViz in action . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.13 Gazebo logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.14 Simulation in Gazebo environment . . . . . . . . . . . . . . . . . . . . . . 22

2.15 tf visualization example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.16 YDLIDAR TSA sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.17 Logitech StreamCam used for object detection. . . . . . . . . . . . . . . . 27

2.18 Ultrasonic sensor for obstacle avoidance [25]. . . . . . . . . . . . . . . . . . 27

2.19 NAV2 Stack Logo [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.20 Diagram of a PID control system with fuzzy logic enhancements [36]. . . . 31

2.21 Rotary encoder with Hall sensors [37]. . . . . . . . . . . . . . . . . . . . . 32

2.22 Clockwise and Counter-Clockwise operation of encoders [38]. . . . . . . . . 32

3.1 Initial System Design Block diagram. . . . . . . . . . . . . . . . . . . . . . 40

3.2 Unified Robot Description Format (URDF) Model of the Robot. . . . . . . 41

3.3 Validation of URDF Model in RViz. . . . . . . . . . . . . . . . . . . . . . . 43

3.4 Virtual Environment in Gazebo. . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5 Initial Simulation Test in Gazebo. . . . . . . . . . . . . . . . . . . . . . . . 45

xiii
LIST OF FIGURES LIST OF FIGURES

3.6 Map Visualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.7 Illustration of DWA algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.8 Illustration of TEB algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.9 Path following with RPP controller. . . . . . . . . . . . . . . . . . . . . . . 51

3.10 Robot during autonomous navigation in Rviz2. . . . . . . . . . . . . . . . . 54

3.11 Coverage Map: Circular FOVs Overlapping for Room Coverage . . . . . . 59

3.12 Ultralytics Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.13 Flutter logo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.14 Main Interface of the Flutter App for robot Control. . . . . . . . . . . . . 65

4.1 Diagram of component connections. . . . . . . . . . . . . . . . . . . . . . . 69

4.2 Assembled robot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.3 Quadrature encoder signals for detecting rotational direction. . . . . . . . . 72

4.4 Manual PID Tuning Results. . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.5 Membership Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.6 Fuzzy Rules Surface for Kp. . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.7 Fuzzy Logic PID Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.8 UART data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.9 FreeRTOS Code Snippet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

xiv
List of Tables

2.1 Comparison of ROS, ROS2, and Alternative Approaches . . . . . . . . . . 25

2.2 Advantages and Disadvantages of Communication Protocols . . . . . . . . 35

3.1 Coordinate Frames and Their Roles . . . . . . . . . . . . . . . . . . . . . . 42

3.2 ROS 2 Nodes and Their Roles . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Launch Files and Their Roles . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Enhanced Comparison of NAV2 Navigation Algorithms in Simulation [39–42] 52

3.5 Search Algorithms Comparison . . . . . . . . . . . . . . . . . . . . . . . . 56

3.6 Comparison of Nano YOLO Models from Ultralytics [43] . . . . . . . . . . 61

3.7 Comparison of Mobile Development Platforms [44–47] . . . . . . . . . . . . 63

4.1 Membership functions comparison . . . . . . . . . . . . . . . . . . . . . . . 75

xv
General Introduction

Robots are programmable electromechanical systems designed for autonomous or su-

pervised tasks, with applications in manufacturing, healthcare, exploration, and domestic
assistance. Among these, autonomous mobile robots stand out for navigating dynamic
environments independently.this project develops a fully autonomous indoor mobile robot
to locate misplaced household items, showcasing robotics’ potential to enhance daily con-
venience.

The adaptive fuzzy logic Proportional-Integral-Derivative (PID) controller adjusts pa-

rameters dynamically to handle nonlinear conditions, ensuring smooth navigation and
energy efficiency. Navigation relies on Robot Operating System 2 (ROS2) and Navigation
2 (NAV2), using Adaptive Monte Carlo Localization (AMCL) for localization, Light De-
tection and Ranging (LiDAR)-based costmaps for obstacle avoidance, and Dynamic Win-
dow Based-Controller (DWB) for path planning, validated in simulation and real-world
tests.

A key challenge is transitioning from simulation to reality, where sensor noise and
environmental dynamics require careful calibration and algorithm adaptation. The robot’s
vision-guided search algorithm generates waypoints for efficient exploration, refining paths
dynamically to locate targets in cluttered spaces. A Flutter app provides a user-friendly
interface for control and supervision.

The first chapter offers a general presentation, detailing the project’s context, objec-
tives, and management using Agile and Scrum methodologies at ESME Research Lab.

The second chapter reviews the history and technologies of autonomous robotics, cov-
ering milestones, Robot Operating System (ROS) evolution, and key areas like sensors,
localization, navigation, and communication.

The third chapter explores software development, covering concept design, URDF
modeling, simulation, NAV2 navigation, search algorithm, You Only Look Once (YOLO)
integration, and the Flutter app.

The fourth chapter addresses hardware realization, detailing component assembly,

ESP32 firmware with FreeRTOS and fuzzy logic PID, and Universal Asynchronous Re-
ceiver/Transmitter (UART) communication with the Raspberry Pi.

1
1 General Presentation

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Academic Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Host Organism Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 ESME Research Lab Activities . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 ESME Research Lab Location . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Project Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Project Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Project Management Approach and Methodology . . . . . . . . . . . . 9
1.5.1 Agile Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Scrum Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2
Introduction Chapter 1

1.1 Introduction

This chapter examines the environmental factors and organizational context relevant
to our project. We begin by introducing the ESME Research Lab, a Paris-based hub
renowned for its dedication to technological innovation and interdisciplinary research.
This supportive environment, with its advanced infrastructure and expertise, has been
instrumental in the project’s success.

Next, we outline the academic context, highlighting the project as the capstone of
our computer engineering education at ENIS. It bridges theoretical learning with practi-
cal application, addressing real-world challenges while meeting degree requirements and
enhancing our technical and problem-solving skills.

We then present the project’s general context, focusing on designing an autonomous

robot to locate misplaced household items (e.g., bottles, jars) indoors. This prototype
integrates object detection, autonomous navigation, and real-time sensor data, offering
potential for smart homes and assistive technologies.

The project overview details its goals, technical challenges, and expected outcomes, ad-
dressing broader issues, innovative approaches, and objectives. It also considers practical
constraints like hardware limitations, environmental variability, and system integration
complexities.

Finally, we discuss our project management strategy, employing Agile and Scrum
methodologies for a flexible, iterative process. This approach facilitated continuous feed-
back, efficient task allocation, progress evaluation, and adaptability to technical challenges
throughout the project lifecycle.

1.2 Academic Context

This project marks the culmination of my three years of engineering studies at the
National Engineering School of Sfax (ENIS). Throughout these years, we have acquired a
solid foundation in various domains, including embedded systems and computer engineer-
ing, which has been instrumental in shaping my understanding of autonomous systems.
This final-year project not only synthesizes the theoretical concepts gained during my
academic journey but also extends my technical capabilities through their application to
a real-world problem. It is worth mentioning that this graduation internship was car-
ried out at the ESME Research Lab in Paris, France, from February 1 to May 30, 2025.
This experience provided an excellent opportunity for me as a student to explore the
professional world, collaborate with new people, and acquire advanced techniques to fur-
ther develop my skills. The chance to work on a concrete and innovative project under
the guidance of research professionals significantly enriched my learning experience and
offered valuable insight into my future career path.

3
Host Organism Presentation Chapter 1

Figure 1.1: ENIS logo[1]

1.3 Host Organism Presentation

ESME Research Lab, affiliated with ESME Sudria, is a multidisciplinary research lab-
oratory based in Paris, France. The lab is dedicated to fostering innovation and advancing
applied research in areas such as robotics, embedded systems, artificial intelligence, and
the Internet of Things (IoT). Through its collaborative approach, the lab brings together
students, faculty, and industry partners to work on cutting-edge projects that address
real-world challenges. Its mission is to bridge the gap between academic research and
industrial application, empowering students to gain hands-on experience with emerging
technologies.

With a strong emphasis on innovation and practical implementation, the ESME Re-
search Lab plays a key role in the academic ecosystem of ESME Sudria. It provides
a dynamic environment where over a hundred projects are conducted annually, ranging
from autonomous systems and smart mobility to energy optimization and cybersecurity.
The lab also supports entrepreneurship through initiatives that encourage students and re-
searchers to transform their ideas into viable solutions. This vibrant and forward-thinking
environment makes the ESME Research Lab a cornerstone of technological advancement
and a vital contributor to the future of engineering education and research.

Figure 1.2: ESME Research Lab logo[2]

4
Project Overview Chapter 1

1.3.1 ESME Research Lab Activities

The ESME Research Lab is an innovative and multidisciplinary research environment

focused on emerging technologies and real-world applications. Its expertise spans two
principal areas:

• Applied Research and Innovation: The ESME Research Lab actively engages
in applied research projects in fields such as robotics, embedded systems, Artificial
Intelligence (AI), the IoT, and cybersecurity. By fostering collaboration between
students, faculty, and industry professionals, the lab delivers tangible solutions to
contemporary technological challenges. Research projects often address societal and
industrial needs, offering students hands-on experience in innovation, system pro-
totyping, algorithm development, and experimental validation. This applied focus
prepares participants to navigate the complexities of modern engineering problems
with creativity and rigor.

• Academic-Industrial Collaboration: A central mission of the ESME Research

Lab is to bridge academic knowledge with industry needs. Through partnerships
with startups, corporations, and research institutions, the lab provides a platform
for collaborative development and technology transfer. This includes co-supervised
student projects, internships, joint publications, and participation in national and
international innovation programs. The lab encourages entrepreneurship and sup-
ports the transformation of research outputs into viable products or services, rein-
forcing its role as a catalyst for innovation and technological advancement.

1.3.2 ESME Research Lab Location

The ESME Research Lab is located at the Paris campus of ESME Sudria, one of
France’s leading engineering schools. Situated in the heart of Paris, the lab benefits from
a vibrant academic environment and close proximity to numerous research institutions,
technology companies, and innovation hubs. This strategic location enables strong col-
laborations with both academic and industrial partners, enhancing the lab’s ability to
work on interdisciplinary projects that respond to current technological and societal chal-
lenges. The Paris campus also hosts state-of-the-art facilities, including robotics labs,
prototyping workshops, and digital platforms, providing students and researchers with
the infrastructure needed to carry out high-impact engineering work.

1.4 Project Overview

This section provides a detailed outline of our end-of-study project at the ESME Re-
search Lab. The project centers on the development of an advanced autonomous robot

5
Project Overview Chapter 1

prototype designed to locate and identify misplaced household objects. The section is
structured into five main parts: project context, problem statement, proposed solution,
objectives and requirements, and project constraints. By addressing each of these ele-
ments, we aim to clearly articulate the project’s goals, the technical challenges encoun-
tered, and the expected outcomes. This overview sets the stage for a deeper understanding
of the innovative approaches and technologies employed in the creation of a state-of-the-
art autonomous robotic system.

1.4.1 Project Context

The development of advanced autonomous robots involves integrating modern tech-

nologies to create systems capable of performing complex tasks without human interven-
tion. These robots are designed to operate independently in various environments such as
homes, factories, and healthcare facilities. They rely on onboard sensors to perceive their
surroundings, smart software to interpret data and make decisions, and robust control
systems to act accordingly. This level of autonomy allows them to perform tasks such
as navigation, object detection, and manipulation in dynamic and unstructured environ-
ments.

Our end-of-study project at the ESME Research Lab focuses on developing a fully
autonomous mobile robot capable of searching for misplaced objects, such as bottles, pails,
or everyday household items, within a home setting. Its autonomy is achieved through
the integration of several advanced technologies. We employ the ROS2 framework to
orchestrate system components and state-of-the-art computer vision algorithms, including
object detection using YOLO, to identify and locate target items. Additionally, onboard
sensors such as LIDAR, IMU and wheel encoders are used for obstacle avoidance and
accurate navigation.

This project showcases the feasibility and effectiveness of combining these technologies
into a single, self-sufficient robotic platform. The resulting prototype serves as a proof of
concept, demonstrating how autonomous systems can be designed to perform purposeful
tasks in real-world domestic environments. It also reflects our capability to innovate and
apply engineering knowledge in building intelligent robotic solutions.

6
Project Overview Chapter 1

Figure 1.3: General Project Architecture Diagram

Figure 1.3 illustrates the general architecture of our autonomous robot system that
integrates multiple technologies for seamless operation.

The architecture consists of a Mobile App with a User Interface that handles Task
Management, sending tasks to a Computer via WebSocket Server. The Computer’s Web-
Socket Server facilitates real-time communication, relaying tasks to the Control Logic,
which issues Commands to an Autonomous Robot. The Autonomous Robot provides
Status Updates back to the WebSocket Server, which are then transmitted to the Mobile
App for user monitoring and interaction.

• Mobile App: the mobile application includes a User Interface and Task Man-
agement, allowing users to send tasks to the Computer via WebSocket Server for
real-time interaction.

• Computer: this system hosts a WebSocket Server that receives tasks from the
Mobile App and forwards them to the Control Logic, while also relaying Status
Updates from the Autonomous Robot.

• Control Logic: tocated within the Computer, it processes tasks from the Web-
Socket Server and sends Commands to the Autonomous Robot to execute the as-
signed tasks.

• Autonomous Robot: this component receives Commands from the Control Logic
and sends Status Updates back to the WebSocket Server, enabling continuous mon-
itoring and control.

7
Project Overview Chapter 1

1.4.2 Project Statement

Designing a fully autonomous mobile robot capable of performing domestic tasks, such
as searching for misplaced items within a household environment, involves overcoming sev-
eral complex engineering challenges. This project focuses on developing such a robot with
a high degree of autonomy, capable of navigating and operating independently without
any external intervention or inter-robot communication.

One of the primary technical challenges addressed in this project is achieving accurate
and robust localization in indoor environments. Since traditional solutions like Global
Positioning System (GPS) are not applicable indoors, the robot relies on a sensor fusion
approach that combines data from wheel encoders, Inertial Measurement Units (IMUs),
and a 2D LiDAR. This fusion of proprioceptive and exteroceptive sensor data enables
precise real-time estimation of the robot’s pose (position and orientation), which is critical
for effective navigation and autonomous operation.

Autonomous navigation is another essential aspect of the system. The robot must
be capable of building and updating a map of its environment, planning paths, avoid-
ing obstacles, and systematically exploring areas to search for objects. These tasks are
computationally demanding and are therefore managed by a distributed processing archi-
tecture. Specifically, high-level navigation algorithms including Simultaneous Localization
and Mapping (SLAM), path planning, and global map handling, are executed on an ex-
ternal host PC running ROS2. Meanwhile, the onboard Raspberry Pi is responsible for
low-level motor control, sensor data acquisition, and command execution. This division
of labor optimizes system performance and ensures responsiveness during exploration and
search routines.

Precise motion control is critical for maintaining stability and accuracy during nav-
igation. To achieve this, the robot implements a closed-loop control strategy using an
adaptive fuzzy logic PID controller. This enhanced control method dynamically tunes
the PID gains in real time based on system behavior, improving response performance
and reducing steady-state errors under varying load conditions or surface properties. The
result is smoother, more accurate movements, which are essential for reliable localization
and object search.

Moreover, the robot’s system architecture is designed to be modular and extensible.

This allows for the integration of new hardware or software components in the future,
making the platform adaptable to a broader set of use cases beyond object search.

By addressing these challenges, the project demonstrates the feasibility of a fully au-
tonomous indoor robot that combines advanced sensor fusion, adaptive motion control,
reliable navigation, and efficient power management into a cohesive and functional pro-
totype.

8
Project Management Approach and Methodology Chapter 1

1.4.3 Proposed Solution

To address the challenges outlined in the problem statement, our proposed solution
involves the development of an advanced autonomous robot prototype that integrates
multiple modern technologies. This integration ensures that the robot can navigate au-
tonomously, communicate effectively, and operate continuously without human interven-
tion.

Figure 1.4: Robot Architecture Diagram

The diagram illustrates the architecture of the autonomous robot, detailing the main
unit, power unit, and radio unit, along with their interconnections.

1.5 Project Management Approach and Methodology

To ensure high-quality software delivery within a predictable timeline, selecting the

right development process is crucial. Given the project’s dynamic nature, the work is
divided into iterations, each focusing on a functional aspect of the autonomous indoor
mobile robot. The Agile SCRUM methodology is chosen for its adaptability to evolving
requirements and technical challenges.

9
Project Management Approach and Methodology Chapter 1

1.5.1 Agile Methodology

The Agile methodology is adopted for its adaptability and capacity to accommodate
shifting requirements. It prioritizes collaboration, quick responsiveness, and iterative
progress (as depicted in Figure 1.5). The fundamental Agile principles guiding this project
include:

1. Valuing working software over extensive documentation.

2. Favoring customer collaboration over strict contract adherence.

3. Embracing change over rigidly following a predetermined plan.

These principles, paired with a commitment to regular feedback and incremental ad-
vancements, help maintain project momentum while flexibly addressing new challenges
or adjustments.

Figure 1.5: Agile Methodology [3]

1.5.2 Scrum Framework

The Scrum framework, a widely recognized component of Agile, is chosen for its
straightforwardness and effectiveness in handling intricate projects. Key components of
the Scrum framework are illustrated in Figure 1.6.

10
Project Management Approach and Methodology Chapter 1

Figure 1.6: Scrum Methodology [4]

Application to the Project:

In developing the autonomous indoor mobile robot, the Scrum framework is imple-
mented with the following customizations:

• Project Timeline Tracking: A detailed timeline, as shown in Figure 1.7, outlines

the project steps, start and end dates, and current status, serving as a personal
management tool to monitor progress and plan tasks.

• Daily Self-Reviews: Daily self-assessments are conducted to evaluate progress,

identify obstacles, and outline the day’s objectives.

• Sprint Planning: Each sprint commences with a self-directed planning session to

prioritize tasks from the backlog, estimating their complexity and required time.

• Sprint Reviews and Reflections: At the conclusion of each sprint, a review is

held to showcase completed work and gather self-feedback. Reflections follow to
assess processes and implement enhancements for the upcoming sprint.

By leveraging Agile and Scrum, the development of the autonomous indoor mobile robot
is designed to be iterative, responsive to changes, and focused on delivering incremental
value. This approach promotes transparency, self-improvement, and adaptability, which
are crucial for the successful execution of a solo, complex project.

11
Conclusion Chapter 1

Figure 1.7: Project Timeline

1.6 Conclusion

In this chapter, we have established a foundation for understanding the key environ-
mental factors relevant to our project. We began by introducing the host organization,
ESME Research Lab, detailing its background, research focus, and facilities. This pro-
vided a clear picture of the lab’s capabilities and the resources available to support our
project. We then outlined the academic context, underscoring the importance of this
project as a pivotal part of our engineering studies at ENIS.

Additionally, we explored the larger scope of our project, focusing on the integration
of advanced technologies to develop an autonomous indoor mobile robot. By examining
the project’s context, we emphasized its significance and potential impact in domestic
applications, such as locating misplaced items with precision.

The project overview section offered a detailed narrative of our project’s objectives,
challenges, and anticipated outcomes. We analyzed the project statement, proposed solu-
tions, objectives, requirements, and constraints. This thorough overview laid the ground-
work for understanding the technical complexities and innovative strategies we are imple-
menting, including the use of ROS2, YOLO-based object detection, and adaptive control
systems.

Lastly, we described our project management approach and methodology, highlight-

ing the adoption of Agile and Scrum frameworks. These methodologies ensure that our
project development remains iterative, adaptable to evolving needs, and capable of de-
livering incremental value. By promoting transparency, self-reflection, and continuous
improvement, we are well-prepared to address the challenges of developing an advanced
autonomous robot as a solo endeavor.

In the next chapter, we will investigate the state of the art in autonomous robotics,
focusing on existing technologies and research that have influenced sensor integration,
object detection, and navigation algorithms. This exploration will provide the foundation
for the technical solutions and innovations we aim to implement in our project.

12
2 Robotics History

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Autonomous Robotics History . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Al-Jazari’s Hand-Washing Automaton (1206) . . . . . . . . . . . . . . . . 14
2.2.2 Leonardo da Vinci’s Mechanical Knight (1495) . . . . . . . . . . . . . . . 15
2.2.3 Jacques de Vaucanson’s Digesting Duck (1738) . . . . . . . . . . . . . . . 16
2.2.4 Charles Babbage’s Analytical Engine (1837) . . . . . . . . . . . . . . . . . 16
2.2.5 Walter’s "Tortoise" Robots (1949) . . . . . . . . . . . . . . . . . . . . . . 17
2.2.6 Shakey the Robot (1966–1972) . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.7 Clearpath Husky UGV (2013) . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.8 MiR100 Autonomous Mobile Robot (2016) . . . . . . . . . . . . . . . . . . 19
2.2.9 Boston Dynamics’ Advanced Robotics (2016) . . . . . . . . . . . . . . . . 19
2.3 Robot Operating System (ROS) . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Introduction and System Structure . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2 Key Development Tools in ROS . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3 Advantages of ROS for Autonomous Robotics . . . . . . . . . . . . . . . . 23
2.3.4 ROS vs. ROS2 vs. Alternative Methods . . . . . . . . . . . . . . . . . . . 24
2.4 Technologies in Autonomous Robots . . . . . . . . . . . . . . . . . . . . 26
2.4.1 Sensors and Perception Systems . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Localization and Mapping Techniques . . . . . . . . . . . . . . . . . . . . 28
2.4.3 Navigation and Path Planning . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.4 Motion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5 Communication Tools and Protocols in Embedded Systems . . . . . . 33
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

13
Introduction Chapter 2

2.1 Introduction

Autonomous robotics has seen remarkable progress over recent decades, driven by
advancements in technology, computing, and AI. This chapter provides an in-depth ex-
ploration of the current state-of-the-art, highlighting key technologies, methodologies, and
influential projects that shape the field. It examines the core components—sensors, actu-
ators, and algorithms—that enable robots to perceive, navigate, and interact with their
environments, while also addressing challenges, constraints, and future trends.

Autonomous robots are sophisticated machines designed to operate independently,

relying on sensors, actuators, and intelligent algorithms. They enhance productivity,
safety, and efficiency across industries like manufacturing, healthcare, agriculture, and
logistics, with growing demand underscoring the need for robust systems.

The chapter begins with a historical overview of autonomous robotics, tracing its
evolution from early innovations to modern applications. It then delves into foundational
technologies, including sensors and perception, localization and mapping, navigation and
path planning, communication protocols, and motion control, with a focus on the pivotal
role of ROS in system development and integration.

This analysis aims to offer a comprehensive understanding of current technologies

and applications, laying the groundwork for innovative solutions in subsequent chap-
ters. It also underscores the importance of addressing technical, ethical, and social chal-
lenges—such as safety, reliability, interoperability, privacy, and employment impacts—to
foster responsible innovation and unlock robotics’ potential to improve quality of life.

2.2 Autonomous Robotics History

The history of autonomous robotics traces key milestones in creating self-operating

machines, influencing modern innovations like this project’s robot.

2.2.1 Al-Jazari’s Hand-Washing Automaton (1206)

In 1206, Ismāil al-Jazari engineered a life-sized hand-washing automaton detailed in

his Book of Knowledge of Ingenious Mechanical Devices, which used hydraulic power,
cams, and valves to autonomously dispense water, soap, and towels in a timed sequence
[5, 6]. This device combined artistry with mechanical precision: pulling a lever initiated
water flow from a brass pitcher, while a float-actuated valve regulated the refill cycle.

Al-Jazari’s automaton established foundational principles of programmable actuation

14
Autonomous Robotics History Chapter 2

Figure 2.1: Al-Jazari’s hand-washing automaton (1206).

and sequential control, inspiring later mechanical clocks and automata in European work-
shops and presaging modern robotics’ emphasis on integrating sensing and timed actua-
tion.

2.2.2 Leonardo da Vinci’s Mechanical Knight (1495)

Around 1495, Leonardo da Vinci designed a humanoid automaton known as the "Me-
chanical Knight" in Italy. This early robot could sit, wave its arms, and move its head
and jaw through a sophisticated system of pulleys and gears. While it remains uncertain
whether da Vinci constructed a fully functional model, modern reconstructions based on
his sketches have validated its design and demonstrated its operational potential [7, 8].

The Mechanical Knight represents one of the earliest conceptual designs for a hu-
manoid automaton, illustrating the integration of mechanical engineering and artistic
vision, and laying a foundation for later developments in robotics and automation.

15
Autonomous Robotics History Chapter 2

Figure 2.2: Leonardo da Vinci’s Mechanical Knight (1495).

2.2.3 Jacques de Vaucanson’s Digesting Duck (1738)

In 1738, French inventor Jacques de Vaucanson created the "Digesting Duck," a lifelike
automaton that could flap its wings, eat grain, and excrete waste, simulating the process
of digestion. This mechanical duck showcased remarkable realism and complexity, using
a system of internal mechanisms to mimic biological processes [9].

Figure 2.3: Jacques de Vaucanson’s Digesting Duck (1738).

Vaucanson’s work advanced the field of automata by demonstrating how mechanical

systems could replicate lifelike behaviors, influencing the development of more sophisti-
cated robotic mechanisms in the centuries that followed.

2.2.4 Charles Babbage’s Analytical Engine (1837)

In 1837, Charles Babbage designed the Analytical Engine, a mechanical general-

purpose computer that, while not an automaton, laid foundational concepts for comput-
ing. Assisted by Ada Lovelace, who wrote what is considered the first computer program
for the machine, the Analytical Engine was envisioned to perform any calculation or data
processing task through a system of punched cards and mechanical operations [10].

16
Autonomous Robotics History Chapter 2

Figure 2.4: Charles Babbage’s Analytical Engine (1837).

Although never fully constructed, the Analytical Engine introduced principles of pro-
grammability and data processing that would later influence the development of modern
computing systems, indirectly impacting robotics through advancements in control and
computation.

2.2.5 Walter’s "Tortoise" Robots (1949)

In 1949, neurophysiologist W. Grey Walter built Elmer and Elsie, simple three-wheeled
robots powered by analog circuits modeling two-neuron networks. Equipped with light
and touch sensors, they exhibited phototaxis and obstacle avoidance behaviors, wandering
and interacting with their environment without human intervention [11, 12].

Figure 2.5: Grey Walter’s Elmer and Elsie "tortoise" robots (1949).

Walter’s tortoises demonstrated that simple reactive circuits could yield emergent au-
tonomous behavior, laying the groundwork for behavior-based robotics and subsumption
architectures still used in mobile robot design.

17
Autonomous Robotics History Chapter 2

2.2.6 Shakey the Robot (1966–1972)

From 1966 to 1972, SRI International’s Shakey was the first mobile robot integrating
perception, reasoning, and action. With onboard cameras, range finders, and the STRIPS
planning system, Shakey could analyze its environment, formulate plans, and execute
tasks such as stacking boxes [13, 14].

Figure 2.6: Shakey the Robot at SRI International (1966–1972).

Shakey’s layered architecture, separating perception, planning, and control, became a

blueprint for cognitive robotics and artificial intelligence in autonomous systems, influ-
encing research on robot planning, SLAM, and multi-agent coordination.

2.2.7 Clearpath Husky UGV (2013)

Since its introduction in 2013, the Clearpath Husky Unmanned Ground Vehicle (UGV)
has served as a versatile field robotics platform. Deployed in agriculture, environmental
monitoring, and research, it demonstrated how robust hardware and software ecosystems
could bring autonomy to real-world outdoor tasks [15].

Figure 2.7: Clearpath Husky UGV in outdoor environments (2013).

18
Autonomous Robotics History Chapter 2

Husky bridged laboratory research and industrial applications, showing that scalable,
rugged robotic platforms could operate autonomously outside controlled settings.

2.2.8 MiR100 Autonomous Mobile Robot (2016)

Launched in 2016 by Mobile Industrial Robots, the MiR100 marked a significant mile-
stone in industrial automation by introducing the concept of autonomous mobile robots
(Autonomous Mobile Robot (AMR)) in warehouse environments. With a payload capac-
ity of up to 100 kg, it could navigate autonomously without relying on any additional
infrastructure [16, 17].

Figure 2.8: MiR100

As the first dependable and commercially viable AMR platform, the MiR100 played
a pivotal role in shaping the evolution of flexible robotic fleets in logistics. It laid the
groundwork for the modern development of AGV and AMR systems used today.

2.2.9 Boston Dynamics’ Advanced Robotics (2016)

Since its founding in 1992, Boston Dynamics has become a leader in advanced robotics,
with significant contributions starting around 2016 with the introduction of robots like
Spot and Atlas. Spot, a quadruped robot launched in 2016, can navigate uneven terrain,
climb stairs, and perform inspection tasks in industrial settings, while Atlas, a bipedal hu-
manoid, demonstrates dynamic capabilities like running, jumping, and performing back-
flips, thanks to advanced control algorithms and hydraulic actuation [18, 19]. These robots
integrate perception, navigation, and manipulation, showcasing the potential for highly
mobile and adaptable robotic systems.

Boston Dynamics’ innovations have pushed the boundaries of robotic mobility and
human-robot interaction, influencing applications in search and rescue, construction, and
entertainment, and setting new standards for autonomous robotic performance in un-
structured environments.

19
Robot Operating System (ROS) Chapter 2

Figure 2.9: Boston Dynamics’ Spot and Atlas robots.

2.3 Robot Operating System (ROS)

The Robot Operating System (ROS) serves as a foundational framework for robotics
development, enabling modular and scalable solutions critical to autonomous systems.

2.3.1 Introduction and System Structure

The Robot Operating System, commonly referred to as ROS, is an open-source frame-

work designed to streamline the development of software for robotic systems. Initially
introduced in 2007 at Willow Garage, it has grown to become a foundational middleware
platform in the field of robotics [20, 21]. ROS provides a robust ecosystem composed of
libraries, tools, and design patterns that promote efficient and modular development for
a wide range of robotic applications.

At its core, ROS organizes functionality into distributed processes called nodes, which
communicate through a graph-based structure. Nodes exchange information via named
topics for continuous data streams, services for synchronous communication, and actions
for long-duration tasks [21]. These elements are grouped into packages that can be reused
and shared across different projects.

Figure 2.10 illustrates a basic example where two nodes, talker and listener, in-
teract through a topic named chatter. In this setup, one node publishes messages that
the other subscribes to, demonstrating the modular and asynchronous nature of ROS
communication.

20
Robot Operating System (ROS) Chapter 2

Figure 2.10: General structure of ROS communication between nodes [20].

2.3.2 Key Development Tools in ROS

The ROS ecosystem includes several essential tools that facilitate simulation, visual-
ization, and system management during development:

• RViz: This tool enables real-time 3D visualization of data from sensors and robot
states, providing developers with a comprehensive view for debugging and monitor-
ing [20].

Figure 2.11: RViz logo

21
Robot Operating System (ROS) Chapter 2

Figure 2.12: Interface of RViz in action

• Gazebo: This high-fidelity simulation tool works in tandem with ROS to test and
refine robotic algorithms in a virtual environment, replicating real-world physics
and sensor data [20].

Figure 2.13: Gazebo logo

Figure 2.14: Simulation in Gazebo environment

22
Robot Operating System (ROS) Chapter 2

• tf2: This utility handles coordinate frame transformations over time, which is vital
for spatial awareness in robotic operations such as navigation or manipulation [20,
22].

Figure 2.15: tf visualization example

[23]

These tools collectively enable thorough testing and debugging, significantly improv-
ing development efficiency and system reliability by reducing dependency on physical
hardware early in the development lifecycle.

2.3.3 Advantages of ROS for Autonomous Robotics

Implementing ROS in autonomous systems development provides several advantages:

• Modular Design: The architecture supports building software components that

are both reusable and independent, accelerating system integration and facilitating
code sharing [20].

• Extensive Community Resources: The large user base of ROS contributes to

a vast repository of documentation, tutorials, and third-party packages, which is a
valuable resource for troubleshooting and development [21].

• Advanced Simulation Capabilities: Tools like Gazebo and RViz allow for high-
fidelity simulation and real-time visualization, ensuring algorithms are well-tested
before real-world deployment [20].

• Cross-Platform Compatibility: ROS supports integration with a wide variety

of hardware and software systems, making it adaptable to diverse robotic platforms
and tasks [21].

23
Robot Operating System (ROS) Chapter 2

• Flexible and Scalable Architecture: Whether for academic research or indus-

trial deployment, ROS scales effectively, supporting both simple projects and com-
plex multi-robot systems [24].

2.3.4 ROS vs. ROS2 vs. Alternative Methods

Our project employs ROS2, which stands out as a leading framework among various
options for autonomous robotics, offering significant enhancements over its predecessor,
ROS, as well as simpler alternatives commonly used in the field. Below, we compare ROS,
ROS2, and other notable methods to highlight why ROS2 is the optimal choice for our
system, particularly for the complex task of searching for lost items.

• System Performance: ROS2 delivers superior performance with optimized com-

munication protocols and resource management, ideal for large-scale applications
like our robot’s search tasks. ROS handles smaller systems adequately, while alter-
natives like Raspberry Pi-based custom solutions or LabVIEW setups often struggle
with efficiency under heavy loads, making ROS2 the strongest performer [24].

• Real-Time Operation: ROS2 introduces robust real-time execution support, cru-

cial for time-sensitive tasks like navigation and object detection, surpassing ROS’s
minimal capabilities. In contrast, simpler methods like Arduino-based control loops
or custom microcontroller scripts offer basic timing but lack the precision and pre-
dictability of ROS2’s real-time framework [24].

• Multi-Robot Capabilities: ROS2 excels with enhanced inter-robot communica-

tion and synchronization, perfect for collaborative tasks, which could enhance future
search operations. ROS offers limited multi-robot support, and simpler methods like
individual microcontroller networks or basic Bluetooth coordination lack the robust
features that ROS2 provides for swarm robotics [24].

• Lifecycle Management and QoS: ROS2 includes lifecycle states and Quality of
Service (QoS) policies, enabling robust and configurable system behavior, which is
vital for our robot’s reliability. ROS lacks these features, and alternative approaches
like ad-hoc scripting or proprietary embedded systems offer no comparable lifecycle
or QoS support, reinforcing ROS2’s advantage [22].

• Security Enhancements: ROS2 provides advanced security features, including

message encryption, node authentication, and access control, far exceeding ROS’s
basic security measures. Alternative approaches, such as direct serial communica-
tion or basic Python scripts, typically lack any security protocols, making them
vulnerable [24].

• Middleware Options: Unlike ROS, which relies on a proprietary middleware,

ROS2 offers flexibility with options like DDS as the default, enhancing scalabil-
ity and performance. Simpler methods, such as standalone C/C++ programs or
MATLAB scripts, use fixed middleware or none at all, limiting their adaptability
compared to ROS2’s versatile architecture [24].

24
Robot Operating System (ROS) Chapter 2

• Community and Ecosystem: ROS2 benefits from an expanding community and

rich ecosystem, building on ROS’s well-established base, offering valuable support
for our development. Simpler methods, such as open-source micro-controller frame-
works (e.g., PlatformIO) or vendor-specific tools, have smaller communities and
fewer resources, making ROS2 more supportive [21].

Table 2.1: Comparison of ROS, ROS2, and Alternative Approaches

Feature ROS ROS2 Alternative
Approaches (e.g.,
Arduino, Custom
Scripts)
System Efficiency Suitable for Designed for Often struggles with
smaller setups high-demand heavy workloads
tasks
Timing Precision Basic real-time Strong Limited, lacks accuracy
features real-time
capabilities
Collaborative Minimal Advanced syn- Little to no support
Features multi-robot chronization
support
Communication No QoS Comprehensive Not applicable
Reliability options QoS features
Data Security Simple Robust (e.g., Mostly absent
protections encryption,
access control)
Communication Fixed Adaptable Rigid or nonexistent
Layer proprietary (e.g., DDS)
system
Lifecycle Oversight Not available Well- Unsupported
implemented
Growth Potential Fits small to Highly Limited scalability
mid-sized expandable
tasks
Design Flexibility Strongly Strongly Restricted, task-focused
modular modular
Developer Resources Large, Rapidly Small, scattered
established growing support
network community

Thanks to these superior features, ROS2 has empowered our system to achieve ex-
ceptional performance and robustness, perfectly aligning with the intricate demands of
modern autonomous robotic applications like ours. Its advanced capabilities outshine
both ROS and simpler alternatives, making it the best choice for integrating the robot’s
diverse hardware and software components effectively.

25
Technologies in Autonomous Robots Chapter 2

2.4 Technologies in Autonomous Robots

This section provides an overview of the core technologies driving the development of
autonomous robots, with a focus on their application in the context of our indoor mobile
robot project. We will examine key components such as sensor integration, navigation
systems, and object detection, highlighting how these technologies enable the robot to
operate independently and efficiently in dynamic environments.

2.4.1 Sensors and Perception Systems

Autonomous robots designed to search for lost household items depend on a range of
sensors to understand their indoor surroundings. These sensors gather the information
needed for the robot to navigate, avoid obstacles, and locate items like phones or keys.
Key types of sensors in this project include LiDAR, cameras, encoders, and potential
future additions like IMUs and ultrasonic sensors.

Types of Sensors:

• LiDAR (Light Detection and Ranging): The robot uses a YDLIDAR TSA, a
LiDAR sensor that measures distances by sending out laser pulses and timing their
return after bouncing off objects. This time-of-flight method helps create accurate
maps of the environment, which can be two-dimensional (2D) or three-dimensional
(3D) depending on the LiDAR model. The YDLIDAR TSA is particularly helpful
for mapping indoor spaces, detecting obstacles, and aiding navigation with its precise
and detailed measurements. While some LiDAR systems focus on 2D maps, which
are often enough for basic navigation and obstacle avoidance, others can produce
3D maps for more complex tasks.

Figure 2.16: YDLIDAR TSA sensor.

• Cameras: Cameras capture visual information, which is processed using the YOLO11n
model to identify and classify objects, recognize patterns, and understand indoor

26
Technologies in Autonomous Robots Chapter 2

settings. For this project, a Logitech StreamCam captures images at 640x480 reso-
lution (with plans to adjust to 128x128 for better performance). These visuals are
essential for detecting lost items like phones or remotes and supporting navigation,
often working alongside other sensors to provide a fuller picture.

Figure 2.17: Logitech StreamCam used for object detection.

• Encoders: Encoders track the position, speed, and direction of the robot’s wheels,
offering important data for motion control to ensure accurate movement and posi-
tioning. They come in two types: incremental encoders, which produce signals with
each wheel turn for relative positioning that needs a starting point, and absolute
encoders, which give a unique signal for each position, ensuring precise tracking
without a reference. Absolute encoders are especially useful for the robot’s need to
move reliably while searching for items.
• Ultrasonic Sensors: Ultrasonic sensors detect objects by sending out sound waves
and measuring the time it takes for the echoes to return, thus calculating distances.
These sensors are considered for simple obstacle detection and avoidance due to their
affordability and ease of use, potentially improving the robot’s ability to navigate
safely through cluttered indoor spaces.

Figure 2.18: Ultrasonic sensor for obstacle avoidance [25].

• IMUs: An Inertial Measurement Unit (IMU) combines accelerometers, gyroscopes,

and sometimes magnetometers to provide data on the robot’s tilt, speed, and grav-

27
Technologies in Autonomous Robots Chapter 2

itational effects. Accelerometers track straight-line movement, gyroscopes measure

turns, and magnetometers provide direction based on magnetic fields. This combi-
nation allows for accurate tracking of the robot’s motion and orientation indoors.
The IMU data could help keep the robot stable and on course while searching,
and advanced techniques like sensor fusion might blend it with LiDAR and camera
inputs to improve overall awareness and decision-making.

• Key Differences between Sensors:

– Data Type: LiDAR offers mapping data, cameras provide visual clues for item
detection, encoders track movement, ultrasonic sensors measure distances, and
IMUs monitor orientation.
– Environmental Sensitivity: LiDAR and cameras may struggle with poor
lighting or obstructions, ultrasonic sensors can be affected by soft surfaces,
IMUs might drift over time, while encoders remain consistent with wheel data.
– Resolution and Range: LiDAR and cameras provide detailed spatial data,
ultrasonic sensors offer short-range detection, IMUs focus on motion, and en-
coders ensure precise movement tracking.
– Use Case Fit: LiDAR excels in mapping, cameras are key for spotting items,
encoders ensure accurate movement, ultrasonic sensors aid in obstacle avoid-
ance, and IMUs support navigation stability.

2.4.2 Localization and Mapping Techniques

This part delves into the critical techniques of localization and mapping, which are
essential for enabling the autonomous indoor mobile robot to navigate and understand
its environment. We will explore how these methods allow the robot to determine its
position accurately and construct a reliable map of its surroundings.

• SLAM: SLAM methods allow robots to create a map of an unfamiliar space while
figuring out their own position within it. This is especially important for navigating
indoors, where GPS signals aren’t available. In ROS2, there are several well-known
SLAM options that could suit this project, though they are not yet fully imple-
mented:

– Gmapping: Gmapping is a popular SLAM method that uses particle filters

to build a 2D grid map. It relies on data from the YDLIDAR TSA and wheel
encoders to work well. Gmapping is a good fit for small, organized spaces like
homes, making it ideal for this robot searching for lost items. It’s simple and
dependable, which makes it a great choice for starting with SLAM in ROS2,
offering enough mapping accuracy for controlled indoor settings [26].
– ROS2 Localization: This approach combines data from the YDLIDAR TSA,
wheel encoders, and a potential future IMU to determine the robot’s exact
position. By fusing these inputs, it provides a reliable way to track the robot’s
location in real-time, perfect for navigating indoor spaces while searching for

28
Technologies in Autonomous Robots Chapter 2

items. This method enhances accuracy and adaptability, making it a strong fit
for the robot’s needs [26].
– Cartographer: Developed by Google, Cartographer can handle both 2D and
3D SLAM, using laser scans from the YDLIDAR TSA and potentially data
from an IMU in the future. This makes it strong and able to manage complex
indoor spaces, like homes with lots of furniture. Cartographer is great for
detailed mapping and is known for being accurate and reliable [27].
– SLAM Toolbox: SLAM Toolbox is a flexible package that supports both live
and pre-recorded SLAM. It offers features like lifelong mapping, which lets the
robot update its map over time, and tools to combine maps. It’s very reliable
and works well for various tasks, from small homes to more cluttered spaces,
making it a solid option for the robot’s search mission [26].

• Real-Time Object Tracking: The robot tracks objects in real-time using a cus-
tom ROS 2 setup that processes data from the Logitech StreamCam. By detecting
items like remotes or laptops with YOLO11n, the robot can adjust its search path
on the go. This ability is key for a robot tasked with finding lost items, ensuring it
can respond quickly to new detections while exploring a home [28].

2.4.3 Navigation and Path Planning

• Introduction to the NAV2 Stack:

Figure 2.19: NAV2 Stack Logo [29]

The NAV2 stack is a powerful navigation framework crafted for ROS2. It offers
a collection of tools and features to help robots navigate on their own, supporting
tasks like mapping, localization, path planning, and movement control. Built on
ideas from the original ROS navigation system, NAV2 adds improvements and new
capabilities that make it well-suited for today’s robotic projects, such as searching
for lost items in a home.
Key features of the NAV2 stack include:
– A flexible design that can be easily adjusted and expanded, fitting different
robot setups.

29
Technologies in Autonomous Robots Chapter 2

– Support for smart path planning methods and movement controllers, perfect
for navigating tricky indoor spaces.
– Better performance and dependability thanks to improved system connections,
ensuring a steady and strong setup.
– Helpful tools for testing, viewing progress, and solving issues, making develop-
ment and testing easier [29–31].

• Algorithms:

– A-Star (A*): A* is a well-known algorithm for finding the shortest path from
a starting point to a goal in a map, using clever guesses to work faster. It’s
often used in robots like this one to plan efficient routes through a home. In the
ROS2 NAV2 stack, A* is part of the Smac Planner for overall path planning,
supporting different movement styles like Dubins or 2D Moore [30].
– Dijkstra: Dijkstra’s algorithm finds the shortest routes between points in a
map, making it great for steady path planning without relying on guesses.
It’s used in the ROS2 NAV2 stack for reliable overall planning when accuracy
matters most [31].
– Rapidly-exploring Random Tree (RRT): RRT explores spaces by ran-
domly growing a tree, which works well in complicated areas. It’s helpful for
planning paths in busy or dynamic indoor settings. The RRT and its improved
versions, like RRT*, are part of the ROS2 NAV2 stack for tackling tough nav-
igation tasks where simpler methods might not work [32].
– Smac Planner: The Smac Planner is a versatile tool in the ROS2 NAV2 stack,
offering options like hybrid A* and state lattice planning. It’s built to handle
different movement styles and delivers strong performance for various robot
tasks. The Smac Planner can plan both overall routes and smaller adjustments,
making it a key part of the NAV2 system [30].

• Motion Planning and Obstacle Avoidance: Motion planning means finding a

practical path for the robot to follow to reach its target, considering how it moves.
Obstacle avoidance ensures the robot can steer clear of objects in real-time while
searching for items. Methods used in the ROS2 NAV2 stack include:

– Dynamic Window Approach (DWA): DWA is a close-range planning

method that looks at the robot’s possible speeds and paths within a set range.
It picks the best route based on factors like movement rules, how close obstacles
are, and the direction of the goal, allowing for smooth navigation and real-time
obstacle dodging [30].
– Regulated Pure Pursuit Controller: This controller helps the robot follow
a planned path by adjusting its speed and direction, keeping it steady while
avoiding obstacles. It’s especially useful for navigating through busy home
settings where furniture or other items might be in the way [31].

30
Technologies in Autonomous Robots Chapter 2

2.4.4 Motion Control

Motion control is a critical aspect of autonomous robotics, ensuring precise movement

and stability, which are essential for autonomous robot navigation and operation.

• Overview of Motion Control Techniques: Motion control involves guiding the

movement of robots and machines by carefully managing their actuators. This is
vital to achieve precise positioning, control speed, and ensure smooth operation.
Motion control plays a key role in robots like this one that search for lost items,
as well as in industrial robots, Computer Numerical Control (CNC) machines, and
automated guided vehicles (AGV). These systems rely on various sensors and con-
trollers to deliver accurate and efficient movement [33, 34].

• Fuzzy Logic PID Controllers and Their Applications: The robot uses a fuzzy
logic PID controller to keep its movements on target by adjusting for differences
between the intended and actual positions. This approach blends the traditional PID
method—using proportional, integral, and derivative terms to correct errors with
fuzzy logic to handle uncertain conditions. In this project, it ensures precise control
of motor speed, position, and orientation while navigating indoor spaces to find
items like phones or keys. This combination is especially valuable for maintaining
stability and accuracy in dynamic home settings [33, 35].

Figure 2.20: Diagram of a PID control system with fuzzy logic enhancements [36].

• Encoders and Feedback Systems: Encoders are essential parts of the motion
control setup, offering feedback on the position, speed, and direction of the robot’s
wheels. They work alongside the fuzzy logic PID controller to ensure accurate
movement. There are two main types: incremental encoders, which provide relative
position data based on wheel turns and need a starting point, and absolute encoders,
which give a unique signal for each position within a full rotation or movement,
ensuring continuous tracking without a reference.
Encoders produce signals to show the direction and extent of movement. Typically,
they generate two signals (A and B) with a 90-degree phase difference, which helps

31
Technologies in Autonomous Robots Chapter 2

determine the rotation direction based on the signal sequence. As shown in Figure
4.3, Hall sensors are used to create these quadrature signals.

Figure 2.21: Rotary encoder with Hall sensors [37].

Figure 2.22: Clockwise and Counter-Clockwise operation of encoders [38].

• Speed Controllers: Speed controllers are used to regulate the angular speed of
motors in motion control systems. They work by adjusting the voltage or cur-
rent supplied to the motor based on the feedback received from encoders. These
controllers are implemented using PID controllers, which utilize feedback from en-
coders to maintain the desired angular speed. Speed controllers are crucial in ap-

32
Communication Tools and Protocols in Embedded Systems Chapter 2

plications where precise speed regulation is needed, such as in Automated Guided

Vehicles (AGVs) and industrial robots [33, 35].

2.5 Communication Tools and Protocols in Embedded

Systems

In embedded systems, communication protocols are crucial for facilitating data ex-
change between the robot’s components and devices. These protocols ensure reliable,
efficient, and timely communication, which is vital for the robot’s performance and sta-
bility while searching for lost items in a home. Below, we explore the key protocols
relevant to this project, focusing on their unique specifications, roles, and applicability to
the robot’s operations:

• Universal Asynchronous Receiver-Transmitter (UART):

– Asynchronous Operation: UART operates without a shared clock signal,

relying instead on predefined baud rates to synchronize data transmission be-
tween devices, making it simple but requiring careful configuration.
– Data Frame Structure: It uses a frame format that includes a start bit, 5
to 9 data bits, an optional parity bit for error checking, and one or two stop
bits, ensuring straightforward data packaging.
– Transmission Speed: UART typically supports baud rates from 300 to
115,200 bps, suitable for low to moderate-speed communication in this project,
such as basic serial debugging on the Raspberry Pi.
– Error Detection: It can employ parity bits for basic error detection, though
it lacks advanced error correction, which may require additional software checks
for reliability.

• Inter-Integrated Circuit (I2C):

– Two-Wire Interface: I2C uses just two lines—SDA for data and SCL for
clock—allowing for a compact setup to connect multiple devices on a single
bus.
– Communication Speed: It supports speeds up to 400 kbps in standard
mode, with faster modes (up to 5 Mbps) available in some implementations,
sufficient for connecting sensors in this project.
– Device Addressing: Each device on the bus has a 7-bit or 10-bit address,
enabling up to 128 or 1024 devices to share the same bus, which is useful for
adding a potential IMU or other sensors.
– Acknowledge Mechanism: After each byte, the receiver sends an acknowl-
edgment bit, ensuring data integrity during transmission, which is critical for
reliable sensor data collection.

33
Communication Tools and Protocols in Embedded Systems Chapter 2

• Serial Peripheral Interface (SPI):

– Four-Wire Setup: SPI uses four lines—MISO (Master In Slave Out), MOSI
(Master Out Slave In), SCLK (clock), and CS (chip select)—offering a full-
duplex communication channel for faster data transfer.
– High-Speed Capability: It can achieve speeds up to 10 Mbps or more,
depending on the hardware, making it suitable for quick data exchanges with
components like the YDLIDAR TSA.
– Clock Polarity and Phase: SPI allows configuration of clock polarity (CPOL)
and phase (CPHA), providing flexibility to match the timing requirements of
different peripherals.
– Simultaneous Read/Write: Its full-duplex nature enables simultaneous
sending and receiving of data, which enhances efficiency when communicat-
ing with high-speed devices.

• Controller Area Network (CAN):

– Message-Based Communication: Controller Area Network (CAN) uses a

message-oriented protocol where data is transmitted in frames with identifiers
(11-bit or 29-bit), allowing prioritized message delivery without device-specific
addressing.
– Data Rate Flexibility: It supports data rates up to 1 Mbps for standard
CAN, with CAN FD (Flexible Data Rate) extending this to 8 Mbps, suitable
for high-speed, robust communication.
– Error Handling: CAN includes built-in error detection mechanisms like CRC
checks, bit stuffing, and acknowledgment, ensuring high reliability in noisy
environments.
– Bus Arbitration: It employs a non-destructive arbitration method using
message priority, allowing multiple nodes to compete for bus access without
data collisions.

• Ethernet:

– Layered Protocol Stack: Ethernet operates within the OSI model’s data
link and physical layers, using standards like IEEE 802.3 to manage high-speed,
structured data transfer.
– Speed Variants: It supports speeds from 10 Mbps to 10 Gbps or higher,
depending on the implementation, making it ideal for applications requiring
substantial data throughput.
– Frame Format: Ethernet frames include source and destination MAC ad-
dresses, a type field, payload (46-1500 bytes), and a CRC for error checking,
ensuring structured and reliable data packets.
– Network Scalability: It supports large-scale networks through switches and
routers, enabling complex setups with many devices communicating over long
distances.

34
Communication Tools and Protocols in Embedded Systems Chapter 2

Table 2.2: Advantages and Disadvantages of Communication Protocols

Protocol Advantages Disadvantages
UART Simple setup with minimal wiring Limited speed (up to 115,200 bps);
(two lines: TX and RX); widely sup- no advanced error correction; sus-
ported across devices; suitable for ceptible to noise over long distances;
short-distance, low-speed communi- supports only two devices without
cation like debugging. additional hardware.
I2C Compact two-wire interface (SDA, Slower speed (up to 5 Mbps); po-
SCL); supports multiple devices (up tential for bus contention with many
to 128 or 1024 with addressing); devices; limited cable length (about
efficient for sensor networks with 10 meter at high speeds).
acknowledgment-based reliability.
SPI High-speed capability (up to Requires more wires (four lines); no
10 Mbps or more); full-duplex built-in device addressing, requir-
communication for simultaneous ing individual chip select lines; less
read/write; flexible clock configura- suited for long-distance communica-
tion (CPOL, CPHA). tion (< 1 meter).
CAN Robust error handling (CRC, bit Complex setup with additional
stuffing, acknowledgment); high re- hardware (transceivers); higher cost;
liability in noisy environments; flex- limited to short network lengths
ible data rates (up to 8 Mbps with (about 40 meters at 1 Mbps).
CAN FD); supports message priori-
tization.
Ethernet High-speed options (10 Mbps to 10 Requires more complex hardware
Gbps); scalable for large networks and wiring; higher power consump-
with switches/routers; robust error tion; overkill for simple, low-speed
checking with CRC; long-distance applications.
capability.

35
Conclusion Chapter 2

2.6 Conclusion

The landscape of autonomous robotics, particularly for applications like searching for
lost household items, showcases impressive advancements and a wide range of technologies
that collectively elevate robotic performance. This section has provided a detailed exami-
nation of the core components and strategies that enable this robot to function effectively,
covering sensors and perception systems such as the YDLIDAR TSA and Logitech Stream-
Cam, localization and mapping approaches like SLAM paired with YOLO11n-based vision
tracking, navigation and path planning through the ROS2 NAV2 stack, communication
protocols including UART and I2C, and motion control techniques driven by a fuzzy logic
PID controller. Each of these aspects plays an indispensable role in allowing the robot to
operate independently and proficiently in indoor settings.

Reflecting on the historical journey of autonomous robotics, we see a progression from

basic mechanical devices in the Middle Ages, like Al-Jazari’s 13th-century water-powered
automata, to pioneering 20th-century innovations such as Grey Walter’s tortoise robots
that demonstrated emergent behavior in the 1940s, and the Unimate robotic arm that
revolutionized industrial automation in the 1960s. These milestones paved the way for
modern systems like the one developed in this project, which leverages advanced sensors
and software to address everyday challenges. This evolution underscores how each era’s
breakthroughs have built toward today’s sophisticated robotic solutions.

The incorporation of cutting-edge tools like AI and Machine Learning (ML) continues
to expand the robot’s capabilities, enabling it to adapt to its environment, handle new
tasks, and operate with increased intelligence and autonomy. Emerging trends, such as
the potential for robots to collaborate in teams or work alongside humans, suggest a future
where this robot could enhance its search efficiency through cooperative strategies.

However, the path forward is not without obstacles. Technical challenges, including
the need for precise sensor data, efficient real-time processing, and seamless system inte-
gration, must be addressed to ensure the robot’s dependability and safety. Additionally,
ethical and societal issues, such as protecting user privacy and managing the robot’s role
in daily life, require thoughtful consideration as it becomes more integrated into homes.

In the future, developments like enhanced multi-robot coordination, more compact

designs, and cost-effective solutions could broaden the scope of this robot’s applications.
Continued collaboration among researchers, developers, and industry professionals will be
essential to navigate these challenges and unlock new possibilities.

36
3 Software Development of Autonomous
Robot

3.1 Introduction to the Robot Development Process . . . . . . . . . . . . . 39

3.2 Concept Development and Initial Design . . . . . . . . . . . . . . . . . 39
3.3 Proposed Modeling and Robot Description . . . . . . . . . . . . . . . . 40
3.3.1 Introduction to URDF and Xacro . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2 Designing the Robot’s Physical Model . . . . . . . . . . . . . . . . . . . . 41
3.3.3 Integrating Sensors and Actuators . . . . . . . . . . . . . . . . . . . . . . 41
3.3.4 Transformations and Their Applications . . . . . . . . . . . . . . . . . . . 42
3.3.5 Validation of URDF Model . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Simulation Environment Development . . . . . . . . . . . . . . . . . . . 43
3.4.1 Selection and Setup of Simulation Tools . . . . . . . . . . . . . . . . . . . 43
3.4.2 Creating the Virtual Environment . . . . . . . . . . . . . . . . . . . . . . 44
3.4.3 Importing and Configuring the URDF Model . . . . . . . . . . . . . . . . 44
3.4.4 Initial Simulation Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.1 Essential ROS2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.2 Launch Files and Configuration . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.3 Robot Localization in Simulation . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.4 Mapping in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6 Navigation System Implementation . . . . . . . . . . . . . . . . . . . . . 49
3.6.1 Initialization and Coordination: . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.2 Global Path Planning: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6.3 Local Path Planning and Obstacle Avoidance: . . . . . . . . . . . . . . . . 50
3.6.4 Costmap Management: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

37
 Chapter 3

3.6.5 Behavior Execution and State Management: . . . . . . . . . . . . . . . . . 53

3.6.6 Control and Command Execution: . . . . . . . . . . . . . . . . . . . . . . 53
3.6.7 Transform Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.6.8 Feedback and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.7 Search Mechanism and Custom Search Algorithm . . . . . . . . . . . . 55
3.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.2 Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.3 Algorithm Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7.4 Complexity Analysis and Interpretation . . . . . . . . . . . . . . . . . . . 57
3.7.5 Algorithm Implementation Details . . . . . . . . . . . . . . . . . . . . . . 58
3.7.6 Coverage Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.8 YOLO Model Integration for Object Detection . . . . . . . . . . . . . 60
3.8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.8.2 Model Selection and Comparison . . . . . . . . . . . . . . . . . . . . . . . 60
3.8.3 Integration with Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.8.4 Detection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.8.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.9 Flutter App Development . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.9.1 Overview of Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.9.2 Why Choose Flutter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.9.3 Flutter App Development for Robot Control . . . . . . . . . . . . . . . . . 64
3.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

38
Introduction to the Robot Development Process Chapter 3

3.1 Introduction to the Robot Development Process

The development of an autonomous indoor mobile robot for locating misplaced house-
hold items integrates advanced hardware, software, and simulation techniques. This
chapter traces the journey from conceptual design to a fully functional robot capable
of navigation, search, and user interaction, focusing on key software development stages
that enable these capabilities, including navigation, perception, and control. Subsequent
chapters will explore additional features and optimizations.

A systematic approach is vital to ensure the robot’s reliability in dynamic home envi-
ronments. This chapter follows a structured process—conceptual planning, URDF mod-
eling, simulation, navigation system implementation, search mechanism development, ob-
ject detection integration, and mobile app creation—documenting each phase to highlight
iterative improvements essential for a robust system.

The process unfolds in distinct stages: conceptualization outlines the robot’s purpose
and specs, URDF modeling creates a digital prototype, simulation in Gazebo validates
navigation and perception, navigation system implementation uses the NAV2 stack for au-
tonomous movement, search mechanism development enables item location, object detec-
tion integration employs YOLO for real-time identification, and Flutter app development
delivers a user interface. These steps establish a solid operational foundation.

The robot operates on ROS2 Humble with WebSocket-enabled communication to an

Edge Device for enhanced functionality. This chapter details conceptualization, URDF
modeling, simulation setup, navigation system implementation, search algorithm develop-
ment, YOLO integration, Flutter app creation, and process reflections, setting the stage
for further enhancements in later chapters.

3.2 Concept Development and Initial Design

The idea for this autonomous robot began as the daily problem of finding missing
objects such as keys or phones in messy homes. The project was conceptualized as utiliz-
ing robotics to autonomously move around interior spaces, inspired by developments in
autonomous systems. That idea formed the basis for a robot that combined navigation,
perception, and eventual search functionality, starting off by building a solid foundation
in navigation.

To shape the robot’s development, clear functional specifications were set to meet
its goals. The robot must autonomously navigate indoor environments, avoiding obsta-
cles while employing SLAM for mapping. It requires sensors such as LiDAR for spatial
awareness and a camera for potential object detection, with real-time processing capabil-
ities. The design also prioritizes scalability for future enhancements like advanced search,
providing a strong foundation for the navigation focus of this chapter.

39
Proposed Modeling and Robot Description Chapter 3

An initial system design sketch outlined the robot’s architecture, emphasizing hard-
ware and software integration. The design features a Raspberry Pi as the central processor
running ROS2 Humble, an ESP32 for motor control and sensor data, and sensors includ-
ing YDLIDAR TSA and Logitech StreamCam. Planned communication includes UART
between ESP32 and Raspberry Pi, USB for sensors, and WebSocket to an Edge Device for
navigation support. Figure 3.1, depicted in a block diagram below, served as the initial
blueprint for development.

Figure 3.1: Initial System Design Block diagram.

This section has outlined the critical early steps of conceptualizing the autonomous
robot, from identifying the need to locate household items to defining its functional re-
quirements and sketching a system design.The next section will explore how this con-
ceptual design is translated into a virtual model through URDF modeling, marking the
transition from planning to practical implementation.

3.3 Proposed Modeling and Robot Description

This section outlines the modeling process for the autonomous indoor mobile robot,
detailing the tools and methodologies used to create an accurate digital representation
essential for simulation and development.

40
Proposed Modeling and Robot Description Chapter 3

3.3.1 Introduction to URDF and Xacro

The URDF serves as a fundamental XML-based format within the ROS ecosystem,
designed to define a robot’s physical structure, including its links, joints, and sensors.
This format enables accurate simulation and visualization, providing a digital blueprint
that tools like RViz and Gazebo can interpret to mimic the robot’s behavior. To enhance
this process, Xacro is employed as an extension, offering a more flexible and maintain-
able approach by allowing parameters and reusable components. Together, URDF and
Xacro create a robust foundation for modeling the robot, streamlining the transition from
concept to virtual testing.

3.3.2 Designing the Robot’s Physical Model

The robot’s physical design was crafted to support its navigation purpose, beginning
with a sturdy rectangular chassis optimized for indoor mobility. This chassis serves as the
platform for four wheels, each designed with joints to enable smooth rotation, ensuring the
robot can maneuver effectively. Specific mounting points were incorporated, strategically
placing the LiDAR at the top center for wide-area scanning and the camera at the front
for forward-facing perception. The design, illustrated in Figure 3.2, establishes a balanced
and functional structure tailored for the robot’s intended environment.

Figure 3.2: URDF Model of the Robot.

3.3.3 Integrating Sensors and Actuators

The robot’s design was enhanced by integrating key sensors and actuators into the
model. The YDLIDAR TSA was positioned centrally on the chassis, configured to provide
comprehensive spatial data for navigation tasks. The Logitech StreamCam was placed at
the front, aligned to capture visual information, supporting potential object detection in

41
Proposed Modeling and Robot Description Chapter 3

later stages. Additionally, the wheel motors were included as actuators, designed to drive
the robot’s movement, ensuring that the virtual model accurately reflects the planned
hardware setup for simulation purposes.

3.3.4 Transformations and Their Applications

Transformations, managed via the tf2 package in ROS2, establish the spatial relation-
ships between the robot’s components as defined in the URDF. The Table 3.1 represent
key parts of the robot:

Table 3.1: Coordinate Frames and Their Roles

Frame Description and Role
world Represents the global reference frame in the simulation en-
vironment, serving as the root for all transformations.
base_footprint Represents the robot’s base footprint, acting as an interme-
diate frame linking the world to the robot’s structure.
base_link Represents the lower chassis of the robot, serving as the
primary frame for the robot’s main body and attachment
points.
upper_chassis Represents the upper chassis, indicating the upper platform
where additional components are mounted.
laser Represents the YDLIDAR TSA LiDAR sensor, marking its
position for spatial mapping and perception tasks.
cam Represents the Logitech StreamCam, indicating its location
for visual data collection to support navigation.
imu Represents the MPU6050 IMU, denoting its position for ori-
entation and motion sensing.
left_wheel Represents the left wheel, indicating its role in the robot’s
movement mechanism.
right_wheel Represents the right wheel, mirroring the left wheel’s role in
locomotion.
odom Represents the odometry frame, tracking the robot’s position
relative to its starting point for localization.

These frames form the foundation for coordinating the robot’s perception, localization,
and navigation in the simulation environment.

42
Simulation Environment Development Chapter 3

3.3.5 Validation of URDF Model

To confirm the accuracy of the modeled design, the URDF was validated using RViz,
a visualization tool in the ROS2 ecosystem. The model was loaded to inspect the robot’s
structure, verifying that the chassis, wheels, and sensor placements aligned with the de-
sign specifications. Joint movements were tested to ensure proper rotation, and sensor
orientations were checked for consistency. A screenshot of this validation process, shown
in the figure 3.3, confirms the model’s readiness for simulation in Gazebo.

Figure 3.3: Validation of URDF Model in RViz.

This section detailed the creation of the robot’s URDF model, enhanced by Xacro, to
establish a virtual representation for simulation. This foundational work sets the stage for
the next section, where the model will be utilized in a simulated environment to develop
navigation capabilities.

3.4 Simulation Environment Development

This section details the creation of a virtual environment to test and validate the
autonomous robot’s functionality, an essential step before real-world deployment.

3.4.1 Selection and Setup of Simulation Tools

The simulation phase began with the selection of Gazebo and RViz as primary tools,
both compatible with ROS2 Humble, to create a virtual testing environment. Gazebo
provides a physics-based simulation for realistic robot interactions, while RViz offers vi-
sualization of sensor data and robot states. These tools were integrated with ROS2 by

43
Simulation Environment Development Chapter 3

installing the necessary packages and configuring the workspace, ensuring a robust plat-
form for simulating the robot’s behavior in a controlled setting.

3.4.2 Creating the Virtual Environment

A virtual environment was designed to emulate a typical indoor household setting,

essential for testing navigation capabilities. This environment includes a floor plan with
rooms, walls, and obstacles like furniture to mimic real-world challenges. Elements such
as tables, chairs, and doorways were added to create a cluttered space, allowing the robot
to encounter varied scenarios during simulation. The resulting environment, visualized in
Figure 3.4, provides a realistic backdrop for evaluating the robot’s performance.

Figure 3.4: Virtual Environment in Gazebo.

3.4.3 Importing and Configuring the URDF Model

The previously developed URDF model was imported into Gazebo to enable simu-
lation of the robot’s physical interactions. This process involved loading the model and
adjusting physics parameters, such as friction and gravity, to reflect real-world conditions.
Sensor plugins were configured to simulate the YDLIDAR TSA’s laser scans and the Log-
itech StreamCam’s image capture, ensuring accurate data generation. The configuration
ensures the virtual robot closely mirrors its physical counterpart for effective testing.

3.4.4 Initial Simulation Tests

Initial tests were conducted in Gazebo to verify the robot’s basic functionality within
the virtual environment. The robot was commanded to move forward, testing wheel

44
Simulation Chapter 3

rotation and motor response, while sensor data from the LiDAR and camera were collected
to assess their accuracy. These tests confirmed that the robot could navigate simple paths
and detect obstacles, though minor adjustments were needed for sensor alignment. A
screenshot of these initial test results in Gazebo is shown in the figure 3.5, highlighting
the robot’s early performance.

Figure 3.5: Initial Simulation Test in Gazebo.

This section outlined the setup of the simulation environment, a critical step in de-
veloping the robot’s navigation capabilities. The next section will focus on implementing
and refining perception and navigation algorithms using this environment.

3.5 Simulation

This part explores the simulation process for the autonomous robot, focusing on the
integration and testing of key components within a virtual environment using ROS2.

3.5.1 Essential ROS2 Nodes

The ROS2 nodes were essential for simulation, each serving a specific role in the
system:

45
Simulation Chapter 3

Table 3.2: ROS 2 Nodes and Their Roles

Node Description and Role
robot_state_publisher Publishes the robot’s state based on the URDF,
broadcasting static transformations and joint
states to enable visualization of the robot’s
structure and movement.
ydlidar_ros2_driver_node Interfaces with the YDLIDAR TSA, publishing
laser scan messages for mapping and localization
tasks.
amcl Implements Adaptive Monte Carlo Localization,
using LiDAR scans and odometry to estimate
the robot’s position within a preloaded map.
map_server Loads and publishes a pre-existing 2D occu-
pancy map for use by localization and naviga-
tion components.
nav2_bringup Orchestrates the NAV2 stack, launching multi-
ple nodes to ensure cohesive navigation function-
ality.
planner_server Part of the NAV2 stack, uses the A* algorithm
for global path planning to compute navigation
paths.
controller_server Manages local path following in NAV2, ensuring
smooth obstacle avoidance during navigation.
bt_navigator Executes navigation behaviors in NAV2 using a
behavior tree, handling tasks like path following
and recovery actions.
costmap_server Maintains global and local costmaps for NAV2,
integrating sensor data and the static map for
safe path planning.
gazebo_ros_state Publishes the robot’s joint states from Gazebo to
ROS2, ensuring synchronization between simu-
lation and ROS2.
gazebo_ros_control Subscribes to motor commands from ROS2 top-
ics and applies them in Gazebo, enabling simu-
lated wheel movement.
rviz2 Visualizes sensor data and robot state, config-
ured to display the robot model, costmaps, and
planned paths for debugging and validation.

These nodes collectively enable the robot’s perception, localization, and navigation in
the simulation environment.

46
Simulation Chapter 3

3.5.2 Launch Files and Configuration

Launch files and configurations were meticulously crafted to streamline the simulation
process:

Table 3.3: Launch Files and Their Roles

Launch File Description and Role
simulation.launch.py The main launch file, responsible for initializing the
simulation environment by launching Gazebo with
the virtual environment, spawning the robot’s URDF
model, starting the robot_state_publisher, and ini-
tializing rviz2 to display the robot model and sensor
data.
ydlidar.launch.py Launches the ydlidar_ros2_driver_node, configured
to ensure accurate LiDAR data publication for map-
ping and localization.
localization.launch.py Starts localization nodes, including map_server and
amcl, to load a pre-existing map and perform position
estimation.
navigation.launch.py Launches the NAV2 stack via nav2_bringup, start-
ing nodes like planner_server, controller_server,
bt_navigator, and costmap_server to enable navi-
gation functionality.

These launch files and configurations automate node startup and parameter tuning,
ensuring a cohesive simulation workflow.

3.5.3 Robot Localization in Simulation

Localization tracks the robot’s position within the virtual environment using various
techniques, each with specific algorithms:

• Odometry-based Localization: Relies on wheel encoder data and joint states

to estimate the robot’s position through dead reckoning, providing a baseline for
movement tracking.

• Particle Filter Localization: Utilizes the amcl algorithm to estimate the robot’s
pose by maintaining a set of particles representing possible positions, updated with
LiDAR scan data against a preloaded map.

47
Simulation Chapter 3

• IMU-assisted Localization: Incorporates data from the MPU6050 IMU to pro-

vide orientation and angular velocity, enhancing odometry-based estimates with
inertial information.

These techniques ensure reliable position tracking, with tests in Gazebo confirming
effective localization.

3.5.4 Mapping in Simulation

Mapping creates a spatial representation of the virtual environment using various

techniques, each with specific algorithms. While the simulation primarily relies on a
preloaded map, the following mapping algorithms are relevant for generating such maps:

• Preloaded Map-based Mapping: Employs the map_server to load a pre-existing

2D occupancy map, generated from prior SLAM runs, providing a static represen-
tation of the environment.

• Laser Scan-based Mapping: Utilizes the ydlidar_ros2_driver_node to collect

LiDAR data, which can be processed by SLAM algorithms to build or update maps.
The following SLAM algorithms are commonly used for this purpose:

– Cartographer: A graph-based SLAM algorithm that builds a map by opti-

mizing a pose graph, using LiDAR scans to create a globally consistent map
while simultaneously tracking the robot’s position.
– SLAM Toolbox: A flexible SLAM framework that supports both synchronous
and asynchronous mapping, allowing the robot to build and refine maps incre-
mentally using LiDAR data, with options for lifelong mapping.
– Gmapping: A particle filter-based SLAM algorithm that constructs a map
by maintaining a set of particles representing possible maps and robot poses,
integrating LiDAR and odometry data for 2D grid mapping.
– Hector SLAM: A scan-matching SLAM algorithm that builds maps by align-
ing consecutive LiDAR scans without requiring odometry, relying on high-
frequency scan matching for map generation.
– Karto SLAM: A graph-based SLAM algorithm that constructs a map using
scan matching and pose graph optimization, focusing on sparse pose adjust-
ments for efficient mapping.

The map is visualized as a screenshot of the saved map from the Cartographer al-
gorithm in .pgm file format, as shown in Figure 3.6, providing a spatial foundation for
navigation.

48
Navigation System Implementation Chapter 3

Figure 3.6: Map Visualization.

Simulation results guided refinements. Localization accuracy was improved by increas-

ing amcl’s particle count, reducing position error. Navigation performance was enhanced
by adjusting the costmap_server’s obstacle range and costmap resolution, improving
obstacle avoidance in tight spaces. These updates were applied through revised configu-
rations, ensuring the robot’s readiness for hardware implementation.

This section provided a detailed account of simulation-based development, covering

transformations, essential ROS2 nodes, launch files, configurations, localization, and map-
ping. The next section will focus on the detailed implementation of the navigation system
using the NAV2 stack.

3.6 Navigation System Implementation

This section provides an in-depth exploration of the navigation system implemented

using the NAV2 stack within the simulation environment, detailing every component, al-
gorithm, and process involved in enabling the robot to autonomously navigate through the
environment while avoiding obstacles. The NAV2 stack, launched via navigation.launch.py,
integrates various nodes and algorithms to achieve robust navigation capabilities.

3.6.1 Initialization and Coordination:

The nav2_bringup node serves as the orchestrator of the NAV2 stack in the simulation,
launching essential nodes such as planner_server, controller_server, bt_navigator,
and costmap_server. It loads configurations (e.g., nav2_params.yaml) to ensure all
nodes operate cohesively, setting up the navigation pipeline from goal setting to execution
in the environment.

49
Navigation System Implementation Chapter 3

3.6.2 Global Path Planning:

The planner_server node is responsible for global path planning in the simulation,
computing a feasible path from the robot’s current position to a user-defined goal.

• A* Algorithm: The primary algorithm used is A*, a heuristic-based search method

that finds the shortest path by evaluating nodes based on their cost (distance trav-
eled) and heuristic (estimated distance to the goal). It operates on the global
costmap derived from the environment, prioritizing paths that avoid known ob-
stacles.

• Dijkstra’s Algorithm: Dijkstra’s algorithm is a widely used algorithm for finding

the shortest paths from a single source node to all other nodes in a graph. It’s par-
ticularly useful for road networks, where nodes represent cities and edges represent
roads. The algorithm works by iteratively exploring the graph, keeping track of the
shortest distances from the source node to all other nodes.

Path Publication: The resulting global path is published on the /plan topic as a
sequence of waypoints, serving as a reference for local planning and execution.

3.6.3 Local Path Planning and Obstacle Avoidance:

The controller_server node manages local path planning in the simulation, ensuring
the robot follows the global path while dynamically avoiding obstacles.

• Dynamic Window Approach (DWA): The default algorithm is DWA, which

samples a set of possible velocity commands (linear and angular) within a dynamic
window in the simulation, evaluating each based on criteria like proximity to ob-
stacles, alignment with the global path, and goal progress. It selects the optimal
command that maximizes progress while ensuring safety in the environment.

Figure 3.7: Illustration of DWA algorithm

50
Navigation System Implementation Chapter 3

• Timed Elastic Band (TEB): An alternative algorithm supported by NAV2 in

simulation is TEB, which optimizes the local path by modeling it as an elastic
band, adjusting the trajectory to minimize path length, obstacle proximity, and
kinematic constraints over time.

Figure 3.8: Illustration of TEB algorithm

• Regulated Pure Pursuit (RPP): NAV2 also offers the Regulated Pure Pursuit
algorithm in simulation, which adjusts the robot’s velocity to follow the global path
by pursuing a lookahead point, adapting to curvature and speed constraints for
smoother navigation.

Figure 3.9: Path following with RPP controller.

A detailed comparison of the navigation algorithms supported by NAV2 highlights

their strengths and trade-offs across multiple criteria within the simulation context:

51
Navigation System Implementation Chapter 3

Table 3.4: Enhanced Comparison of NAV2 Navigation Algorithms in Simulation [39–42]

Criteria A* Dijkstra’s DWA TEB RPP
Algorithm
Path Optimality High (shortest High (shortest Moderate High Moderate
path) path) (real-time (optimized (curvature-
adjusted) trajectory) based)
Computational O(n log n) O(n log n) O(n) O(n2 ) O(n)
Complexity
Obstacle Avoidance Limited (static Limited (static Excellent Very Good Good
obstacles) obstacles) (dynamic (dynamic (lookahead
obstacles) adjustments) avoidance)
Suitability for Low (requires Low (requires High High Moderate
Dynamic Env. replanning) replanning) (real-time (real-time (adaptive
adaptation) optimization) response)
Real-Time High Moderate(no High High High
Performance (heuristic- heuristic-based
based search) search)
Kinematic Poor Poor Moderate Excellent Good
Constraint Handling
Smoothness of Low (sharp Low (sharp Moderate High High (smooth
Motion turns) turns) (velocity- (optimized tracking)
based) flow)

Based on the comparison, the Dynamic Window Approach (DWA) has been selected
for global planning, while A* has been chosen for local planning for the remainder of
the project. DWA’s strengths in handling dynamic environments and its high real-
time performance make it an excellent fit for the simulated Gazebo environment,
where the virtual robot must adapt to changing obstacles and maintain efficient nav-
igation across broader areas. Meanwhile, A*’s ability to compute optimal shortest
paths ensures precise local adjustments, providing robust obstacle avoidance critical
for the project’s goals. This combination leverages DWA’s proven performance in
simulation for global adaptability and A*’s efficiency for detailed local development.

3.6.4 Costmap Management:

The costmap_server node maintains both global and local costmaps within the
simulation, providing the spatial context for planning and control .
– Global Costmap: Built from the static map loaded by map_server in the
simulation, the global costmap represents the environment’s known obstacles
and free spaces, used by the planner_server for long-term path planning.
– Local Costmap: Updated in real-time, the local costmap captures dynamic
obstacles within a smaller, rolling window around the robot, used by the
controller_server for immediate obstacle avoidance.
– Costmap Layers: Both costmaps are composed of layers, including the static
layer (from the map), obstacle layer, inflation layer (adding a safety buffer
around obstacles), and voxel layer (for 3D data, though primarily 2D here).
These layers combine to assign costs to grid cells, guiding path planning .
– Costmap Updates: The costmap_server continuously updates the
costmaps, integrating new data to reflect changes in the environment, ensuring
the robot’s navigation decisions remain accurate.

52
Navigation System Implementation Chapter 3

3.6.5 Behavior Execution and State Management:

The bt_navigator node manages the overall navigation behavior using a behavior
tree framework.
– Behavior Tree Structure: The navigation process is modeled as a behavior
tree, with nodes representing tasks (e.g., ComputePathToPose, FollowPath)
and conditions (e.g., IsPathValid, IsGoalReached). The tree defines the se-
quence and logic of navigation actions, such as planning, following, and recov-
ering in the virtual environment.
– Task Execution: The bt_navigator executes tasks like following the global
path by delegating to the controller_server, checking if the goal is reached,
and handling transitions between states (e.g., from navigating to recovering).
– Recovery Behaviors: When navigation fails (e.g., the robot is stuck), the
bt_navigator triggers recovery behaviors, such as spinning in place to clear
obstacles, backing up to reposition, or replanning the path, ensuring the robot
can continue toward its goal.
– Goal Handling: The bt_navigator receives navigation goals via the
/navigate_to_pose action interface, managing the lifecycle of the goal (e.g.,
accepting, executing, completing, or aborting) and providing feedback on progress
within the environment.

3.6.6 Control and Command Execution:

The controller_server generates velocity commands to drive the virtual robot
along the planned path in the simulation.
– Velocity Command Generation: Based on the local plan, the
controller_server computes linear and angular velocities, ensuring they re-
spect the robot’s kinematic constraints (e.g., differential drive limits) and en-
vironmental conditions (e.g., virtual obstacle proximity).
– Command Publication: These velocity commands are published to the
/cmd_vel topic as a geometry_msgs/Twist message, specifying the desired
linear and angular velocities for the robot to follow the path.
– Execution in Simulation: The velocity commands are processed (m/s to
RPM), which applies them to the robot’s differential drive model, moving by
adjusting the left and right wheel speeds.

3.6.7 Transform Integration

: Navigation relies on the tf2 framework to maintain spatial relationships between
frames (e.g., world, base_link, odom, laser), ensuring accurate localization and
navigation alignment.
– Frame Alignment: The robot_state_publisher and amcl nodes publish
transforms (e.g., odom to base_link), aligning the robot’s pose with the map
and sensor frames, critical for correct path planning and obstacle detection.

53
Navigation System Implementation Chapter 3

– Sensor Data Transformation: data is transformed into the appropriate

frames (e.g., laser to base_link), ensuring the costmaps and planners interpret
data in the correct spatial context.

3.6.8 Feedback and Monitoring

: NAV2 provides feedback mechanisms to monitor and debug the navigation process.

– Path Visualization: The global and local paths are visualized in RViz via the
/plan topic, allowing developers to inspect the planned trajectory and identify
issues.
– Costmap Visualization: The global and local costmaps are published and
visualized in RViz, showing obstacle costs, inflation zones, and the robot’s
footprint, aiding in debugging navigation failures in the simulation.
– Navigation Status: The bt_navigator provides status updates via the
/navigate_to_pose action feedback, reporting progress, current state, and
any errors (e.g., goal unreachable) in the environment, facilitating system mon-
itoring.

Figure 3.10: Robot during autonomous navigation in Rviz2.

This section outlined the implementation of the navigation system using the NAV2
stack, detailing key components such as path planning, costmap management, and be-
havior execution. The next section will demonstrate the utility of this navigation system
in implementing the search mechanism.

54
Search Mechanism and Custom Search Algorithm Chapter 3

3.7 Search Mechanism and Custom Search Algorithm

3.7.1 Overview

The search mechanism leverages the robot’s autonomous capabilities to systematically

explore an unknown indoor environment in search of a user-specified object using a YOLO-
based detection system. The robot uses a grid-based waypoint generation algorithm
combined with the Nav2 stack to navigate to unvisited waypoints and perform scans.
The objective is to cover the entire area efficiently while minimizing redundancy, making
the system suitable for indoor object-finding scenarios.

3.7.2 Algorithm Selection

Various search strategies were assessed before finalizing the custom algorithm. The
evaluation focused on factors like coverage, obstacle adaptability, computational cost, and
integration with the Nav2 stack.

• Random Walk: Involves unpredictable motion. It can eventually cover the area
but lacks any assurance of completeness or efficiency.

• Spiral Search: Expands outwards from a starting point. It fails in environments

with obstacles or irregular boundaries.

• Zigzag Search: Ensures structured coverage in open areas but lacks flexibility in
obstacle-dense environments.

• Grid-Based Search: Divides the map into cells and visits each cell’s center sys-
tematically. It adapts well to obstacles, integrates with costmaps, and supports
waypoint navigation, making it optimal for our use case.

55
Search Mechanism and Custom Search Algorithm Chapter 3

Table 3.5: Search Algorithms Comparison

Feature Random Spiral Zigzag Grid-Based
Walk Search Search Search
Coverage Pattern Unstructured, Outward spiral Back-and- Systematic
random forth linear grid
Obstacle Moderate Low (rigid Low (linear High (costmap
Adaptability (unplanned) pattern) constraints) integration)
Computational O(1) O(n²) O(n²) O(n log n)
Complexity
Exploration Low Moderate Moderate High
Efficiency (redundant (open areas) (linear spaces) (optimized
paths) waypoints)
Compatibility with Low (no Moderate Moderate High
Nav2 waypoints) (path (path (waypoint-
adjustments) adjustments) based)
Suitability for Low (no focus) Moderate Moderate High (target-
Target Search (broad sweep) (limited focus) oriented)

After comparing these options, a greedy grid-based search algorithm was chosen be-
cause it provides a good balance between coverage and simplicity, as indicated by the
comparison table. Waypoints are generated based on the sensor’s field of view, and the
nearest unvisited waypoint is selected at each step. By always choosing the closest next
goal, the algorithm efficiently covers the area with minimal computation. This greedy ap-
proach allows for quick adaptation and straightforward implementation, making it suitable
for real-time search tasks.

3.7.3 Algorithm Demonstration

The implemented algorithm is detailed in Algorithm 1. It combines grid-based way-

point generation, efficient waypoint selection, and 360-degree object scanning using YOLO-
based detection.

56
Search Mechanism and Custom Search Algorithm Chapter 3

Algorithm 1 Grid-Based Search with Detection-Driven Termination

1: procedure SearchLoop
2: W ← GenerateWaypoints() ▷ Generate initial waypoints
3: H←∅ ▷ Track visited or failed waypoints
4: while target not found do
5: Wvalid ← W \ H ▷ Filter out visited/failed waypoints
6: if Wvalid is empty then
7: W ← RegenerateWaypoints() ▷ Regenerate if none left
8: continue
9: end if
10: w ← NearestWaypoint(Wvalid ) ▷ Choose closest waypoint
11: if NavigateTo(w) fails 3 times then
12: H ← H ∪ {w} ▷ Mark waypoint as failed
13: continue
14: end if
15: Spin360WithPauses() ▷ Perform a 360° scan
16: if DetectTarget(score > 0.7) then
17: break ▷ Stop when target detected
18: end if
19: H ← H ∪ {w} ▷ Mark waypoint as visited
20: end while
21: end procedure

3.7.4 Complexity Analysis and Interpretation

The overall complexity of the algorithm is influenced by three main stages: waypoint
generation, waypoint selection, and scan-based detection. Let n denote the number of grid
cells used to generate waypoints, and m denote the number of valid, navigable waypoints.

• Waypoint Generation: The initial grid-based waypoint generation iterates over n

cells. Each cell involves a path validity check using the costmap via navigator.getPath(),
which has complexity O(log n). Hence, the total cost for generating waypoints is:

O(n log n)

• Waypoint Selection: During each loop iteration, the algorithm selects the nearest
waypoint from the remaining m valid ones. Since distance calculations are precom-
puted and the list is sorted, selecting the closest waypoint takes:

O(log m)

• Scanning and Detection: At each waypoint, a 360° scan is performed in discrete

steps, each invoking an object detector. Assuming a fixed number of steps based on

57
Search Mechanism and Custom Search Algorithm Chapter 3

the detector’s field of view, this results in constant-time work per waypoint:

O(1)

• Retry Logic and Waypoint Refresh: If navigation fails up to a constant number

of times before a waypoint is discarded, and regeneration is triggered only when all
valid waypoints are exhausted, the retry and refresh logic adds at most a constant
overhead per waypoint:
O(1)

• Total Complexity: The main loop iterates over up to m valid waypoints. Each
iteration involves O(log m) for waypoint selection and O(1) for scanning and retry
logic. The total complexity of the full search process becomes:

O(n log n + m log m)

Since m ≤ n, this simplifies to:

Total Complexity = O(n log n)

3.7.5 Algorithm Implementation Details

The search is implemented in the SearchController ROS 2 node on the Raspberry

Pi:

• Initialization: Sets up the Nav2 BasicNavigator, ROS 2 publishers/subscribers:

– Publishers: /search_order, /robot_pose

– Subscribers: /detections, /search_target_id, /search_state,
/global_costmap/costmap, /amcl_pose

• Waypoint Generation: Uses camera FOV (60◦ ) and range (0.75 m) to compute:

span = 0.75 × tan(30◦ ) ≈ 0.433 m

width height
   
cols = , rows =
2 · span 2 · span
Points in occupied or recently visited zones (within 0.2 m) are filtered.

• Waypoint Navigation: Waypoints are sorted based on Euclidean distance:

p
d= (xr − xw )2 + (yr − yw )2

58
Search Mechanism and Custom Search Algorithm Chapter 3

• Spin and Detect: At each goal, robot performs:

360◦
 
spins = =6
60◦

with 0.5-second pauses for detection during each interval.

• Resilience and Updates: If all waypoints are exhausted or failed, new ones are
generated every 15 seconds.

3.7.6 Coverage Rate

• The robot’s camera has a 0.75 m radius field of view. As shown in Figure 3.11, the
placement of 11 waypoints and their corresponding circular coverage zones result in
over 95% area coverage of the room, validated by overlapping circular visual spans.

Figure 3.11: Coverage Map: Circular FOVs Overlapping for Room Coverage

The search algorithm combines grid-based waypoint generation, efficient nearest-point

selection, and detection-driven termination. With a total complexity of O(n log n), it
remains scalable and efficient even in large environments. By avoiding redundant explo-
ration and focusing on unvisited or reachable points, it ensures fast and reliable target
detection in indoor settings.

59
YOLO Model Integration for Object Detection Chapter 3

3.8 YOLO Model Integration for Object Detection

This section explores the integration of the YOLO model for real-time object detection,
a crucial component for enabling the autonomous robot to identify and locate misplaced
household items.

3.8.1 Overview

Ultralytics has developed a series of YOLO (You Only Look Once) models, advancing
real-time object detection and computer vision tasks since the release of YOLOv5 in 2020.
These models, evolving through YOLOv8, YOLOv9, YOLOv10, and YOLO11 (launched
on September 30, 2024, at YOLO Vision 2024), offer a balance of speed, accuracy, and effi-
ciency. YOLOv5 introduced PyTorch-based usability with export options, YOLOv8 added
anchor-free detection and multi-task support, YOLOv9 incorporated Programmable Gra-
dient Information (PGI) and Generalized Efficient Layer Aggregation Network (GELAN)
for edge efficiency, YOLOv10 eliminated Non-Maximum Suppression (NMS) with dual
label assignments, and YOLO11 enhanced accuracy with fewer parameters using C2PSA
modules and C3k2 blocks. Available in nano to extra-large scales with pre-trained weights
on Common Objects in Context (COCO) and ImageNet (ImageNet), these models sup-
port detection, segmentation, classification, pose estimation, and Oriented Bounding
Boxes (OBB). In this system, the YOLO model serves as the primary method for real-
time object detection, processing camera input to identify target items and guide the
search algorithm. [43]:

Figure 3.12: Ultralytics Logo

3.8.2 Model Selection and Comparison

The nano variants of YOLO models (YOLOv5n, YOLOv8n, YOLOv9n, YOLOv10n,

YOLOv11n) are the fastest due to their minimal parameter counts and optimized archi-
tectures, making them suitable for resource-constrained devices like the Raspberry Pi.
[43]:
A detailed comparison based on Ultralytics’ benchmarks is presented in the table 3.6

60
YOLO Model Integration for Object Detection Chapter 3

Table 3.6: Comparison of Nano YOLO Models from Ultralytics [43]

Model Parameters mAPval (%) Inference Inference Best Use
(M) Time (ms) - Time (ms) - Case
GPU CPU
(TensorRT) (ONNX)
YOLOv5n 1.9 28.0 1.5 5.2 Lightweight
mobile
deployment
YOLOv8n 3.2 37.3 0.99 4.1 Balanced edge
detection
YOLOv9n 3.0 38.5 0.85 3.8 Efficient edge
with PGI
YOLOv10n 2.8 39.0 0.75 3.5 NMS-free
real-time
detection
YOLOv11n 2.6 39.5 0.70 3.2 Fastest with
C2PSA
optimization

The comparison highlights YOLO11n as the fastest model, with the lowest inference
time on Graphics Processing Unit (GPU) (0.70 ms) and Central Processing Unit (CPU)
(3.2 ms), while maintaining a competitive mAPval of 39.5% with only 2.6 million pa-
rameters. This makes YOLO11n the optimal choice for real-time object detection on the
Raspberry Pi, balancing speed and accuracy without requiring retraining or modifications.

3.8.3 Integration with Raspberry Pi

The YOLO11n model is integrated into the Raspberry Pi, serving as the vision
processing hub for the robot. This integration leverages the provided ROS 2 node
(ObjectDetectionNode) and is detailed as follows:

• Software Environment: The ObjectDetectionNode is implemented using rclpy

for ROS 2, subscribing to /image _raw and publishing to /detections. Dependen-
cies include cv_bridge for ROS-to-OpenCV conversion, ultralytics for YOLO11n,
and torch (PyTorch >= 1.8). Installation is handled with pip install -U pip
and pip install ultralytics[extra].

• Model Configuration: The YOLO11n model is loaded from

/home/pfe/models/yolo11n.pt, a pre-trained weight file with 2.6M parameters
optimized for speed. Input images are resized to 256x256 pixels (imgsz=256) to align
with the model’s input requirements, converted from BGR8 format using CvBridge.

• Integration with System: The node subscribes to /image _raw for video input
and publishes to /detections, interfacing with the ROS 2 ecosystem. Startup is
logged with self.get_logger().info(), and rclpy.spin(node) ensures continu-
ous operation with proper cleanup on shutdown.

61
Flutter App Development Chapter 3

• Performance Considerations: The ObjectDetectionNode on a Raspberry Pi 4

Model B with 4GB RAM takes approximately 800 ms to read ROS 2 image messages
from /image_raw, pass them through the YOLO11n model, and publish the results
to the /detections topic. This latency includes message handling, preprocessing,
inference, and publishing overheads. Overclocking the 1.5 GHz quad-core CPU may
reduce this latency, though proper cooling is required to prevent thermal throttling.
The 2.6M parameters of YOLO11n ensure low memory usage, fitting comfortably
within the 4GB RAM, and A High-Performance Neural Network Inference Frame-
work (NCNN) export is recommended for further embedded optimization. The
script lacks explicit error handling, so adding try-except blocks around model()
calls would improve robustness.

3.8.4 Detection Process

The detection pipeline begins with the Raspberry Pi capturing video frames from
the camera, published as /image_raw. These frames are preprocessed by resizing to
256x256 pixels and converting to the required format. The YOLO11n model, running on
the Pi’s CPU, performs inference, identifying objects and generating bounding boxes with
confidence scores and class IDs. The results are parsed into a Detection2DArray message,
published to /detections, where the SearchController uses them to halt navigation
upon detecting a target with a confidence score above 0.7, ensuring accurate and timely
search termination.

3.8.5 Conclusion

The integration of the YOLO model for object detection has successfully enhanced the
AMR system, enabling real-time item identification. Leveraging ROS2 and WebSocket
communication, the system effectively triggers YOLO-based detection, integrating results
into the navigation workflow with robust performance. Future improvements could focus
on reducing latency and expanding the detection dataset for greater versatility.

3.9 Flutter App Development

This part details the development of a Flutter-based mobile application, designed

to provide an intuitive interface for controlling and monitoring the autonomous robot’s
operations.

62
Flutter App Development Chapter 3

3.9.1 Overview of Flutter

Flutter is an open-source UI software development kit created by Google, designed

for building natively compiled applications for mobile, web, and desktop from a single
codebase using the Dart programming language [44]. It features a reactive framework,
hot reload for real-time development, a rich widget library for custom UIs, and high
performance through native code compilation. For the AMR project, Flutter was selected
to create a mobile app as the main interface for controlling and monitoring the robot,
leveraging its cross-platform capabilities and real-time interaction support with ROS2.

Figure 3.13: Flutter logo.

3.9.2 Why Choose Flutter?

Flutter was preferred over other mobile development platforms due to its cross-platform
efficiency, performance, and seamless integration with ROS2 via WebSockets. The table
3.7 compares Flutter with React Native, Xamarin, and native development (Swift for iOS,
Kotlin for Android):

Table 3.7: Comparison of Mobile Development Platforms [44–47]

Platform Language Performance Development UI ROS2
Speed Consistency Integration
Flutter Dart High (Native Fast (Hot High (Custom Good
compilation) Reload) widgets) (WebSocket
support)
React Native JavaScript Moderate (JS Fast (Hot Moderate Good
bridge) Reload) (Native (WebSocket
components) support)
Xamarin C# High (Native Moderate Moderate Moderate
binding)
Native Swift/Kotlin/ Very High Slower High Complex
(Android Java (Native) (Separate (Platform- (Native APIs)
Studio) codebases) specific)

63
Flutter App Development Chapter 3

Analysis and Rationale:

• Cross-Platform Development: Flutter’s single codebase reduced development

effort compared to native development’s separate codebases.

• Performance: Native compilation ensured smooth real-time map and position

updates, outperforming React Native’s JavaScript bridge.

• UI Flexibility: Custom widgets provided consistent UI across platforms, unlike

Xamarin’s potential inconsistencies.

• ROS2 Integration: WebSocket support (via web_socket_channel) aligned with

the ROS2 WebSocket server
(ros2 launch rosbridge_server rosbridge_websocket_launch.xml), simplify-
ing integration over native platforms.

3.9.3 Flutter App Development for Robot Control

This part outlines the implementation of the Flutter app’s features for controlling the
autonomous robot, focusing on user interaction and real-time monitoring.

System Integration via WebSockets

The app connects to the ROS2 system via a WebSocket server launched with ros2
launch rosbridge_server rosbridge_websocket_launch.xml.
This setup facilitates:

• Subscriptions: The app subscribes to ROS2 topics such as /amcl_pose for real-
time robot position and /map for map data.

• Publications: It publishes to /goal_pose for navigation control (search_controller_node)

and supports item search initiation via topic /search_order.

Main Interface Design

The app’s main interface, shown in Figure 3.14, includes:

• Robot Position Initialization: A “Set Initial Pose” button to set the robot’s
starting position using AMCL data.

64
Flutter App Development Chapter 3

• Navigation Control: A “Set Goal Pose” button allows users to set navigation
goals by tapping the map or entering coordinates, utilizing RPP or DWA.

• Item Search Initiation: A dropdown (e.g., “bottle”) and associated functionality

to start item searching, triggering YOLO

• Map and Real-Time Position Display: A map view displays the robot’s position
(e.g., x = −0.0431, y = 0.1068, yaw= −1.0548 rad) and environment, updated in
real-time from /amcl_pose.

Figure 3.14: Main Interface of the Flutter App for robot Control.

As shown in Figure 3.14, we can initialize the robot’s position, set goal poses for
autonomous navigation, and start the item search process.

Implementation Details

• Flutter project: The Flutter project contains Dart files (e.g., main.dart) us-
ing the web_socket_channel package for WebSocket communication. It include a
CustomPaint widget for map rendering, as seen in Figure 3.14.

• Map Rendering: The map is rendered with a black outline, updated with the
robot’s pose from /amcl_pose.

65
Conclusion Chapter 3

• Navigation and Search: The app publishes /goal_pose messages and triggers
item detection via the topic /search_order, as inferred from the interface.

• Connectivity: The “Connected to ROS2” status indicates a stable WebSocket link,

managed by the rosbridge_websocket_launch.xml server.

3.10 Conclusion

This chapter has provided a comprehensive overview of the software development

process for an autonomous indoor mobile robot designed to locate misplaced household
items, detailing the journey from conceptual design to a functional system as of June 01,
2025. Beginning with the conceptualization and initial design, we established the robot’s
purpose and architecture, focusing on its navigation capabilities using a Raspberry Pi,
ESP32, YDLIDAR TSA, Logitech StreamCam, and ROS2 Humble. The URDF modeling
phase created a virtual representation of the robot, validated through RViz, which served
as the foundation for simulation in Gazebo.

The simulation environment development enabled rigorous testing of perception and

navigation, incorporating a realistic indoor setting to refine the robot’s behavior. The
navigation system implementation, leveraging the NAV2 stack, successfully enabled au-
tonomous movement with algorithms like DWA, ensuring robust obstacle avoidance and
path planning. The custom grid-based search mechanism further enhanced the robot’s
ability to systematically explore environments, achieving over 95% coverage, while the
integration of YOLO11n for object detection provided real-time identification capabilities
on the Raspberry Pi, despite challenges in managing inference latency.

The development of the Flutter app established an intuitive user interface, facilitating
real-time control, monitoring, and interaction with the robot via WebSocket communica-
tion, completing the system’s core functionality.

In the next chapter, we will focus on the hardware integration and real-world testing
phases, evaluating the robot’s performance in actual indoor environments and addressing
the practical challenges encountered during deployment.

66
4 Hardware Realization and Integration

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 Hardware Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 ESP32 Firmware for Motor Speed and Communication . . . . . . . . 70
4.3.1 FreeRTOS for Multitasking and Real-Time Execution . . . . . . . . . . . 70
4.3.2 Motor Speed Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.3 Motor Speed Regulation Process . . . . . . . . . . . . . . . . . . . . . . . 73
4.3.4 Communication Between ESP32 and Raspberry Pi . . . . . . . . . . . . . 80
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

67
Introduction Chapter 4

4.1 Introduction

This chapter centers on the hardware realization and integration of the autonomous
indoor mobile robot, designed to navigate and locate misplaced household items, marking
the shift from simulation to physical deployment. Building on the software framework
from the previous chapter, the navigation system, driven by the NAV2 stack, is now
implemented on a tangible platform. The integration process involves assembling and
configuring hardware to interface with the ROS 2 ecosystem, ensuring real-time data
exchange for accurate navigation and control.

A structured methodology guides the creation of a robust hardware solution, in-

corporating key components like the ESP32 microcontroller, DC motors with encoders,
MPU6050 IMU, L298N motor driver, Raspberry Pi 4, Logitech camera, YDLIDAR TSA,
and a 12V LiPo battery. The chapter details ESP32 firmware development with FreeR-
TOS for multitasking, a Fuzzy Logic PID controller for motor speed regulation, and
UART communication between the ESP32 and Raspberry Pi for sensor data and com-
mands, with each step documented to reflect iterative improvements for dynamic indoor
use.

The process includes hardware assembly, firmware optimization, and performance test-
ing. The robot relies on a Raspberry Pi 4 for ROS 2 processing, an ESP32 for low-level
control, and advanced sensors for perception, enhanced by a WebSocket-linked Edge De-
vice. This chapter covers hardware integration, firmware implementation, communication
protocols, and a concluding analysis, laying the groundwork for real-world testing and fu-
ture refinements.

A significant challenge is adapting the Fuzzy Logic PID controller from simulation
to real-world conditions, where friction, uneven surfaces, and sensor noise require precise
tuning for smooth motor control. This transition highlights the complexity of aligning
virtual models with physical systems, to be addressed through iterative adjustments and
testing.

4.2 Hardware Integration

The autonomous robot is equipped with several essential hardware components, each
serving a specific role in ensuring its proper operation:

• ESP32 microcontroller: serves as the central processing unit, handling motor

control and communication with the ROS 2 navigation stack.

• DC motors with encoders: provide odometry data, enabling precise tracking of

the robot’s position and speed.

68
Hardware Integration Chapter 4

• MPU6050 IMU: supplies orientation information, contributing to the robot’s sta-

bility and localization.

• L298N motor driver: controls the DC motors, managing power delivery and
direction based on commands from the ESP32.

• Raspberry Pi 4: runs the ROS 2 navigation stack, processing data for global and
local path planning.

• Logitech camera: provides visual data, enhancing environmental perception for

the navigation system.

• YDLIDAR TSA: offers 360-degree LiDAR scans, supporting obstacle detection

and mapping in the navigation pipeline.

• 12V LiPo battery: powers all components, ensuring stable operation through a
voltage regulator.

Thre figure 4.1 illustrates the assembled hardware setup:

Figure 4.1: Diagram of component connections.

69
ESP32 Firmware for Motor Speed and Communication Chapter 4

Figure 4.2: Assembled robot.

4.3 ESP32 Firmware for Motor Speed and Communi-

cation

The ESP32 firmware is designed to manage motor speed regulation and communication
with the ROS 2 navigation stack efficiently. This is achieved through the use of FreeRTOS
for multitasking, precise speed calculation from encoder data, and a custom Fuzzy Logic
PID controller for motor speed regulation.

4.3.1 FreeRTOS for Multitasking and Real-Time Execution

FreeRTOS, a real-time operating system, is integral to the ESP32 firmware, enabling

multitasking and ensuring real-time execution of critical tasks. It allows the ESP32 to
handle multiple processes concurrently, such as motor speed regulation and communica-
tion with the ROS 2 system, without compromising performance.

FreeRTOS facilitates the creation of two primary tasks:

• Communication Task: This task manages the reception and processing of ROS 2
/cmd_vel messages, ensuring the ESP32 can interpret velocity commands from the
navigation stack in real time.

• Motor Regulation Task: This task continuously adjusts motor speeds based on

70
ESP32 Firmware for Motor Speed and Communication Chapter 4

encoder feedback, using the Fuzzy Logic PID controller to maintain the desired
velocity.

The importance of FreeRTOS lies in its ability to prioritize tasks, manage resources
efficiently, and guarantee timely execution. By assigning appropriate priorities to the
communication and motor regulation tasks, FreeRTOS ensures that velocity commands
are processed without delay, while motor adjustments occur at regular intervals (e.g.,
every 10ms). This multitasking capability minimizes latency, prevents task starvation,
and maintains system stability, which is critical for real-time robotic applications where
precise and timely motor control is essential.

4.3.2 Motor Speed Calculation

The motor speed is calculated using data from the DC motors’ encoders, which are
interfaced with the ESP32 through two pins (encA and encB) to detect rotational move-
ment. The process ensures accurate speed measurement for the subsequent Fuzzy Logic
PID regulation.

• Quadrature Encoding and Position Tracking: The quadrature encoder gen-

erates two signals, A (encA) and B (encB), to monitor the motor’s rotation. These
signals have a phase difference, enabling the ESP32 to determine both the speed and
direction of rotation, as illustrated in Figure 4.3. The ‘Init‘ method sets up encA
and encB as input pins and attaches an interrupt (‘encoderISR‘) to encA. This in-
terrupt triggers on any change in encA’s state, ensuring timely detection of encoder
ticks. The ‘Update‘ method, invoked by the interrupt, reads the states of encA and
encB to determine the direction of rotation. The logic for direction detection is as
follows:

– If encB is high and encA is high, the wheel rotates clockwise, so the position
increments by +1.
– If encB is high and encA is low, the wheel rotates counter-clockwise, so the
position decrements by -1.
– If encB is low and encA is high, the wheel rotates counter-clockwise, so the
position decrements by -1.
– If encB is low and encA is low, the wheel rotates clockwise, so the position
increments by +1.

The ‘Position‘ variable tracks the cumulative encoder ticks, incrementing for clock-
wise rotation and decrementing for counter-clockwise rotation, providing an accurate
measure of the motor’s position.

71
ESP32 Firmware for Motor Speed and Communication Chapter 4

Figure 4.3: Quadrature encoder signals for detecting rotational direction.

• Speed Calculation: The ‘GetfilteredVelocity‘ method calculates the motor speed

in Revolutions Per Minute (RPM) (Revolutions Per Minute). It first retrieves the
current position (GetPosition) using a critical section with a mutex (‘muxMotor‘)
to ensure thread safety. The change in position (∆pos) is computed as the difference
between the current and previous positions. The elapsed time (∆t) in seconds is
calculated using ‘micros()‘. The initial speed in counts per second (counts/s) is
determined as:
∆pos
v=
∆t
This is converted to RPM using:

counts/s
v= × 60
204

where 204 is the number of counts per revolution, and 60 converts seconds− 1 to
minutes− 1.

• Low-Pass Filtering for Speed Smoothing: To reduce noise and ensure smooth
motor speed control, a low-pass filter with a 25 Hz cut-off frequency is applied to
the calculated speed. The filter smooths out rapid fluctuations, providing a stable
input to the PID (Proportional-Integral-Derivative) controller. The filtering process
uses the recursive equation:

vfilt = 0.854 × vfilt + 0.0728 × (v + vprev )

where vfilt is the filtered speed, v is the current speed, and vprev is the previous speed
reading.

• State Update: The method updates the previous position, velocity, and time

72
ESP32 Firmware for Motor Speed and Communication Chapter 4

(previousPosition, previousVelocity, previousTime) for the next iteration, en-

suring continuous and accurate speed calculation.

This process provides a reliable speed measurement, critical for the subsequent Fuzzy
Logic PID regulation.

4.3.3 Motor Speed Regulation Process

The motor speed regulation process aims to maintain the desired speed of the DC
motors using speed data derived from encoder measurements. Initially, a manual PID
tuning method was employed, followed by an adaptive Fuzzy Logic PID controller to im-
prove performance under varying conditions. The following sections outline the regulation
process, comparing the two approaches and detailing the Fuzzy Logic implementation.

Manual PID Tuning

The initial approach involved manual PID tuning, where the PID gains—Kp (Propor-
tional gain), Ki (Integral gain), and Kd (Derivative gain)—were adjusted through trial
and error to achieve a stable response. The tuning process included:

• Setting initial gains (e.g., Kp = 1.0, Ki = 0.0, Kd = 0.0) and observing the motor’s
response to a setpoint speed.

• Increasing Kp until the motor speed oscillated, then reducing it slightly to stabilize
the response.

• Adjusting Ki to minimize steady-state error, ensuring the motor approached the

setpoint over time.

• Fine-tuning Kd to dampen oscillations, though it was kept low to avoid noise am-
plification.

The results of this method are depicted in Figure 4.4, which shows the motor speed often
exceeding the target setpoint, causing overshoot (reaching up to 220 RPM when the target
is 200 RPM). This led to non-smooth speed variations, particularly under varying loads,
with a settling time of approximately 0.6 seconds and noticeable oscillations.

73
ESP32 Firmware for Motor Speed and Communication Chapter 4

Figure 4.4: Manual PID Tuning Results.

However, manual PID tuning has inherent limitations. The fixed gains struggle to
adapt to dynamic conditions such as sudden load changes or uneven terrain, resulting in:

• Overshoot and oscillations, as observed in the chart, which can destabilize the robot.

• Inconsistent performance when encountering non-linear motor behavior or environ-

mental changes.

• A time-consuming tuning process requiring repeated adjustments for different sce-

narios.

Adaptive Fuzzy Logic PID Controller

To address these shortcomings, an adaptive Fuzzy Logic PID controller was devel-
oped. This method dynamically adjusts the PID gains based on the error (e) and its
rate of change (dedt), providing a more robust solution. Comparison of Member-
ship Functions: Different membership functions can be used to define the fuzzy sets,
influencing the controller’s performance. The following describes each type individually:

• Trapezoidal Membership Function:

Defined by four points (a, b, c, d), this function features a flat top where the mem-
bership degree is 1.0 between b and c, with linear slopes on either side. For example,
the NB set has a membership of 1.0 from -0.8 to -0.6, dropping to 0.0 outside -1.0 to
-0.6. This shape ensures stable classification of significant errors, enabling decisive
corrective actions, and supports overlapping regions for smooth transitions.

• Triangular Membership Function:

Defined by three points (base start, peak, base end), this function rises to a peak of

74
ESP32 Firmware for Motor Speed and Communication Chapter 4

1.0 at the center and drops linearly to 0.0 on both sides. For instance, a triangular
NB might peak at -0.8 and taper to 0.0 at -1.0 and -0.6. It lacks a flat top, leading
to rapid membership changes and potential ambiguity when errors lie between sets,
which can result in less consistent control responses.
• Gaussian Membership Function:
This function uses a bell-shaped curve based on an exponential decay, centered
at a mean with a defined standard deviation. It provides very smooth transitions
with no sharp edges, but its membership never reaches exactly 0 or 1, requiring
more complex tuning. For example, a Gaussian NB might center at -0.8, decaying
symmetrically, making it computationally intensive due to exponential calculations.

A comparison of these membership functions is summarized in the table4.1:

Table 4.1: Membership functions comparison

Feature Trapezoidal Triangular Gaussian
Shape Flat top with Single peak Bell-shaped
linear slopes with linear curve
slopes
Membership Range 0 to 1 with 0 to 1 with 0 to 1
plateau peak (asymptotic)
Overlap Handling Smooth via Rapid Very smooth
overlap transition
Computational Low (linear) Low (linear) High
Complexity (exponential)
Decisiveness for High (stable Moderate Low (gradual)
Large Errors plateau) (peak only)
Suitability for High High Low
ESP32

Based on this comparison, trapezoidal membership functions were chosen for this sys-
tem. Their flat top ensures a stable and decisive response for significant errors, critical
for rapid correction in motor speed regulation. The overlapping regions provide smooth
transitions in control output, avoiding jerky behavior under load, while their low compu-
tational complexity suits the resource-constrained ESP32 platform. Triangular functions
lack the plateau, potentially leading to less decisive actions, and Gaussian functions,
though smoother, are computationally intensive, making trapezoidal the optimal choice
for stability, responsiveness, and efficiency.

Selection of Fuzzy Rules

The Fuzzy Logic system begins with the selection of fuzzy rules, designed to achieve
an aggressive response to quickly correct errors and stabilize motor speed. The error

75
ESP32 Firmware for Motor Speed and Communication Chapter 4

(e) and error derivative (dedt), both normalized to the range [-1.0, 1.0], are categorized
into seven linguistic variables: Negative Big (NB), Negative Medium (NM), Negative
Small (NS), Zero (Z), Positive Small (PS), Positive Medium (PM), and Positive Big
(PB). The trapezoidal membership function (trapezoidalMF) defines these variables, with
parameters set to overlap slightly for smooth transitions. For example, NB ranges from
-1.0 to -0.6, NM from -0.8 to -0.2, as specified in the ‘calculateMemberships‘ function.
The membership functions are visualized in Figure 4.5.

Figure 4.5: Membership Functions.

Fuzzy Rules Table

The fuzzy rules are implemented as 7x7 matrices (‘rule_kp‘ and ‘rule_ki‘) within the
‘fuzzyInference‘ function to dynamically adjust the PID controller gains for motor speed
regulation, mapping combinations of e and dedt memberships to proportional (Kp) and
integral (Ki) gains, with Kd set to 0.0. The values are designed to increase aggressively
for large errors (e.g., 6.0 for NB-NB) and decrease for small errors (e.g., 0.6 for PB-PB),
scaled by factors (1.5 for Kp, 7.0 for Ki) to enhance responsiveness. The tables are:

dedt e NB NM NS Z PS PM PB
NB 6.0 5.8 5.6 5.4 5.2 5.0 4.8
NM 4.8 4.6 4.4 4.2 4.0 3.8 3.6
NS 3.6 3.4 3.2 3.0 2.8 2.6 2.4
• Rule Table for Kp (x 1.5):
Z 2.4 2.2 2.0 1.8 1.6 1.4 1.2
PS 2.2 2.0 1.8 1.6 1.4 1.2 1.0
PM 2.0 1.8 1.6 1.4 1.2 1.0 0.8
PB 1.8 1.6 1.4 1.2 1.0 0.8 0.6

76
ESP32 Firmware for Motor Speed and Communication Chapter 4

dedt e NB NM NS Z PS PM PB
NB 6.0 5.8 5.6 5.4 5.2 5.0 4.8
NM 4.8 4.6 4.4 4.2 4.0 3.8 3.6
NS 3.6 3.4 3.2 3.0 2.8 2.6 2.4
• Rule Table for Ki (x 7.0):
Z 2.4 2.2 2.0 1.8 1.6 1.4 1.2
PS 2.2 2.0 1.8 1.6 1.4 1.2 1.0
PM 2.0 1.8 1.6 1.4 1.2 1.0 0.8
PB 1.8 1.6 1.4 1.2 1.0 0.8 0.6

The rules prioritize rapid error correction for large deviations (e.g., NB-NB yields
high Kp and Ki) and reduce gain intensity as the error nears zero (e.g., PB-PB yields low
Kp and Ki), ensuring stability near the setpoint. The relationship between error, error
derivative, and Kp gain is visualized in Figure 4.6.

Figure 4.6: Fuzzy Rules Surface for Kp.

Fuzzy Inference System (FIS) Rules

The FIS rules operate as follows. The ‘fuzzyInference‘ function computes membership
degrees for e and dedt using ‘calculateMemberships‘. It applies the minimum operator

weight = min(eMembership[i], dedtMembership[j])

to determine the firing strength of each rule. The weighted sums are calculated as:

6 X
X 6
sum_kp = (weight × rule_kp[i][j] × 1.5)
i=0 j=0

77
ESP32 Firmware for Motor Speed and Communication Chapter 4

6 X
X 6
sum_ki = (weight × rule_ki[i][j] × 7.0)
i=0 j=0

6 X
X 6
sum_weights = weight
i=0 j=0

The final gains are:

sum_kp sum_ki
kp = , ki =
sum_weights sum_weights

If sum_weights > 0; otherwise, the previous gains are retained. This center-of-gravity
method ensures a smooth transition of gains.

The Fuzzy Logic PID controller enhances motor speed regulation by dynamically ad-
justing Kp and Ki gains based on normalized error and its rate of change. It employs
trapezoidal membership functions to categorize inputs into seven linguistic sets (NB to
PB), uses aggressive rule tables for gain determination, and applies a weighted average
defuzzification method, outperforming manual PID tuning under varying loads.

Implementation Process

The process continues with the following steps:

• Error Calculation: The ‘ComputeFuzzy‘ method calculates the error (e) as the
difference between the desired setpoint (from ROS 2 /cmd_vel) and the filtered
speed (from ‘GetfilteredVelocity‘). The time difference since the last call is com-
puted using ‘micros()‘ to ensure accurate derivative calculations, with a safeguard
to prevent division by zero.

• Error Derivative Calculation: The derivative of the error (dedt) is computed

using:
currentError − previousError
dedt =
deltaTime
This enables the controller to respond to rapid speed changes.

• Normalization: The ‘Map‘ function normalizes the error (e) and error derivative
(dedt) to a range of -1.0 to 1.0, ensuring compatibility with the fuzzy logic system
and handling edge cases like zero or negative setpoints.

• Membership Calculation: The ‘calculateMemberships‘ function maps the nor-

malized error (e) and error derivative (dedt) into seven fuzzy sets using trapezoidal
membership functions (trapezoidalMF).

• Fuzzy Inference: The ‘fuzzyInference‘ function applies the rules and computes
the adjusted gains (Kp, Ki, Kd), with Kd set to 0.0.

78
ESP32 Firmware for Motor Speed and Communication Chapter 4

• PID Computation: The ‘ComputeFuzzy‘ method calculates the control signal

using the adjusted gains according to:
Z
de
controlSignal = Kp × e + Kd × + Ki × e dt
dt

The integral term includes anti-windup protection, and the output is limited to
prevent saturation.

• Motor Control Output: The control signal is applied to the DC motors via the
L298N motor driver, adjusting the PWM signal. The ESP32 updates the previous
error (e) and time for the next iteration.

Results and Performance

The Fuzzy Logic PID results are shown in Figure 4.7. Unlike the manual PID, the chart
indicates minimal overshoot, with the speed closely tracking the setpoint (e.g., stabilizing
around 200 RPM without exceedance). This ensures smoother speed variations, especially
under load, with a settling time reduced to under 0.3 seconds and almost 0 oscillations,
enhancing navigation performance.

Figure 4.7: Fuzzy Logic PID Results.

This adaptive process ensures precise motor speed regulation, effectively handling real-
time variations while maintaining seamless communication with the ROS 2 navigation
stack.

79
ESP32 Firmware for Motor Speed and Communication Chapter 4

4.3.4 Communication Between ESP32 and Raspberry Pi

This part details the communication strategy enabling data exchange between the
ESP32 and Raspberry Pi, a necessary aspect for real-time coordination in the autonomous
robot system.

Overview of UART Communication Protocol

The Universal Asynchronous Receiver/Transmitter (UART) is a serial communication

protocol that enables asynchronous data exchange between the ESP32 and Raspberry Pi
without a shared clock. UART transmits data as a series of bits over a single wire (TX
for transmission, RX for reception), with each packet typically including a start bit, 8
data bits, an optional parity bit, and one or more stop bits. The protocol’s simplicity and
flexibility suit real-time applications, requiring both devices to agree on baud rate, data
format, and timing. In this system, UART facilitates bidirectional communication, with
the ESP32 sending sensor data and receiving motor commands, supported by FreeRTOS
to ensure real-time performance on the ESP32.

Figure 4.8: UART data transmission

Detailed Communication Steps

The communication process involves the following steps:

• Initialization: The ESP32 initializes its UART module, setting the baud rate (e.g.,
115200 bps), 8 data bits, no parity, and 1 stop bit to align with the Raspberry Pi’s

80
ESP32 Firmware for Motor Speed and Communication Chapter 4

serial settings. FreeRTOS tasks are created to handle transmission and reception
concurrently, preventing delays in real-time operations.

• Data Collection on ESP32: The ESP32 gathers sensor data, including encoder
values (encoder1, encoder2) from motor encoders, orientation data (yaw, pitch,
roll) from the IMU, and acceleration data (accel_x, accel_y, accel_z) from the
accelerometer. This data is formatted as
[encoder1,encoder2,yaw,pitch,roll,accel_x,accel_y,accel_z].

• Data Transmission from ESP32: A FreeRTOS task triggers UART transmission,

sending the formatted sensor data packet over the TX pin to the Raspberry Pi. The
packet uses commas and square brackets for parsing, ensuring timely updates (e.g.,
every 50 ms) critical for navigation.

• Data Reception on Raspberry Pi: The Raspberry Pi receives the data via its
RX pin, where a ROS 2 node parses the packet to extract values for pose estimation
and path planning, relying on the real-time data stream from the ESP32.

• Command Generation on Raspberry Pi: The Raspberry Pi’s ROS 2 navigation

stack processes sensor data and generates motor speed commands in the format
<leftMotorSpeed,rightMotorSpeed>, specifying desired speeds for the left and
right motors.

• Command Transmission from Raspberry Pi: The Raspberry Pi sends the

command packet over its TX pin to the ESP32’s RX pin via UART, enclosed in
angle brackets for identification.

• Command Reception on ESP32: A FreeRTOS task on the ESP32 monitors the

RX pin, deserializing the packet to extract leftMotorSpeed and rightMotorSpeed
values, ensuring rapid command processing.

• Command Execution on ESP32: The extracted speeds are fed into the Fuzzy
Logic PID controller, which adjusts PWM signals to the L298N motor driver. FreeR-
TOS ensures this execution occurs in real-time, maintaining responsiveness to dy-
namic conditions.

• Timeout Feature: To enhance safety, the ‘processCommand‘ function includes

a timeout mechanism. If no new command data is received within 100 ms, the
motor speeds are reset to 0, halting the motors to prevent unintended movement
during communication lapses. This feature ensures the system remains stable under
intermittent data loss.

• Continuous Loop: The process runs in a continuous loop, with FreeRTOS schedul-
ing tasks to maintain real-time performance. The ESP32 transmits sensor data
periodically, and the Raspberry Pi responds with commands, sustaining seamless
integration with the ROS 2 ecosystem.

81
Conclusion Chapter 4

Importance of FreeRTOS

FreeRTOS is critical for this system’s real-time operation. It enables multitasking on

the ESP32, allowing simultaneous handling of sensor data collection, UART transmis-
sion, command reception, and motor control execution. This concurrency ensures that
sensor data is sent at precise intervals, supporting the Raspberry Pi’s navigation algo-
rithms, while commands are executed with minimal latency, critical for dynamic robot
navigation. The timeout feature further leverages FreeRTOS’s task scheduling to monitor
communication health, enhancing safety and reliability in real-time applications.

Figure 4.9: FreeRTOS Code Snippet.

4.4 Conclusion

This chapter outlined a comprehensive approach to motor speed regulation and inter-
device communication for the robotic system, integrating the ESP32 and Raspberry Pi.
Initial manual PID tuning established a baseline but showed limitations like overshoot
and a 0.6-second settling time. An adaptive Fuzzy Logic PID controller, using trapezoidal
membership functions and aggressive rule tables, improved performance, reducing settling
time to under 0.3 second with smoother speed control.

Communication via UART, supported by FreeRTOS on the ESP32, enabled real-time

sensor data and command exchange, enhanced by a safety feature resetting motor speeds
to zero if no commands are received within 100 ms. These advancements provide a robust
foundation for ROS 2 navigation integration.

82
General Conclusion

The rapidly evolving field of autonomous robotics presents both opportunities and
challenges as cutting-edge technologies emerge. This report has explored the develop-
ment of an autonomous indoor mobile robot, tracing its evolution from conceptual design
and simulation to real-world implementation. The project has tackled critical aspects
including communication protocols, control systems, and navigation algorithms within
an embedded framework, unifying these elements into a cohesive system for household
applications such as locating misplaced items.

The study addressed key technical areas: the first chapter provided a foundational
overview, detailing the project’s context, objectives, and management approach at ESME
Research Lab. The second chapter reviewed the history and technologies of autonomous
robotics, setting the stage with insights into sensors, localization, and navigation. The
third chapter detailed the software development process, covering concept design, URDF
modeling, simulation, NAV2 navigation, a custom search algorithm, YOLO integration,
and the Flutter app, establishing a robust software foundation. The fourth chapter focused
on hardware realization, integrating components like the ESP32 and Raspberry Pi, with
FreeRTOS and a fuzzy logic PID controller ensuring precise motor control and reliable
UART communication.

Significant challenges included ensuring real-time performance and scalability in com-

munication, adapting the fuzzy logic PID controller for dynamic indoor environments, and
refining navigation algorithms using ROS2 and NAV2 with LiDAR and Inertial Measure-
ment Unit (IMU) data. The transition from simulation to reality revealed complexities
like sensor noise and hardware constraints, addressed through iterative testing and cali-
bration. These efforts culminated in a robot capable of autonomous navigation and object
detection, validated in both simulated and real-world settings.

Personally, this project fostered substantial growth. Mastering ROS2 and integrating
YOLO for object detection required extensive self-learning, enhancing my ability to tackle
cutting-edge technologies. Troubleshooting independently was pivotal in overcoming tech-
nical hurdles. Additionally, I honed communication skills by organizing complex concepts
for this report and team discussions, strengthening my ability to convey technical details
effectively.

This research contributes to autonomous robotics by addressing real-time communica-

83
Conclusion Chapter 4

tion, control, and navigation challenges, with applications extending beyond this robot to
other autonomous systems. The integration of YOLO, ROS2, and a Flutter app demon-
strates the potential for adaptable, practical solutions.

Future work could focus on reducing detection latency, expanding the object dataset,
or incorporating machine learning for adaptive behavior. Exploring energy efficiency
and multi-robot collaboration will further enhance applicability as autonomous robots
integrate into daily life. This report lays a foundation for ongoing advancements, affirming
the feasibility of autonomous robots in household settings and opening avenues for future
innovation.

84
Bibliography

[1] enis.rnu.tn. Enis, 2024. Accessed: June 22, 2025.

[2] https://www.esme.fr/recherche-ecole-ingenieurs. Esme, 2024. Accessed: June 22,
2025.
[3] ResearchGate. Agile methodology in system development, 2024. Accessed: June 22,
2025.
[4] Medium. Excelling in software development with scrum methodology, 2024. Accessed:
June 22, 2025.
[5] National Geographic France. Al-jazari : l’inventeur des
premiers robots de l’histoire. National Geographic, 2020.
URL https://www.nationalgeographic.fr/histoire/2020/10/
al-jazari-linventeur-des-premiers-robots-de-lhistoire. Accessed: June
22, 2025.
[6] Donald R. Hill. The Book of Knowledge of Ingenious Mechanical Devices. Springer,
1974.
[7] Robotics24.net. Leonardo da vinci’s mechanical knight: A renaissance robot.
https://robotics24.net/leonardo-da-vinci-mechanical-knight, 2023. Ac-
cessed: June 22, 2025.
[8] Alaflashback.blogspot.com. Leonardo’s mechanical knight: The first robot? https:
//alaflashback.blogspot.com/2015/05/leonardo-mechanical-knight.html,
2015. Accessed: June 22, 2025.
[9] WIRED. The mechanical duck that fooled the world. https://www.wired.com/
2016/09/mechanical-duck-fooled-world/, 2016. Accessed: June 22, 2025.
[10] DiTech Media. Charles babbage and the analytical engine: The dawn of comput-
ing. https://ditechmedia.com/charles-babbage-analytical-engine, 2023. Ac-
cessed: June 22, 2025.
[11] National Museum of American History. “tortoise” mobile robot, 1949. URL https://
americanhistory.si.edu/collections/search/object/nmah_879329. Accessed:
June 22, 2025.
[12] Owen Holland. The first biologically inspired robots. Philosophical Transactions of
the Royal Society A, 360:3041–3051, 2002.

85
BIBLIOGRAPHY BIBLIOGRAPHY

[13] SRI International. Shakey the robot, 1972. URL https://www.sri.com/hoi/

shakey-the-robot/. Accessed: June 22, 2025.

[14] Computer History Museum. Shakey – chm revolution, n.d. URL https://www.
computerhistory.org/revolution/artificial-intelligence-robotics/13/
289. Accessed: June 22, 2025.

[15] Clearpath Robotics. Husky ugv: Empowering field robotics. https://

clearpathrobotics.com/husky-a300-unmanned-ground-vehicle-robot/, 2019.
Accessed: June 22, 2025.

[16] Mobile Industrial Robots. Mobile industrial robots. Technical report, 2016. URL
https://www.mobile-industrial-robots.com/. Accessed: June 22, 2025.

[17] Mobile Industrial Robots. Mir100 in action: Flexible logistics automation, 2018. URL
https://www.mobile-industrial-robots.com/case-studies/. Accessed: June
22, 2025.

[18] Boston Dynamics. Spot: Agile mobile robot for industrial applications. https:
//www.bostondynamics.com/products/spot, 2023. Accessed: June 22, 2025.

[19] Boston Dynamics. Atlas: The world’s most dynamic humanoid robot. https://
www.bostondynamics.com/atlas, 2023. Accessed: June 22, 2025.

[20] ROS Wiki. Robot operating system (ros) - ros wiki, 2023. Accessed: June 22, 2025.

[21] ROS.org. Why ros?, 2023. Accessed: June 22, 2025.

[22] ROS 2 Documentation. Introducing tf2 — ros 2 documentation: Humble, 2023.

Accessed: June 22, 2025.

[23] https://commons.wikimedia.org/wiki/File:ROS2_tf2_frames.png. Ros2 tf2 frames,

2022. Accessed: June 22, 2025.

[24] arXiv. Robot operating system 2: Design, architecture, and uses in the wild, 2023.
Accessed: June 22, 2025.

[25] Arrow Electronics. Ultrasonic sensor used for obstacle detection, 2023. Accessed:
June 22, 2025.

[26] Aditya Kamath. Comparing different slam methods, 2020. Accessed: June 22, 2025.

[27] SpringerLink. Comparison and implementation of ros-based slam and path planning
methods, 2021. Accessed: June 22, 2025.

[28] Wevolver. Lidar slam: The ultimate guide to simultaneous localization and mapping,
2023. Accessed: June 22, 2025.

[29] NAV2 Documentation. Navigation 2 documentation, 2023. Accessed: June 22, 2025.

[30] GitHub. Ros 2 navigation framework and system, 2023. Accessed: June 22, 2025.

[31] ROSCon. Roscon 2019 navigation 2 overview, 2019. Accessed: June 22, 2025.

[32] The Robotics Back-End. Ros2 nav2 tutorial, 2023. Accessed: June 22, 2025.

86
BIBLIOGRAPHY BIBLIOGRAPHY

[33] Nidec. Motion control | agv solutions | solutions for autonomous guided vehicles and
mobile robots, 2023. Accessed: June 22, 2025.

[34] SpringerLink. Dynamic performance of industrial robot with cnc controller, 2023.
Accessed: June 22, 2025.

[35] Vecna Robotics. Amrs vs agvs: How autonomous warehouse robots navigate indus-
trial facilities, 2023. Accessed: June 22, 2025.

[36] SpringerLink. System identification, stability analysis and pid controller design for
pem electrolyzer, 2020. Accessed: June 22, 2025.

[37] HSMagnets. Universal magnetic rotary encoders, 2023. Accessed: June 22, 2025.

[38] All About Circuits. How to use a rotary encoder in an mcu-based project, 2023.
Accessed: June 22, 2025.

[39] ROS 2 Navigation Team. Nav2 documentation: Navigation algorithms and configu-
rations. https://docs.nav2.org/, 2024. Accessed: June 22, 2025.

[40] Peter E. Hart, Nils J. Nilsson, and Bertram Raphael. A formal basis for the heuristic
determination of minimum cost paths. IEEE Transactions on Systems Science and
Cybernetics, 4(2):100–107, 1968. doi: 10.1109/TSSC.1968.300136. URL https://
doi.org/10.1109/TSSC.1968.300136.

[41] Dieter Fox, Wolfram Burgard, and Sebastian Thrun. The dynamic window approach
to collision avoidance. IEEE Robotics & Automation Magazine, 4(1):23–33, 1997.
doi: 10.1109/100.580977. URL https://doi.org/10.1109/100.580977.

[42] R. Craig Coulter. Implementation of the pure pursuit path tracking algorithm.
Technical Report CMU-RI-TR-92-01, Carnegie Mellon University Robotics Institute,
1992. Accessed: June 22, 2025.

[43] Ultralytics. Yolo model benchmarks and documentation. https://docs.

ultralytics.com/, 2024. Accessed: June 22, 2025.

[44] Flutter Team. Flutter documentation, 2023. URL https://docs.flutter.dev.

Accessed:June 22, 2025.

[45] Microsoft. Mobile development with xamarin | .net. URL https://dotnet.

microsoft.com/en-us/apps/xamarin. Accessed:June 22, 2025.

[46] React native · learn once, write anywhere. URL https://reactnative.dev/. Ac-
cessed:June 22, 2025.

[47] Android studio. URL https://developer.android.com/studio?hl=fr. Ac-

cessed:June 22, 2025.

87
 Design, Development, and
Implementation of an Autonomous
Robot
Ameur Gargouri
Abstract: This graduation project, conducted at ESME Research Lab, focused on the
design and deployment of an autonomous indoor mobile robot prototype. The project in-
tegrated cutting-edge technologies, including real-time communication, control, and navi-
gation systems. We utilized ROS2 for sensor integration, path planning, and autonomous
navigation, with communication between subsystems enabled by UART protocol and
FreeRTOS, ensuring reliable data exchange. This marked the first-time use of ROS2
and advanced object detection with YOLO, providing valuable practical insights into
autonomous robotics for both the intern and the lab.

Keywords: Autonomous robot, ROS2, real-time communication, UART, FreeRTOS,

sensor integration, path planning, navigation, object detection.

Résumé : Ce projet de fin d’études, réalisé au sein du laboratoire ESME Research

Lab, s’est concentré sur la conception et le déploiement d’un prototype de robot mobile
autonome intérieur. Le projet a intégré des technologies de pointe, incluant des systèmes
de communication, de contrôle et de navigation en temps réel. Nous avons employé ROS2
pour l’intégration des capteurs, la planification de trajectoires et la navigation autonome,
avec une communication entre sous-systèmes assurée par le protocole UART et FreeRTOS,
garantissant un échange de données fiable. Ce fut la première utilisation de ROS2 et de
la détection d’objets avancée avec YOLO, offrant des enseignements pratiques précieux
en robotique autonome pour le stagiaire et le laboratoire.

Mots-clés: Robot autonome, ROS2, communication en temps réel, UART, FreeRTOS,

intégration de capteurs, planification de parcours, navigation, détection d’objets.

úÍð @ h. XñÖß Qå„ð ÕæҒ úΫ Q»Pð ESME Research Lab Q.Jm× Ég@X h. QjJË@ ¨ðQå„Ó YJ®JK Õç' :‘jÊÖÏ @
 ú¯ ékCÖ
I ¯ñË@  Ï @ð ,ÕºjJË@ ,ÈA’B@ éÒ  ¢ @ É҂  , èPñ¢JÓ HAJ  J® K ¨ðQå„ÖÏ @ l×. X @ . úÎg@X É® J‚Ó ¼QjJÓ HñK  . ðQË
áK. ÈA’B@ àAÖޕ ©Ó , éJ K@ YË@ ékCÖ  Ï @ð H@  P A‚ÖÏ @ ¡J¢m' ð PAª‚ ƒB@ èQêk @ ÉÓA¾JË ROS2 AJÓYjJƒ@ . úΪ®Ë@
.
 
 KñÓ B XAJK Q¯ñK AÜØ , FreeRTOS ÐA¢ ð UART Èñ»ñKðQK Ð@YjJƒAK éJ «Q®Ë@ éÒ
 KAJJ.ÊË A¯ñ  ¢ B@
Èð @ @ Yë àA¿ . HA . . .
 ¯ éJ ÊÔ« ø ðP ÐY¯ AÜØ , YOLO ©Ó éÓY
ÈAm.× ú¯ éÒJ  ® JÖÏ @ @Q« B@ á« ­‚ºË@  AJk. ñËñJºKð ROS2 Ë Ð@YjJƒ@
.Q.JjÖÏ @ð H. PYJÖÏ @ áÓ É¾Ë éÊ ® J‚ÖÏ @ HA
 KñK. ðQË@

èQêk @ ÉÓA¾K , FreeRTOS , UART , úΪ®Ë@ I ¯ñË@

 ú¯ ÈA’B@ , ROS2 ,É® J‚Ó HñK
 . ðP :iJKA®ÖÏ @ HAÒʾË@

.
 Ï @ ,PA‚ÖÏ @ ¡J¢m' ,PAª‚ ƒB@
 , ékCÖ
. @Q« B@ ­‚»