Mobile Robot Control 2023 R2-D2

Group members:

Name	student ID
Ismail Elmasry	1430807
Carolina Vissers	1415557
John Assad	1415654
Jelle Cruijsen	1369261
Florian Geister	1964429
Omar Elba	1492071

General Requirements of the wiki page

• Is there an introduction/conclusion? (yes, at least there's a heading for that)
• Is there a logical ordering storywise? (must be checked afterwards, need to have all the components of the functionalities, and everything we have done so far written down to not miss anything, then we can order)
• Interpretability/readability: proper grammar, use of figures etc. (check afterwards, did we check comments in the code so it can be read and understood easily?

Design Presentation

File:MRC Design.pdf Presentation pdf:

-- About the design presentation: Possible Extension Algorithms and why we don't use them any more

Introduction

The main challenge is to design, structure and implement, later execute, a working programm for a mobile robot that takes a starting sequence as an input to serve tables in a restaurant according to that sequence of tables to serve.

In order to do that, the course provided us, beside lectures, with exercises to get properly introduced to the robot simulation environment, the robot itself, as well as programming in general in C++. After a first introduction to the course, we started with a 'Don't crash' exercise to have a proper tool in hand for the robot to safely move around an environment. The next was the 'A*-algorithm' to plan and find a specific goal in a given grid. An introduction to an 'Open Space Approach' exercise We then finished with the 'Localizaion' exercise to let the robot know where it is in a given environment.

The main objective is to deliver orders to a specific table in a restaurant environment. For this, it needs to get the table sequence, then plan the path to the required table, drive to the table, avoid any obstacles within driving and then deliver the the order by driving near the table, facing it and giving a sound signal. This process must then be repeated.

For the challenge, requirements are set in advance. That includes to neither touch walls or obstacles like objects or people, visit the tables in the given order and also within 10 minutes. The maximum speed is set to 0.5 m/s translational and 1.2 rad/s rotational.

As a bonus, detected static and dynamic objects should be detected and presented in the world model of the robot.

This report presents an in-depth analysis of the Restaurant Challenge, focusing on the system description, software architecture, strategy employed, robustness considerations, and evaluation of the challenge. The Restaurant Challenge is a challenge that assesses the capabilities of an autonomous robot to navigate and deliver orders within a restaurant environment. The challenge requires teams to develop software and algorithms for their robot, known as Hero, enabling it to autonomously navigate through the restaurant, avoiding obstacles and humans, while accurately delivering orders to designated tables.

The report begins by introducing the challenge overview as well as the system description then follows by outlining the state flow and data flow created for the challenge. The state flow details how Hero progresses from the start area to the designated tables, while the data flow explains how information is exchanged and processed within the system.

Furthermore, the report covers the strategy employed by the team to tackle the Restaurant Challenge. This includes a discussion of the global planner responsible for determining the overall path, the local planner handling immediate obstacles and route adjustments, the particle filter aiding in localization, and the main algorithm that orchestrates the entire delivery process.

A crucial aspect of the challenge is the software architecture developed. This section of the report explores the architecture's design, how it was organized and its effectiveness in enabling Hero to perceive and navigate the environment, handle object detection, and execute the delivery task.

The report also addresses the robustness considerations involved in the challenge, ensuring that Hero can handle unexpected situations, such as collisions, stalls, or navigational uncertainties. Therefore, the software needs to be designed with this in mind, and this section evaluates the robustness of the implementation created.

Finally, the report discusses the results of the Restaurant Challenge. The performance of Hero will be assessed based on criteria such as successful delivery completion, adherence to the correct table order, object detection capabilities, and overall navigation efficiency. The evaluation section will include a discussion of the results, lessons learned throughout the challenge, things that could have been improved and future considerations. The report will then be concluded with a brief conclusion that describes the main achievements that were successfully completed.

Through this report, we aim to provide a comprehensive analysis of the Restaurant Challenge, shedding light on the technical aspects, strategies employed, software architectures developed, and evaluation outcomes. This knowledge contributes to the advancement of autonomous navigation and delivery systems, fostering innovation in real-world scenarios where robots can assist in restaurant operations and similar tasks.

Challenge Overview

The Restaurant Challenge is designed to test the navigation and delivery capabilities of Hero, an autonomous robot. The objective of the challenge is to deliver orders to designated tables in the correct order provided, following a specific set of rules and conditions. The challenge environment consists of a restaurant setup, including walls, tables, doors, and both static and dynamic objects.

At the start of the challenge, Hero is placed in a designated start area with an unknown orientation. The list of tables to be visited in the correct order is provided just before the challenge begins. Hero's task is to navigate through the restaurant, avoiding obstacles and humans, and reach each table to deliver the orders.

The delivery of an order is defined by driving up to the table, positioning near the table while facing towards it, and giving a clear sound signal to indicate Hero's arrival. The exact positioning next to the table is not critical as long as the robot is close enough for a customer to comfortably take their order from the tray.

The challenge environment specifications state that the walls are approximately straight, and tables are solid objects represented as rectangles in the LiDAR measurements such that it is not necessary to detect the legs of the tables. Doors may be open or closed, and there can be multiple routes to a given goal. Furthermore, the presence of dynamic objects in the form of humans adds complexity to the navigation task. Additionally, static obstacles such as chairs that are unknown to the robot and not present in the map given may be placed throughout the restaurant. Their detection and influence on the path taken is an additional challenge that needs to be overcome.

The challenge is subject to specific rules, including restrictions on touching walls or objects, limitations on robot speed, and time limits for each trial. Two trials are allowed, with a maximum of one restart per trial. A trial ends if Hero bumps into a wall or object, remains stationary or makes non sensible movements for 30 seconds, exceeds the total time limit of 10 minutes, or if a restart is requested. A restart allows Hero to return to the start position while resetting the trial time but not the total time.

The overall goal of the challenge is to demonstrate the robot's ability to autonomously navigate a complex environment, accurately deliver orders to designated tables, and effectively handle dynamic obstacles. The teams' performance will be evaluated based on their ability to complete the task within the given constraints.

System Description

For this assignment, the robot, Hero, will be used. The Hero robot, used in this assignment, has certain limitations on its maximum speed. Its translational speed is limited to 0.5 m/s, while its rotational speed is limited to 1.2 rad/s. To establish communication with the robot, two types of inputs can be utilized: laser data from the laser range finder and odometry data from the wheels.

The laser range finder provides information about the distances between the robot and its surrounding objects. The range_min and range_max values define the minimum and maximum measurable distances, respectively. Any distance reading below range_min or above range_max is considered invalid. Furthermore, the angle_min and angle_max values determine the angles of the first and last beams in the measurement. The angle_increment value can be derived from angle_min, angle_max, and the number of beams. The actual laser sensor readings are stored in a vector of floats of which each reading is associated with the ranges. Each element in the vector corresponds to a measured distance at a specific angle, which can be calculated using angle_min, angle_increment, and the index of the element in the vector. Additionally, the timestamp associated with the laser data indicates the time at which the measurements were taken.

Moreover, odometry provides information about how far the robot has traveled and how much it has rotated. Each wheel and the rotational joint are equipped with encoders that keep track of their respective rotations. By utilizing the encoder data from all sources and considering the wheel configuration, it is possible to calculate the displacement and rotation of the robot since its initial position. However, it is important to note that odometry data is susceptible to drift due to small measurement errors and wheel slip, which accumulate over time. Therefore, relying solely on odometry data for longer periods is not recommended. Additionally, it is essential to be aware that the odometry data does not start at the coordinates (0,0), indicating that the robot's initial position may be different from the origin. Thus, the utilization of a particle filter will be needed.

Apart from the laser and odometry data, the Hero robot is equipped with two separate bumpers, each acting as an individual sensor. Therefore, to obtain bumper information, the data from each bumper should be retrieved individually which would provide information about whether the robot made contact with an obstacle, from the front or the back.

Furthermore, the velocity command given to the robot can only realize movement in the x-direction (which is forward and backwards), and rotate with a given input rotational velocity. Thus, by understanding these different types of input data, the robot can be controlled, and made to navigate without collision.

Strategy Description Restaurant Challenge

Strategy

Q: Strategy regarding our project work, distribution and how we do get to the solution or more by means of strategy on how the system should work (Data or Design flow).??

Q: Why the grade of the design presentation?

Q: What about the map generation? Mention the algorithm we used for the small restaurant map with only two tables? Detailed description on how we did it, how much work it is and why we did it

• Main strategy of the robot: State approach, Specific functions called after states are set, function between algorithm parts
• Is the behaviour described logical and is the description complete
• Reasoning of the used algorithms? Were the algorithms sufficient or too simplistic? (Time regarding the dismissing of the SLAM algorithm, any new algorithms we used or introduced to extend the existing ones?
  • Detailed description of the algorithms (Every function, every part, every file)

*Maybe also add a description of some of the challenges we faced for each section and how we overcame them

Local Planner

Open Space

In the implemented open space approach, the robot utilizes laser data to navigate through the environment by identifying and traversing through open spaces or gaps between obstacles. This approach enables the robot to safely move without colliding with objects in its path. The algorithm consists of several key steps:

1. Gap Detection: The algorithm analyzes the laser scan data to identify gaps or open spaces. It examines consecutive laser points within a specified range (2π/3 cone in front of robot) and checks if their distances exceed a certain threshold, look ahead distance that begins at 0.8 meters. If a sequence of laser points with distances greater than the threshold is found, it indicates the presence of a gap.

2. Gap Width Evaluation: After detecting a potential gap, the algorithm evaluates its width to determine if it is wide enough to be considered a significant open space. A minimum gap width criterion is set to 100 laser pointers to ensure that the detected gap is large enough to fit the width of the robot such that it can safely drive within this gap.

3. Open Space Search: The algorithm searches for open spaces within the laser scan data by iteratively applying the gap detection process. It gradually adjusts the look ahead distance parameter by decreasing it by 10% each iteration to find wider gaps if no suitable gap is found initially. However, it should be noted that this look ahead distance should never decrease below the obstacle distance defined. This adaptive mechanism allows the robot to explore different distances and adapt to the environment's characteristics.

4. Open Space Calculation: Once a significant gap is detected, the algorithm calculates the distance and rotation required for the robot to navigate through the open space. It determines the start and end indices of the laser scan range representing the open space and uses this information to calculate the desired rotation angle. The algorithm also accounts for small adjustments to the rotation angle to ensure smooth and precise navigation.

By implementing the open space approach, the robot can effectively plan its trajectory by identifying safe areas to move through. This strategy minimizes the risk of collisions and enables efficient navigation in complex environments.

Software Architecture Restaurant Challenge

Software Architecture

• Logical interaction between software components (states, calling of functions, actively activating and disabling of functions)
• Are the components implemented correctly (any errors seen?, how about any issues that still persist?)

Robustness Restaurant Challenge

Robustness Restaurant Challenge

• How was the performance verified (objectives fullfilled?, simulation of particle filter)
• What kind of tests were performed to check robustness (moving in front of a moving robot to check obstacle avoidance, changing accuracy of walls, simulations, visualizing particle filter, pathfinding, checking components of the final program like specific algorithm parts)
• Comments on robustness

Evaluation Restaurant Challenge

Evaluation Restaurant challenge

• Reflection on performance
• Conclusions about what could have gone better