Mobile Robot Control 2020 Group 8

Group information

Group Members

Name	Student Number
J.J.W. Bevers	0904589
J. Fölker	0952554
B.R. Herremans	0970880
L.D. Nijland	0958546
A.J.C. Tiemessen	1026782
A.H.J. Waldus	0946642

Meeting Summaries

A logbook with a summary of the contents of each meeting is documented and can be found here.

Course description

Introduction

Figure 1: PICO.

As is proven during the current situation concerning the COVID-19 pandemic, our healthcare system is of high importance. However, there are shortcomings for which an efficient solution is required. At the time, hospitals are occupied by many patients. Therefore, doctors and nurses have limited time for human-to-human contact with patients. By automating simple tasks, doctors and nurses have more time for contact with patients. An option is to use an autonomous embedded robot to assist in everyday tasks such as getting medicine, moving blood bags or syringes and getting food and drinks. During this course, software for such an autonomous robot is developed. The goal is to complete two different challenges in a simulated environment: the Escape Room Challenge and the Hospital Challenge.

PICO

The mobile robot used is called PICO and is shown in Figure 1. PICO consists of multiple components. This year's edition of the course will be completely based on the PICO simulator (as developed by the project team) and will, thus, not contain the implementation of the software on the actual robot. Only the relevant components for simulations are, therefore, briefly explained. For actuation purposes, PICO has three Omni-wheels which make for a holonomic base. A Laser Range Finder (LRF) is used by PICO to scan its surroundings, providing PICO with distance data. Furthermore, the wheel encoders data is used to keep track of PICO's translations and rotation (odometry).

Figure 2: Example of the map used for the Escape Room Challenge (left) and the Hospital Challenge (right).

Escape Room Challenge

The goal of this challenge is to navigate PICO, through a corridor, out of a rectangular room of unknown dimensions without bumping into walls. An example of an environment map that might be encountered during this challenge is shown on the left side of Figure 2. PICO has an unknown initial position within this room. Thus, PICO first needs to detect and recognize the exit. When the exit is found, PICO has to exit the room as fast as possible by moving through the corridor. The challenge is finished when the rear wheels of PICO cross the finish line entirely. In the Section Escape Room Challenge, the approach is explained in more detail. Here, the algorithms used and its implementations are explained. Moreover, the results of the challenge are shown and discussed.

Hospital Challenge

This challenge represents an example of the application of an autonomous robot in a more realistic environment. In this challenge, PICO has to operate in a hospital environment. The environment will consist of multiple rooms, a hallway and an unknown number of static- and dynamic objects. In the rooms, cabinets are present that contain medicine. In this challenge, PICO will first need to recognize its initial position in the known environment. Next, PICO has to plan a path to various cabinets in a predefined order, representing the collection and delivery of medicine. When executing this path, PICO needs to prevent collisions with walls and static- and dynamic objects. An example environment is shown on the right side of Figure 2. In Section Hospital Challenge, more information will be provided.

Design document

In this section, an adapted version of the design document is found which incorporates received feedback. The original design document can be found in Section Deliverables. The design document serves as a generic document applicable to both challenges. The functions listed are an initial guess of what is thought to be needed before actually working on the software. When producing the software, the actual functions arose. These functions are listed and explained in the Sections Escape Room Challenge and Hospital Challenge.

Requirements and Specifications

A distinction is made between general and competition specific requirements. Three stakeholders are considered: the hospital employees, the patients and the software engineers. In ascending order, the requirements are subdivided into environment requirements, border requirements, system requirements and function types. Five functions types are introduced: Localization(L), Detection(D), Mapping(M), Path Planning(PP) and Motion Control(MC). These are elaborated in the next section. The requirements are shown in Figure 3 and elaborated below. Note the legend located bottom right. First, the five environment requirements will be discussed in more detail. Even though the environment requirements are shown as separate parts, they do relate to each other. The first three environment requirements correspond to the functionality of PICO and are thus relevant for both challenges. The fourth and fifth environment requirement are specifically defined for the Escape Room- and Hospital Challenge, respectively.

• PICO should operate autonomously: No interaction is allowed, unless an emergency stop is needed. To start the software, the ’git pull’ command is used to update, the ’cmake’ and ’make’ commands are used for compiling and one executable is used to start execution.

• PICO can only stop executing when its task is finished: Therefore it must be able to verify when it is finished. Also, PICO cannot be stationary for 30 consecutive seconds and the task must be finished in time. PICO should operate safely. In order to do so, it must obey speed limits. A maximum transnational and rotational speed of 0.5 m/s and 1.2 rad/s, respectively, are set.

• PICO can not bump into walls: Therefore, PICO should be able to detect walls and keep a certain distance. PICO should provide information on its state. Therefore, PICO should visualize its sensor data, produce and visualize a map and its current position and finally visualize its produced path.

• PICO should finish the Escape Room Competition: To succeed, PICO must be able to identify the exit and it should exit as fast as possible. A strategy is explained in the next section.

• PICO should finish the Hospital Competition: PICO should deliver medicine. Therefore, PICO must recognize cabinets, drive to them, position in front of them facing towards them and afterwards produce a sound signal. PICO should operate in the hospital environment. Therefore it must recognize its (initial) position in the provided map. Finally, PICO should not bump into static or dynamic objects. Thus PICO should detect an object within a 10 meter range and the distance between PICO and a static or dynamic object must be at least 0.2 m and 0.5 m respectively.

The hospital employees are involved in the first, second and fifth requirement, the patients in the second and fifth and the software engineers in the first, third and fourth.

Figure 3: The general requirements (left), the competition specific requirements and legend (right).

Functions

The finite state machine displayed in Figure 4 depicts the designed behavior of PICO, allowing it to complete the two challenges. The states are:

• State I - Initializing: PICO performs an initial scan of it’s surroundings and maps this data to find its position on the map. It is possible that insufficient information has been gathered to do this when, for instance, all objects are out of reach of the laser range finder.

• State II - Exploring: An exploration algorithm such as a potential field algorithm or a rapidly expanding random tree algorithm is used to explore the environment further. When PICO’s position within the map is known and the exploration algorithm has been executed for T seconds, the transition to State III occurs.

• State III - Planning: After PICO has localized itself on the map, enough information has been gathered to compute a path towards a target. An algorithm is used to compute a state trajectory, that is then translated into control actions.

• State IV - Executing: During this state a control loop is executed which controls PICO towards the reference coordinates (x,y) by measuring position and actuating velocities. When PICO runs into an unexpected close proximity object, the state is transferred to State V. When PICO runs into an unexpected distant proximity object, the state is transferred to State III, such that a new path can be planned before PICO arrives at this object.

• State V - Recover: During the recover state, PICO has encountered a close proximity object which it did not expect. PICO then immediately stops and when completely stopped, it transits to State II, such that the exploration algorithm can move PICO away from this unexpected object for T seconds. The loop (State II, State III, State IV, State V) can be executed repeatedly and can be counted, such that T increases when more loops are encountered.

• State VI - Reached: After the path execution has been finished and PICO has reached the end of the path, PICO stops moving as it has reached its target location.

Figure 4: Finite State Machine

FUNCTION	DESCRIPTION
Localization
InitialScan()	PICO makes a rotation of 190 [deg] to get a full 360 [deg] scan of the environment
GetMeasurement()	Read out the laser range finder sensor data
Detection
ProximitySense()	Detects if an unexpected object is in close proximity
DistantSense()	Detects if an unexpected object is in distant proximity
Mapping
UpdateMap()	Write measured data to Cartesian 2D world map used by path planner
UpdatePotField()	Write measured data into potential field map used by potential field algorithm
GetMap()	Retreive current 2D carthesian world map and (x, y) position of PICO
GetPotField()	Gets gradients from the potential field
Path Planning
GetGoal()	Retrieve Cartesian coordinates of the goal (xg, yg) with respect to the map
PlanPath()	Path planner algorithm using the 2D world map to plan a state trajectory (x, y array)
ComputePotState()	Uses gradients from potential field as input, to compute a state reference ẋ, ẏ, \dot{θ}
ReadPath()	Get current (x, y) goal of path array
Motion Control
Move()	Send position reference (x, y, θ) to PICO. Contains position control loop
StopMoving()	All movements of PICO are stopped: ẋ, ẏ, \dot{θ} = 0
FullRotation()	PICO makes one full rotation
ExecutePath()	Translates (x, y) path reference into controller action for calling Move(). Loop over all (x, y) to achieve position reference tracking

Software Architecture

The proposed information architecture is depicted in Figure 5. It shows a generic approach, so note that a specific challenge may require additional functionalities and interfaces. Between the software and mechanical components, information is shared via interfaces marked in green and labeled with an arbitrary number or letter. These interfaces dictate what information is set by which component and what information is shared, and among which components. In the central section, this schematic overview visualizes what capabilities are intended to be embedded in the software. Firstly, interface 10 represents the data received from the user, which may include a JSON file with a map and markers, depending on the challenge. On the right, interface 1 between PICO (including the provided software layer) and the designed software shows the incoming sensor data, i.e. structs with distance data from the Laser Range Finder (LRF) and odometry data based onthe omni-wheel encoders. This data is (possibly) processed and used to map PICO’s environment (mapping), to estimate PICO’s position and orientation (localization), and to detect static/dynamic obstacles (detection), via interfaces 2, 3 and 5. This knowledge is stored in the world model,serving as a central data-base. Via interface 4, a combination of the current map, PICO’s poseand the current (user-provided) destination is sent, to plan an adequate path. This path is sent over interface 8, in the form of reference data for the (x,y,θ)-coordinates. The motion controlcomponent will then ensure that PICO follows this path by sending velocity inputs over interface 9. Simultaneously, the detection monitors any static/dynamics obstacles on the current path online. If this is the case, interfaces 6 and 7 serve to feed this knowledge back to either the path planning component to adjust the path or directly to motion control to make a stop. On the left, interface A between the behavior scheme and the capabilities shows that the high-level finite state machine manages what functionality is to be executed and when. Interfaces B represent the data that is chosen to be visualized to support the design process, i.e. the visualization serves as a form of feedback for the designer. The information that is visualized depends heavily on the design choices later on in the process and, therefore, this will not be explained further.

Implementation

The components described above are intended to be explicitly embedded in the code through the use of classes. The functionality that belongs to a certain component will then be implemented as a method of that specific class. At this stage of the design process, the specific algorithms/methodsthat will be used for the functionalities are not set, but some possibilities will be mentioned here. Simultaneous mapping and localization (SLAM) algorithms, based on Kalman filters or particle filters, could be used for the mapping and localization components. Moreover, for path planning, Dijkstra’s algorithm, the A* algorithm or the rapidly-exploring random tree algorithm can be used.For motion control, standard PI(D) control, possible with feedforward, can be used to track the reference trajectory corresponding to the computed path. Additionally, for detection, artificial potential fields can be used to stay clear from obstacles.

Figure 5: Software Architecture

Escape Room Challenge

In this section, the strategy for the Escape Room Challenge is discussed, as well as the algorithms that are used. The software for this challenge can be roughly divided into three main parts: the finite state machine, the potential field algorithm and the exit detection algorithm. These will be covered next. Moreover, for testing, an extra output window is created in which the behaviour of PICO with the created software is shown. This output window will also be used to demonstrate how the different algorithms work.

Finite state machine

A Finite State Machine (FSM) that describes the robot's behavioral scheme is designed, forming the basis of the software architecture. The FSM describes which states can be reached from a certain state, given the response of that state to some input. For the Escape Room Challenge, a total of four behavorial states are implemented as can be seen in Figure 4. The states of the FSM are defined as followed:

Initializing: PICO performs an initial scan of its surroundings and searches for the exit. If the exit is detected, the detection algorithm will place a target in the middle of the beginning of the exit corridor and the state transitions to the executing state. If the exit is not detected after the first rotation of 360 degrees, the state transitions to the exploring state.

Exploring: A potential field algorithm is used to explore the environment. Untill the detection algorithm has located the exit, PICO will drive in a straight line untill it reaches a wall. When a wall is reached, the repulsive field of the wall becomes stronger than the atrractive field that is placed 1m in front of PICO, making the robot rotate away from that wall. This movement continues untill the exit is detected

Executing: In the executing state, an attractive field is placed on the location that the detection algorithm has indicated as a target. The vector that follows from the combined attractive and repulsive field is translated into translational and rotational velocities, which are used as input for the robot motion. Multiple targets can be identified in the executing state, for example the beginning of the exit corridor and the end of the exit corridor. When PICO has reached the final target and it no longer detects any walls, the state transitions to the reached state.

Reached: After the path execution has finished and PICO has reached the end of the exit corridor, PICO stops moving as it has reached its final target location.

Figure 4: Finite State Machine.

Potential field algorithm

During the Escape Room Challenge, the direction and magnitude of the velocity of PICO is guarded by the potential field algorithm. The potential field within a mapped environment consists of a rejective field and an attractive field. An example of a gradient field from the rejective field is shown in Figure 6. For the Escape Room Challenge, however, it is chosen not to use a worldmap as this would unnesesarily overcomplicate computations. Therefore the rejective field vector at PICO’s current position is computed based on all current LRF data, such that the gradient with respect to PICO’s local coordinate frame based on its current measurements is computed. For the attractive field, the current goal relative to PICO’s local coordinate frame is required. This goal is provided by the exit detection algorithm. The vector corresponding to the gradient of the attractive field is computed by means of a convex parabola in the XY-plane with respect to the local coordinate frame of PICO, which has its minimum at the goal relative to PICO’s local coordinate frame. Both the rejective and the attractive field vectors are normalized to have a magnitude of 1. This avoids the effect that the rejective field is stronger when PICO observes more datapoints at a certain moment, which could give a distorted effect in the magnitude of the rejective field gradient vector.

Figure 6: Example of rejective field gradients.

The normalized field vectors are then used to control the motion of PICO. In order for PICO to always be able to see the goal, and thus obtain an estimation of the goal relative to PICO's coordinate frame, the orientation of PICO is controlled such that it always aligns with the direction of the attractive field vector. This control is a feedback loop, with the error equal to the angle of the attractive field vector with respect to PICO’s X-axis, and as controller a simple gain.

The velocity in X and Y with respect to PICO’s local coordinate frame is actuated using both the normalized attractive and repulsive field vectors. In order to combine these vectors, the minimum distance to an object “Dmin” is measured. This measurement is used to compute the contribution factors of the attractive and repulsive field as follows. When “Dmin” is smaller than a tuneable tolerance “Dmint”, these factors are multiplied with the corresponding field vectors and then the average is used. This way the rejective field is stronger when PICO is near a wall. The 1/x function allows to drive fairly close to a wall but not collide with it. Furthermore when “Dmin” is larger than the tolerance “Dmint”, The forward vector component in X- and Y-direction consists of the attractive field vector and repulsive field vector with factor 1.

Figure 7: Contribution factors of rejective and attractive field vectors.

This thus yields a new vector relative to PICO’s local coordinate frame. This vector can still have a magnitude smaller or larger than 1. When the magnitude of this vector is larger than 1, it is limited to 1, such that the X and Y components of this vector can be multiplied with PICO’s maximum velocity such that the maximum velocity is never exceeded, but it still enables PICO to drive more slowly, for example when moving through a narrow corridor in which the rejective field is very strong.

During testing, it was noticed that the exit detection algorithm can sometimes rapidly switch between detected targets relative to PICO. When this rapid switching occurs, it is unwanted that PICO rapidly adjusts its direction. Therefore when this rapid switching is detected, the vector corresponding to the gradient of the attractive field is filtered using a low-pass filter with a relatively low bandwidth. When no switching is detected, thus in the regular case, this vector is filtered using a low-pass filter with a relatively high bandwidth allowing for faster adjustment of this vector.

Of course, it is possible that at a certain time instance PICO receives a relative goal. At the next time instance it might be possible that the exit detection algorithm does not provide a goal. Therefore, each time the potential field algorithm obtains a goal, it captures the orientation of its local coordinate frame with respect to the world coordinate frame based on odometry. Furthermore, the distance to the goal relative to this local coordinate frame is logged. In the next iteration, when the potential field algorithm is called with a flag “0”, corresponding to the case that at this call no relative goal is provided, PICO uses the odometry data to move to the last known goal with respect to the last known coordinate frame. During this motion, PICO maintains the orientation of the last known attractive field vector when a goal was still provided. Of course, when the distance to its last known coordinate frame increases, the position error increases. Nonetheless when the exit detection algorithm initially provides a goal which lies 1 [m] in front of PICO, and then can no longer detect this relative goal, PICO will move forward and measure the traveled distance using the odometry until it has traveled the distance of 1 [m] with respect to PICO’s local coordinate frame when a goal was provided. When this distance has been traveled, PICO stops moving. This way some additional redundancy has been built in, such that PICO can still move when no goal can be provided at a certain time instance.

Exit detection algorithm

For the Escape Room Challenge, it is not required to compute PICO's global location and orientation, i.e. its global pose, within the room. In fact, this is not even possible, because the dimensions of the room are not known and the room may also not be perfectly rectangular. Even if it were, it is unlikely that it would be possible to uniquely compute the robot pose from the LRF data. Since the mere goal of this challenge is to drive out of the room via the corridor, the exit detection algorithm must detect where the exit is relative to PICO's current position, i.e. the target. This information then serves as an input to the potential field algorithm to compute the attractive field. Note that this algorithm, thus, serves as a means of meeting (border-)requirement 'Identify Exit'.

The following considerations are taken into account:

• Looking forward, it is decided that it is preferred to already implement as much intelligence as possible which may later function as part of the localization component of the software for the final Hospital Challenge.
• In order to feed the potential field algorithm effectively, i.e. in such a way that it is expected to yield a smooth motion, it is also preferred to first compute the center position of the start of the corridor. Only once PICO is positioned sufficiently in front of (or in) the corridor, the center position of the end of the corridor should be computed. If, for example, the target were always placed at the end of the corridor, guided by means of the potential field algorithm, PICO will first drive on a path deemed for collision with a wall. Only when sufficiently close to the wall, PICO would be guided along the wall, towards the corridor.
• Moreover, a significantly accurate estimate of these positions is required.

For this reason, instead of simply detecting gaps in the LRF data, the exit detection algorithm must be able to:

i) divide the LRF data into segments belonging to seperate walls,

ii) fit lines on these walls (to minimize the influence of LRF data noise on PICO's perception),

iii) use these fits to compute corners and edges, and

iv) use theses corners and edges to compute the target position.

The exit detection algorithm, therefore, incorporates data pre-processing, data segmentation, line fitting, corners and edges computations, and target computations. These individual parts of the algorithm will be further elaborated below.

Data pre-processing

Firstly, the LRF data is pre-processed by simply filtering out data that lies outside of the LRF range, i.e. below its smallest and above its largest measurable distances, 0.01 and 10 m, respectively. It is then converted to Cartesian coordinates relative to PICO's local frame (see Figure x):

where ρ_i is the measured distance and θ_i the corresponding angle. Note that the index i starts at 0 (and, thus, ends at 999).

Figure x: PICO's local frame and conventions.

Data segmentation

The procedure that is applied to divide the LRF data into segements is inspired by the famous image processing technique, split and merge segmentation. It is based on the criterion that, if all data points in a considered range lie within a treshold distance to a straight line connecting the first and last data point of that range, a segment is found. This approach is especially suited in the context of the two challenges, because the walls of PICO's environment are (sufficiently) straight. Moreover, the static objects of the Hospital Challenge are (sufficiently) rectangular. The iterative procedure encompasses the following steps and computations:

1. Start with the first and last data points, corresponding to θ = -2 rad and θ = 2 rad, respectively (assuming these have not been filtered out during pre-processing). Set i_start and i_end, respectively, equal to the corresponding indices (0 and 999).

2. Compute the perpendicular distances, d_i, of all other data points to a straight line from data point i_start to i_end [1]:

Here, (x_1,y_1) and (x_2,y_2) are the Cartesian coordinates of data points i_start and i_end, respectively.

3a. Compute the maximum of all distances computed at step 2 and the corresponding index. If this distance is below a certain treshold (which accounts for measurement errors), go to step 4, otherwise, go to step 3b.

3b. Split the segment, i.e. set i_end equal to the index computed at step 3a, and go back to step 2.

4. A new segment is found. Save the indices of the first and last data point belonging to the segment, i.e. i_start and i_end. Set i_start = i_end + 1 and i_end = 999 (again, assuming this data point is not filtered out during pre-processing), and return to step 2.

5. Repeat this procedure until all data points are considered, i.e. until i_start is no longer smaller than the index corresponding to the last data point.

After the segmentation procedure has terminated, segments consisting of a number of data points that is below a certain treshold are discarded. This adds robustness, because occasionally segments only consist of 2 data points, for example, and thereby may form the two edges of an opening. Moreover, a sufficient number of data points is required to obtain a reliable fit.

Line fitting

Next, a line y = ax+b is fitted onto each segment by means of the linear least-squares method. It can be shown that the solution is

where N_seg is the number of data points in the considered segment and the sums run over index i, going from the indeces corresponding to the first data point of the segment to the last [2]. For each segment, the coefficients a and b are stored. The resulting fits are shown in Figures 6-8 as blue lines.

A serious drawback of this approach is that it is not possible to represent vertical lines, because coefficient a goes to infinity. This means that no reliable fit is found for walls that are more or less parallel to the y-axis of PICO’s local coordinate frame. Nonetheless, it is a very simple approach that will show to suffice for exit detection purposes.

Corners and edges computations

For subsequent segments, the Euclidian distance between their neighbouring endpoints, i.e. the last data point of segment j and the first of segment k=j+1, is computed. If this distance is below a small treshold, a corner is assumed to be found. To compute its coordinates, the intersection of the line fits of the two segments is computed. If the distance is not below the treshold, an edge is found which is a point at which either a jump in the LRF data is observed or at which there is a gap (a set of angles over which no distance within range is measured) in the LRF data. Within the context of the Escape Room challenge, the first occurs if, for instance, PICO ‘looks’ at the corridor at an angle; the latter occurs if, for instance, PICO ‘looks’ into the corridor. Edges, obviously, also occur at the first and last data point of the (pre-processed) LRF data.

For each segment, the coordinates of its first and last point are saved, whether it is a corner or an edge. The resulting corners and edges are shown in Figures 6-8 as red circles.

Target computations

A corridor (entrance) is possibly detected if edges occur between two subsequent segments (in order to exclude the edges at the very first and last data points). Two cases are distinguished for the situation where PICO can ‘see’ the corridor:

1. PICO scans both of the walls on either side of the corridor, i.e. PICO is located in the region directly in front of the corridor, and

2. PICO scans one of the walls of the corridor and the corner of the entrance on the other side of the corridor.

Determining which case is observed is based on the slopes (coefficient a) of the lines fitted through the subsequent segments. In case 1, the observed walls should be more or less parallel, so their slopes should be equal up to a certain treshold. In case 2, on the other hand, the walls should be more or less perpendicular, so a_j should equal -1/a_k up to a certain treshold.

1. In case 1, the edge that is furthest away from PICO is used. A line is drawn through it, perpendicular to the line fit of the opposite corridor wall. The midpoint of this line serves as target.

2. In case 2, the edge closest to PICO is used. Similarly, a line is drawn through it, perpendicular to the line fit of the opposite corridor wall. Again, the midpoint of this line serves as target.

The resulting target is shown in Figures 6-8 as a yellow circle. The method described here serves the purpose well, because a target is first placed at the entrance of the corridor. Only after PICO is already in front of the corridor, the target is placed further into the corridor and, eventually, at the actual end of the corridor.

Visualization and Testing

In order to see how the developed algorithm operate, a visualization is made using the openCV library. With this library dot, line, arrow, circle and rectangle shapes are created to represent the laser range data, detected walls, velocity vectors, corners and PICO respectively. These shape objects are drawn on a window iteratively representing PICO and its interpretation of the surrounding, as can be seen in Figure 6.

Using this visualization, the program can be tested to optimize the behaviour of PICO. To explain main parts of the testing phase, three test cases are considered. However, a lot more cases have been tested in order to ensure robust behaviour of PICO while leaving the room.

Test 1: Large Room and Parallel Exit

As shown in Figure 6, PICO is positioned in a large wide room with the exit parallel to one of the walls. In this case, PICO is not able to see the whole room at once because some walls are too far away. In this case, detection of the exit can be a challenge and therefore PICO is programmed to initially start moving away from the walls untill the exit is detected. This allows to have a better view of the room since it is moving to the center. If the exit is detected, PICO can continue to move towards the exit. In the example in Figure 6, this happens quite rapidly. In case the exit would not be detectable, PICO sets a temporary target in front of him, to keep moving through the room. Detection of an exit which is parallel to one of the walls is an unique case which has been tested extensively. However, the detection algorithm had no problems to detect these special kind of exits.

Test 2: Small Exit

Another case, illustrated in Figure 7, can be challenging due to the narrow exit of around 0.5 meters. Here PICO’s positioning is made accurate enough to fit through without colliding. To gain more accuracy, PICO is driving slower which is caused by a larger amplitude of the rejective field in the narrow corridor, making the overall velocity vector smaller.

Test 3: Realistic Environment

As visible in Figure 8, the walls of the room consist of separated blocks. The detection of the exit is made robust to these kind of gaps, by using a minimal threshold for the size of the exit. As shown, PICO does not mistake these gaps for an exit.

Figure 6: Large Escape Room with an exit parallel to a wall.

Figure 7: Escape Room with a small exit.

Figure 8: Escape Room with realistic wall containing gaps.

Results

Figure 9 shows the final result of the Escape Room Challenge. During this challenge, PICO managed to escape the room within 15 seconds, as the fastest of all groups. In the beginning, it is visible that PICO starts with rotating counterclockwise. This happens because PICO did not see the exit immediately and therefore starts scanning its surrounding. When the exit is found, a target is placed, indicated by the yellow circle. Next, PICO starts to move towards the exit, represented by the green arrow. It can be seen that the target does not stay located at the exit, but rotates with PICO. This is because the target is updated at a lower frequency and therefore PICO remembers a fixed target relative to himself for a short period of time. When driving, PICO is pushed away from the walls by the rejective field, represented by the red arrow. The resulting velocity of PICO is represented by the orange arrow. When entering the exit, the target is relocated at the end of the corridor.

Figure 9: Final result Escape Room Challenge.

Hospital Challenge

In this section, the strategy for the Hospital Challenge is discussed, as well as the algorithms that are used. The discussion is structured based on the software components as shown in Figure 5: finite state machine, localization, mapping, path planning, motion control and detection.

Finite State Machine

'discuss the (slightly adjusted) FSM and the strategy it captures in the context of the hospital challenge'

Localization

Clearly, autonomous behaviour of PICO in the context of the Hospital Challenge requires the implementation of a localization algorithm. Recall that, in the Escape Room Challenge, only the relative position of PICO with respect to the exit was required to autonomously drive out of the room. In the Hospital Challenge, however, (an estimate of) PICO's global pose is needed, i.e. its pose with respect to some global coordinate frame, because it needs to know where it is with respect to the provided map of the hospital environment, in order to autonomously visit the next cabinet in a sensible way.

Since a certain starting area is specified on the provided map, the localization problem can be classified as a tracking problem. A certain initialization procedure is, however, required to infer an estimate of the initial pose using the knowledge of the starting area. To solve the tracking problem, typically, extended Kalman filters (EKFs) or particle filters (i.e. Monte Carlo localization) are used. The key difference is that EKFs represent the belief of the robot's pose, or the state, by a single multivariate Gaussian, whereas particle filters represent a multimodal belief by finitely many samples, i.e. weighted particles. As a consequence, EKF algorithms are computationally significantly more efficient. This forms the main motivation to use an EKF algorithm for the localization software component. Moreover, the EKF is relatively simple and tuning is quite intuitive.

An odomotry-based motion model is used, because it is generally more accurate than velocity-based ones as it does not suffer from the mismatch between velocity references sent to the robot's base and the actual velocities (if drift and slippage are ignored for the sake of the argument). Other than that, odometry is directly available. Moreover, a feature-based measurement model is used. Such models are computionally cheap compared to beam-based models, because, by extracting features from the raw LRF data, the measurements are projected into a low-dimensional feature space. An additional benefit, as mentioned before, is that quite some software of the exit detection algorithm from the Escape Room Challenge can be reused for the feature extraction algorithm. Furthermore, a maximum likelihood estimator is used for the data association problem. With other words, for each observed feature, the landmark that corresponds best is used for updating the belief.

The feature extraction algorithm will be discussed first, followed by the EKF algorithm and its motion and measurement models, and, finally, the initialization procedure is covered.

Feature extraction

- only mention changes w.r.t. exit detection algorithm of Escape Room Challenge

In Figure ..., the result of the feature extraction algorithm is shown. As mentioned, the feature extraction algorithm is able to distinguish between concave and convex corners. This difference is shown in the figure as well, where solid circles are used with different colors, cyan is used for concave corners and magneta for convex corners. Note that if a corner is not yet classified as either convex or concave, it is shown as an open red circle. The walls are shown in blue and PICO itself is represented by the red, rectangle.

Figure ...: Results of the feature extraction algorithm.

- Figure out how to make smaller GIF and position it !

Extended Kalman filter

As mentioned, an EKF algorithm is used for localization. The algorithm is given by

As inputs, the EKF algorithm requires an estimate of PICO's pose at time t-1 given by the mean μ_t-1 and the covariance Σ_t-1. Moreover, the odometry readings at times t-1 and t, x̅_t-1 and x̅_t, the observed features at time t, z_t, and the map m, containing the X- and Y-coordinates and the signature of all the landmarks, are needed. The EKF algorithm gives an estimate of PICO's pose at time t as output, again given by a mean and covariance μ_t and Σ_t, respectively.

In the EKF algorithm, lines 2-4 represent the motion update and lines 5-18 the measurement update as implemented in the motion and measurement model. Both will explained in more detail. Actual implementation of the EKF algorithm slightly deviates from the EKF algorithm presented above, but this will be explained later.

Motion model

In the motion model, a prediction of PICO's pose at time t is determined based on the available odometry data at times t-1 and t. PICO's movement is divided into three separate motions: a rotation δ_rot1, a translation δ_trans and another rotation δ_rot2. The three motions are determined using the odometry readings at times t-1 and t, and are calculated by

In line 2, the mean of the prediction of PICO's pose at time t is determined by adding a vector g_t to the mean of PICO's pose estimate of time t-1. This vector g_t contains the three, previously determined motions. Next, in line 3, the Jacobian G_t of vector g_t is determined, which is needed in line 4, where the covariance of the prediction of PICO's pose at time t is calculated. Note that a covariance matrix R_t is added, which models the uncertainty of PICO's movement. It is assumed that the uncertainty in PICO's movement is constant over time, thus R_t = R.

Measurement model

Next, the prediction of PICO's pose is corrected by means of the measurement model. First, in line 5, a covariance matrix Q_t, which models the uncertainty in the obtained LRF data, is introduced. Again, it is assumed that this uncertainty is constant over time, thus Q_t = Q. Next, in lines 6-12, a loop over all landmarks is given. In line 7, a vector δ_k is introduced in which the differences in x and y of a specific landmark and the prediction of PICO's pose are stored. In line 8, the transpose of this vector is multiplied by the vector and stored in q_k, which represents the squared distance between PICO and a particular landmark. All vectors corresponding to a pose of PICO (μ_t-1, μ_t, x̅_t-1 and x̅_t) are given in the form (x, y, θ)^T, while the vectors z, which correspond to features, are given in the form (r, φ, s)^T. Therefore, in line 9, the distance between the prediction of PICO's pose and a particular landmark is used to produce a vector in the same form of that of the features. Next, the Jacobian of this vector is determined in line 10. In line 11, The Jacobian is used in combination with the covariance of the prediction of PICO's pose in order to produce Ψ_k. Note that the covariance matrix Q of line 5 is added.

In line 13-16, a loop over all observed features at time t is shown. The purpose of this loop is to determine which landmarks correspond to the features that are observed. First, in line 13, the argument corresponding to the minimum of a cost function is determined. In this cost function, the difference between an observed feature and the vector of line 9 is used. The transpose of this difference is multiplied by the inverse of the result of line 11. Its result is again multiplied by the previously determined difference. The argument of the minimum is stored in a vector j and actually represents which landmark corresponds best to the observed feature. Next, the Kalman gain K_tⁱ is determined.

Finally, in lines 17 and 18, the estimate of PICO's pose, represented by mean μ_t, and covariance Σ_t are determined using the Kalman gain and the previous pose estimates.

Implementation

Figure ...: Only features observed in the room where PICO is currently positioned in are used for localization.

The implementation of the EKF algorithm roughly follows the algorithm as presented above. However, there are some differences which will be elaborated. First, it is chosen to store the covariance of the estimate of PICO's pose, Σ_t, as a private matrix in the header file of localization, rather than making it public and to use it as input of the algorithm when called upon. Even though its impact is minimal, it reduces computational complexity of the software. Next, for the same reason, in the loop of lines 6-12, not all landmarks are used, but only those of the room or part of the hallway that PICO is located in. This can be seen in Figure ..., where in the left window the features are shown that are used for localization and in the right all features that are observed. As seen, the feature extraction algorithm already recognizes two features in the room that PICO is about to enter, however, they are not used yet. The hospital environment is divided into nine different segments of which seven are rooms and two are a half of the hallway.

Figure ...: Situation where no features are observed.

Moreover, not all observed features are used when computing PICO's next pose estimate, but only those up to a certain threshold. Both these adaptions provide robustness since it reduces the chance that wrong data associations are made, which can have serious consequences. It might occur that none of the observed features fall within the threshold, or that no features are observed at all. The latter is shown in Figure ..., where PICO is driving through a hallway. Then the motion update as determined in lines 2-4 is used for the estimate of PICO's pose. Finally, since transpose and inverse matrices are widely used throughout the algorithm as well as many matrix products, separate functions have been created which are used from within the EKF algorithm. This way, the algorithm remains organized. The essence of localization is shown in Figure ..., where clearly the effect of drift is observed. In red, PICO is shown which makes use of the EKF algorithm. In blue, PICO's pose is shown in case simply the odometry data is used.

Figure ...: The effect of drift during movement. In red, localization using EKF and in blue, localization using direct odometry readings.

- Figure out how to make smaller GIF!

- Add that PICO's orientation stays within -pi and pi?

- Code snippet

Mapping

'discuss why mapping is preferred: i) if obstacle blocks path, PICO might try to squeeze through a too small opening, and ii) if obstacle is not saved, path planning will plan paths through it again next time'

'discuss specific choice of mapping algorithm'

Path planning

In the Escape Room challenge a feature detection algorithm was used to find the exit of the Escape Room. This data was then used as input for the attractive field of the Potential field algorithm, resulting in Pico having a goal relative to Pico’s local coordinate frame (the exit corridor) to drive towards. This approach worked very well for the Escape Room Challenge, but since the Hospital Competition is much more complex a dedicated path planner is required to guide Pico through the map and towards the cabinets.

Considered optimal path planning algorithms

Several options for path planning algorithms have been considered for this cause. Dijkstra's Algorithm, Rapidly Exploring Random Tree (RRT), RRT* and graph and grid based A* algorithms have been examined and evaluated for several important properties. Based on the fast computation time w.r.t. other grid based path planning algorithms, and relative ease of implementing it was chosen to work with a grid based A* algorithm. The main argument of choosing the A* algorithm is that a grid can easily be updated with obstacles dynamically, such that paths can be planned around detected obstacles. In comparison with for example weighted graph A* planning it is required to choose nodes which can not be altered dynamically easily. An overview and rating of the algorithms that were examined can be seen in Table X down below:

Table X: Considered path planning algorithms with scores for relevant properties.

A* Algorithm

The A* algorithm works as follows: In a global coordinate frame a path needs to be planned from a continues starting point in [m] to a continuous target in [m]. This global map is transformed into a grid as explained in the Section Mapping. In this grid of size N x M a path has to be planned from a start point (i,j) index towards a goal point. From the start point, all adjacent grid points that are not obstacles are evaluated, For each adjacent grid node n the cost g(n) is calculated, which represents the Euclidean distance from the start node to node n, and the cost h(n), which represents the Euclidean distance from the target node to node n. The algorithm then goes to the node which has the lowest cost f(n) = g(n) + h(n) and evaluates all adjacent nodes in a similar fashion. All visited nodes are iteratively stored in a CLOSED list, such that nodes can only be visited once by the algorithm. Furthermore all evaluated adjacent nodes are stored in the OPEN list, such that cost functions of adjacent nodes only have to be computed once. and then starts evaluating all adjacent nodes that have not been evaluated before. Prior to the iterative search of finding nodes with minimum cost functions until the target node is found, obstacles are placed on the CLOSED list, such that these can not be visited by the algorithm. Obstacles like walls have a very high value for g(n) and h(n), and are therefore automatically avoided by the lowest cost determination. In case no unevaluated adjacent nodes of the currently evaluated node are present, and if the available adjacent nodes are obstacles, the node with the minimum cost function f(n) from the open list is taken. dead end is reached by the algorithm, it automatically goes back to the last grid point with the lowest combined cost that is not evaluated yet. This process is then repeated until a path of grid nodes is found from start to goal. Using this approach, it is of course also possible that no path can be found, for example when the starting point is enclosed by obstacles. In the latter case the algorithm provides an exitflag which indicates that no path could be found.

Figure X: Path planned with the normal map (left) and with the weighted map (right).

Weighted Map

If the A* algorithm would be implemented like this, it is likely that a path would be planned directly next to walls and/or other obstacles, as it treats a minimal traveled distance as being optimal. In order to avoid paths to be planned close to corners, close to walls in a hallway or tightly past edges of door openings a weighted map is made and added to the cost function, such that the evaluated cost function becomes f(n) = g(n) + h(n) + w(n). The weighted map is constructed on the last known grid map from MAPPING, before the A* algorithm is called. It is constructed by evaluating each node (i,j) in the map. First adjacent nodes are evaluated and checked whether they contain an obstacle. If they do not contain an obstacle, the evaluation radius of node (i,j) is increased such that all next adjacent nodes are evaluated. This is repeated until an obstacle in the evaluated circumference is present, or the evaluation radius exceeds a threshold, which represents the maximum distance from an obstacle from which the weighted map affects the planned path. If one or more obstacles in the circumference are detected, the Euclidean distance w.r.t. node (i,j) is computed. Then node (i,j) is assigned the minimum of these Euclidean distances multiplied with a weight factor W, such that node (i,j) in the weighted map contains a weight based on the Euclidean distance to the nearest obstacle w(n). Thus now when a node is evaluated by the A* algorithm and the cost function f(n) is calculated, the corresponding cost w(n) is extracted from the weighted map. Figure (X) on the right shows the difference between a path that is planned with and without the weighted map.

Figure X: Path planned with the weighted map (left) and with the blocked map (right).

Blocking Map

As the gridsize of the map is parameterized, it can be chosen to have a smaller length than the maximum width of Pico. Therefore for the A* algorithm it would be possible for Pico to plan paths through which it does not physically fit. An example of such a case is when a dynamic obstacle is standing in a door opening. It then partially blocks the door, but if the gridsize is sufficiently small, grids in-between the dynamic obstacle and the edge of the door are interpreted as free space by the mapping algorithm. Therefore in this a path could be planned through this small opening through which Pico does not fit. The weighting algorithm takes care of this problem in regular cases, as this ads a sense of optimality of rather taking a detour than driving close through a wall, which is the case for such small openings. However when this detour becomes very long, taking this detour is no longer optimal. Increasing the threshold of seeing lager detours still as being optimal w.r.t. planning through small gaps can be achieved by increasing the MAXIMUM WEIGHT of the weight map. Increasing this weight however negatively affects the planned paths in regular cases as the weighted map is constructed using the Euclidean distance of each node w.r.t. the closest wall. This would then thus result in the path planner planning through the minimum of the weighted map, which is not always desirable. Therefore, the solution to this problem is to also interpret nodes which are less or equal than 0.5 times the width of Pico away from obstacles, as being obstacles, and hence adding these nodes to the CLOSED list. Therefore, a path can never be planned through gaps or near walls through which Pico does not physically fit, or at which Pico cannot be physically present without having a collision. Figure (X) on the right shows how this approach leads to the desired path.

Reducing computational time using compression

Figure X: Fine (left) and coarse path (right) from a certain starting location to the target.

At this point, the computation time of the path is relatively long compared to the time it takes Pico to follow it. An easy way to increase the computational speed would be to just increase the grid size, but this has the large downside of losing detail. This detail is not required in a lot of cases, but in some cases, in tight spaces, this detail is required to be able to compute a detailed map around obstacles. Therefore it would be desirable to be able to switch between coarse path planning with low computational times, and fine/detailed path planning in cases where coarse path planning does not suffice. Therefore path planning with a variable grid size was implemented based on [X]. This way of planning allows for grid sizes of distant nodes to be larger and nodes closer to the current position to be smaller. This way a fine path is planned and the computational time is reduced. The downside however is that each time the end of the fine path is reached a new path must be computed. Therefore the total time it takes to compute a fine path is spread out over the distance being traveled. After implementation and tuning this did not result in satisfactory behavior. The essence of using a coarse grid and fine grid for path planning however was maintained. mapping capabilities as this can lead to walls or other objects being portrayed bigger than they actually are. Several improvements have been tried out, where some were more successful than others. The most significant improvement is mentioned consecutively.

In order to be able to dynamically switch between coarse and fine path planning using a provided gridmap from MAPPING, it is necessary to be able to compress the map. The compression function uses the map and a compression factor N as an input. When using a compression factor of 2, (2x2) grids are compressed into a single grid, hence reducing the dimension of the map, but also removing detail. The map is compressed by looping over blocks consisting of size NxN, where N is the compression factor. If there is an obstacle in any of the elements of block N x N the compressed element is assigned a 1 indicating an obstacle, and otherwise is assigned a 0. As the map spans a 2D space, the number of potentially evaluated nodes by the path planning algorithm reduces quadratically as a function of the compression factor N. The compressed map is then used as input for the path planning algorithm. After a path is computed the path is decompressed such that the path is defined in the mapping grid. Figure (X) on the right shows the uncompressed (left, fine) path and the decompressed (right, coarse) path for a given starting point and target. Of course compressing the map has downsides. For example if the compression factor is too high, to much detail is lost and door openings are no longer detectable in the map. It can thus happen that due to compression, no path can be planned from the starting point to a certain target. In this case the corresponding exitflag by the A* algorithm is activated, and the compression factor can be reduced.

[x] Variable Sized Grid Cells for Rapid Replanning in Dynamic Environments – Rachel Kirby, Reid Simmons, and Jodi Forlizzi – October 11-15-2009, St. Louis USA – IEEE/RSJ International Conference on Intelligent Robots and Systems.

Potential Improvements

a) Replanning detection One of the ways to detect if a path needs to be computed is if a previously unmapped obstacle is now in the way of the planned path. The way that this is detected is by simply checking if no obstacles are present on the nodes of the path in the gridmap provided by MAPPING. Of course a coarse path is computed using compression and decompressing the computed optimal path, it is possible that no obstacles are present in the provided map on the nodes of the path, but an obstacle is actually inbetween the nodes of the planned path. For example a door could be initially assumed to be open, but as soon as Pico sees it, the obstacle is updated on the map. When this obstacle only consists of a single node and this node does not match a coarse path node, then the path being blocked is not detected. In order to enable this detection, the nodes inbetween the coarse path nodes must also be checked. Such an algorithm has not been implemented for this course, but is certainly a good improvement as then, similarly as is implemented for a fine path, Pico can replan the path as soon as it detects an obstacle being in the way of the path.

Motion control

The path planner now provides various options to compute an optimal path, due to the compression function. From this function a path in (X,Y) coordinates in meters is obtained. Simultaneously from the localization algorithm Pico’s (X,Y) position within the global coordinate frame is known. In order to follow the path, Pico’s (x,y) position in the global frame and a goal on the path w.r.t. this global frame are used to compute a relative goal w.r.t. Pico’s local coordinate frame. This relative goal is provided to the attractive field as also used during the room challenge. The resulting effect of this approach is a control loop which actuates Pico to a goal on the path with a simple gain. This gain can be increased by choosing a steeper attractive field towards the relative goal.

FigureX: Combination of attractive and repulsive field vector as function of minimum distance to an obstacle.

In order to enable the possibility that a coarse path can be followed continuously, without hitting details of objects in the world which are not taken into account in coarse path planning due to compression, a rejective field is added. The rejective field takes into account all the LRF data within a radius of Pico, which is set to be 1.5 [m]. Any laser-beam within this range contributes to a repulsive vector. Both the repulsive and attractive field vector are normalized, and combined into a single vector which is used to control the direction of motion. The orientation of Pico is similarly as during the room challenge, aligned with the attractive field vector, such that Pico is always facing its target. The normalized vectors of the attractive and repulsive field are combined using the corresponding weight factors F as indicated in Figure (X) representing the attractive field in blue and the repulsive field in orange. The factor for the repulsive field is dependent on the minimum distance of a visible object w.r.t. Pico Dmin. The effect of the repulsive field vector w.r.t. the attractive field vector is increased when Pico is closer to an obstacle. The dotted black line on the left is the threshold at which Pico executes an emergency stop.

Another tuneable parameter is the goal on the path which is provided. The distance of the target on the path w.r.t. Pico’s position can be tuned. For coarse path planning this distance is relatively large, as this provides more flexibility for the potential field algorithm. For example tight corners of the path can be cut off safely, due to the incorporation of the rejective field. This enables in a relatively coarse computed path, to still result in a smooth optimal trajectory of Pico’s motion. This distance of the target on the path can be interpreted as being a rope. The target on the path can be interpreted as being a rail, dragging Pico along the path using the rope. Increasing the length of this rope allows more flexibility in movement w.r.t. the computed path, but requires more effort by the rejective field algorithm to avoid obstacles. Decreasing the length of the rope enforces that the computed optimal path is followed more closely and thus reduces the effort of the rejective field. This way, by adjusting this length, it is possibly to dynamically make an adjustment between the potential field algorithm and the rejective field algorithm, where the potential field algorithm is fast, but less robust, and the A* path planning algorithm is robust, but is slower to compute.

Coarse path planning is always the initial option of path planning and actuation of motion, but when Pico has detected an object within a near collision radius, it is likely to be in a tight space, where the coarse path planning in combination with the long ‘rope’ is insufficient. In the latter case the compression is reduced such that a fine path is computed. Simultaneously the length of the ‘rope’ is reduced such that the computed path is followed more closely and the effort of the rejective field is reduced. This way it is possible to compute paths out of tight spaces where a potential field algorithm does not suffice. AN EXAMPLE OF PICI FOLLOWING A COARSE AND A FINE PATH CAN BE SEEN IN …. SIMULATION WITH FINAL PATH

Recovery state

For situations in which it is impossible for Pico to follow the fine path as well, another solution has to be come up with. The situations in which a fine path is calculated but cannot be followed is when static obstacles block the path, when a dynamic obstacle has occurred on the path and it is not moving until Pico moves away from it or when the goal is actually unreachable due to obstacles and/or closed doors. For the first two situations, a recovery state is introduced. The recovery state is triggered whenever Pico has had to make an emergency stop, meaning that an unexpected obstacle has appeared on the path and Pico cannot continue its current movement. In the recovery state, Pico´s direct surrounding is mapped more accurately than in the planning state, increasing the likelihood of the path planning algorithm to find a path that leads Pico away from this situation. In the Recovery state, the same approach of first looking for a coarse path and only then a fine path is used. For the situation that a dynamic obstacle blocks both Pico and the dynamic obstacle from moving, a counter is used such that the amount of path planning attempts remains limited. If a threshold value is reached, Pico will stop planning, and will instead follow its repulsive field gradient for 1.5s to move away from the dynamic obstacle, therefore resolving the situation.

Deliverables

Design Document

In the design document, a generic approach for the Escape Room Competition and the Hospital Competition is introduced. Requirements are proposed, which are clarified by means of specifications. Based on these, a finite state machine is designed. In each state, groups of functions are proposed. This functionality is, in turn, structured in an information architecture which covers the components and the interfaces. Undoubtedly, throughout the remainder of the course, this document needs to be updated, but its current content functions more as a guideline. Since the Escape Room Competition is the first challenge, functional specifics may be more focused towards this goal. And because software design is use-case dependent, for the Hospital competition the current approach will need to be adapted and improved. The design document deliverable can be found here.

References

[1] https://en.wikipedia.org/wiki/Distance_from_a_point_to_a_line

[2] https://nl.mathworks.com/help/curvefit/least-squares-fitting.html