Mobile Robot Control 2020 Group 8

Welcome to the page of group 8 of the course Mobile Robot Control!

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. } 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. Escape Room Competition Hospital Competition