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

In this section, a brief summary of the meetings is given.

Date	Content
29-04-2020	This was an introductory meeting during which the group met with the tutor, Wouter Houtman. We briefly discussed with him what he expected of us and how we were planning to make progression. Also, we discussed the contents of the design document. We had a general discussion about the expectations of the course and the two challenges. As a group, we agreed to have at least two meetings per week, one with our tutor to discuss progression and to ask questions and one without him. We agreed that every group member should watch the lectures and make the tutorials. If one does not do so, he will fall behind and will not be able to help the group progress. Moreover, since none of the group members has experience with C++, every group member is advised to practice in the programming language. For next meeting, every group member should, apart from watching the lectures and finishing the tutorials, get some inspiration for the design document. Sources of inspiration are the wiki pages of groups of previous years and the general wiki page with the description of the challenges.
01-05-2020	In order to remember what is agreed upon during the meeting, we assigned someone to take minutes. Next time, he will lead the meeting to improve the structure and someone else will be taking the minutes. A role division scheme will be made. During this meeting, we discussed the five items that should be included in the design document. First, we agreed that we should first focus on the requirements and specification. By further specifying the requirements and specifications, functions will follow. Once the functions are known, they can be divided among the components of PICO. The components will on its turn be included in the software architecture with the corresponding interfaces. We decided to roughly follow the scheme of lecture 2.1 for the requirements and specification. Next, we divided the tasks. Two people will work on the requirements and specifications, two on the functions and two on the interfaces and components. Since the deadline for the design document is 04-05-2020, we set a deadline on 03-05-2020 for a first draft of the different tasks. This gives us sufficient time to process feedback from others and finalize the design document.
03-05-2020	This meeting was planned as a follow up on the tasks assigned in the previous meeting. First, some general agreements were made. It was decided to create an OneDrive folder so that it would become easier to share and store documents. Also, the minute taker was made responsible to update this meeting log on our Wiki page. Afterwards, each subgroup shortly explained their work. After this brief explanation, some possible improvements were discussed and noted in the minutes, so that they can be implemented. The main points of improvement were focused on small adjustments for each part to be coherent with the other parts. At last, we looked at how to continue towards the next meeting planned on Thursday. The first priority would be to finish the Design Document. It was decided to finish it today so that it can be checked and delivered on Monday before 5 pm. After that deadline, all members would further investigate Tutorial 12, since this would help to create an understanding of a simple software implementation. Besides that, the same subgroups were appointed to work out some of the capabilities as formed in the Design Document. The expected outcome of this task would be a general approach (or possible libraries/algorithms to use) and possibly a piece of code.
07-05-2020	This meeting was used to receive feedback from our tutor on the design document, and to discuss our approach for the escape room challenge. One of the feedback points that was received was that the design document could have been more explicit. We got the recommendation to update the design document still, since this will make the programming part easier. After this we discussed the algorithms we are working on, and what the advantages and disadvantages of each algorithm are. In the end, we divided the work for next meeting (08-05) in three sub assignments. The first duo would work on the project structure and corner detection, while another duo would work on the potential field algorithm. The last duo is going to investigate and program the corridor exit procedure. The goal for the next meeting is that the structure is finished and that the individual parts can be implemented into one system, since integral testing will probably uncover quite a few problems between the components.
08-05-2020	During this meeting the progress of the implementation of the potential field algorithm, an algorithm able to identify the target at the exit of the room, and the investigated approaches of driving straight through the exit corridor are discussed. The rejective field gradient has been implemented successfully and movement in (x,y,theta) can be initiated according to this gradient vector. Potential field is likely to be able to drive through a corridor if the execution rate is sufficiently high. A split & merge approach for detecting wall features is investigated mathematically using Matlab. Recursive fitting is used to fit lines to measurement points from the laser range finder corresponding to a single feature. Finally the strategy for the room challenge and hospital challenge has been further elaborated and the structure corresponding to the approach for the room challenge has been implemented. Goal for next meeting is to compare the split & merge approach with the corner detection algorithm, to see which one is more efficient. Furthermore the potential field algorithm will be further implemented to include the attractive field. Finally the implementation in C++ for the room challenge will be continued and possibility of visualizing gradient vectors and identified corners will be investigated.
11-05-2020	In this meeting, we met with our new tutor, Jordy Senden. We got some more feedback on our design document: i) the graph of stakeholders and different types of requirements is good, but the connections can be worked out further and some requirements are still missing a specified value (e.g. min. speed), and ii) it is questionable whether the planning state of the finite state machine is needed (or is planning going to happen in another state simultaneously with other tasks). Moreover, we asked the tutor some questions regarding visualization, our strategy for the escape room challenge and programming in c++. After that, we shortly introduced our current software to the tutor: part 1 that (mainly) applies the potential field algorithm and part 2 that (mainly) applies (a sort of) split and merge segmentation. Finally, we further discussed what we were going to work on up until the escape room challenge which is in two days. Regarding part 1 (potential field algorithm), we decided to start using odometry data as a means of updating the target location (i.e. the corridor) for cases where part 2 fails to produce a new target location. A lot of debugging still needs to be done to get part 2 working as expected, therefore we decided to compare MATLAB and c++ results to see where it goes wrong. Moreover, part 2 will be tested more thoroughly in MATLAB, i.e. using more data obtained from the PICO simulator, and we plan on adding a more thorough preprocessing on the LRF data at the beginning of the part 2 software to increase robustness.
12-05-2020	During this meeting, we discussed our results in order to define the last tasks for the Escape Room Challenge. Our potential field algorithm ensures that PICO keeps track of the odometry data in order to identify it's current position relative to the target. The split and merge algorithm is now able to locate the target at the exit of the room and at the end of the corridor. However, this algorithm has some robustness issues which need to be fixed. Next to this, the visualization of PICO's perception of the surrounding is implemented. Now, both algorithms need to be combined into a single working program, which then can be tested and finally used for the Escape Room Challenge.

PICO Project

Introduction

Figure 1: PICO

Figure 2: Escape Room Map

Figure 3: Hospital Map

Nowadays the demand of good health care is rapidly growing, requiring a more efficient solution. A autonomous embedded robot could assist in the everyday tasks in a hospital environment, allowing the doctors and nurses to save their valuable time for the right tasks. During this course the software for such a mobile robot, named PICO, is developed. The goal is complete two different simulated challenges, the “Escape Room Challenge” and the “Hospital Challenge”. While completing these challenges PICO should be robust to environmental changes which are common in a hospital environment.

Pico

Pico is a mobile robot equipped with sensors and actuators. The used sensors of PICO are a Laser Range Finder (LRF) to scan its surrounding and odometer wheel encoders to keep track of its movements. In order to actuate, PICO has a holonomic base with omni wheels which allows 2D translation and rotation.

Escape Room Challenge

The goal of this challenge is to escape a room with unknown dimensions as fast as possible. PICO has a unknown initial position within this room and has to detect the exit with the LRF data. When this target this set, PICO has to move to this exit and leave the room all the way through the corridor. In the following section the approach of the Escape Room Challenge is explained. The algorithms used and the implementation are explained. Finally the results of the challenge are discussed.

Design

Requirements and Specifications

A distinction is made between general and competition specific requirements. Three stakeholders are considered: the hospital employees, patients and 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 1 and elaborated below. Note the legend located bottom right.Figure 1: The general requirements (left), the competition specific requirements and legend (right).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.

Finite State Machine

The following finite state machine depicts the designed behavior of PICO:Figure x: State space description of FSM.

• 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.

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.