In order to support and facilitate the collaborative group effort, each group will have access to a version controlled repository (git). If you are not familiar with git, see
git-tutorial, (git-cheat-sheet) and this hands-on exercise to get started.
The group repos are available at
https://gitlab.control.lth.se/regler/FRTN40/2018/group-A
https://gitlab.control.lth.se/regler/FRTN40/2018/group-B
...
To clone your repo, type (in the terminal):
git clone git@gitlab.control.lth.se:regler/FRTN40/2018/group-A
etc.
Before you can clone your repo, you need to create an account at gitlab.control.lth.se. Use your real name, first_last, and your LUCAT e-mail address when doing so. Once everyone in your group has an account, e-mail your project advisor with your login names. She/he will then create your repo. It will be read/writable only by your group's members and course staff. When creating your repo, your project advisor will populate it with a copy of the repo
git@gitlab.control.lth.se:regler/FRTN40/template
containing the required directory structure for the course, and template files for the final report.
The material you produce for reviews, as well as the written reviews you provide shall be pushed to the repo
git@gitlab.control.lth.se:regler/FRTN40/2018/reports
To simplify thing for both you, your project advisor, and fellow students, we will all be using the same standard folder structure for all projects - the one that came with your git repo. You are welcome to add sub-folders as you please.
doc - Documentation. A fellow student with access to the repository should be able to reproduce all your project results based on the information here. (The above subfolders are meant to contain the project plan and reports for feedback seminar 2 and the final report, respectively.
report - Presentations for the seminars, the corresponding documentation, and the final report. Note: even if you work with an online LaTeX environment, such as Overleaf, you are required to push LaTeX source from which your final report document can be built.
schematics - Wiring diagrams, drawings, etc.
model - Models and simulations on which you base your design, also scripts and investigations for the control design.
src - all source code for the project. Consider the use of subfolders if you use multiple programmings languages in your project. The code should be tidy, readable, and rigurously documented.
test - tests for the source code. If your source code only consists of a single arduino program it might not be meaningful to do unit testing, but if you have a more complex project we strongly encourage you to have unit and integration testing of your code.
Make sure that it is very easy to understand how to both compile and get the source code to run on your platform, including complete setup and build instructions of dependencies, such as openCV. These instructions are preferably written in the README file in the root folder of the project, using markdown. Include a picture and a short description of your finished project in this file as well).
It is not possible to commit empty folders to git. If you still want to commit an empty folder, a quite common technique to add files called .gitkeep in the empty folders.
Try to keep your git-repository clean. As a rule-of-thumb, do not check in files that can be generated from the code in the repository, e.g., compiled binaries. In principle, neither pdf-files which are generated from the TeX-code should be checked in. However, do check in final versions of your reports, presentations and all other documentation - these are the same documents that go into the shared git repo.
To help you to avoid checking in files that are not needed, the .gitignore contains rules for which files that will not be added to git by default. If you explicitly add a specific file, it will be added regardless of the rules in the .gitignore file.A .gitignore file that works OK for LaTeX and Matlab files is already in place in your repos.
Each project group is required to hand in a project plan to their respective project advisor. The plan should contain:
Some useful hints for the project planning and execution
The plan should be detailed enough to track weekly progress. If you need to order some equipment for your project, first confirm it with your project advisor, and it is important to schedule time for component ordering and delivery in your plan. An example project plan is available in your git repo.
Link to an online spread sheet will be circulated via the course mail list. Make sure to fill in all component you need for your project by Fri Nov 9 (see important dates).
All component orders go through your group's project advisor. Talk to her/him if you have any questions regarding ordering things for your project.
We will use the built in issue/milestone tracking system of gitlab. Whenever you identify a problem or task within your project, you open an issue (after logging in at gitlab.control.lth.se). Then you assign this issue to yourself or other group member(s), and to a milestone. While the issue is open, you can add comments to it, and once you are done with resolving the issue, you can mark it "resolved", but it is good practice not to delete resolved issues (unless they were not errounously created). A milestone is a goal consisting of a collection of issues associated with a date. You can create as many milestones as you like. A good idea is to tie them to important course events, for example:
Organizing issues into milestones provides a good way to gain overview of the project, both for group members and project advisors. It also prevents from issues being forgotten, to emerge again once you are close to some deadline.
Documentation of the issues and milestone trackers are found here (although it might be easier to just play around with it):