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 |
Introduction
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 | ... |
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 can be found *here.