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
To clone your repo, type (in the terminal):
git clone firstname.lastname@example.org:regler/FRTN40/2018/group-A
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
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
This repo can be read/written by everyone taking the course. Each group has a directory (A, B, ...) in the repo. Use the following file names
- plan-2018-X.pdf is the project plan of group X (where X is your group's capital letter
- feedback2-2018-X.pdf is your feedback seminar 2 report
- report-2018-X.pdf is your group's final report
- review-2018-X.pdf is your group's review of another groups' final report
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.
Each project group is required to hand in a project plan to their respective project advisor. The plan should contain:
- An overview of the project.
- Descriptions of the key parts of the project, including
- equipment and materials
- design (hardware, software, control principles)
- A decomposition of the project into subtasks and a suggested allocation of the project resources to key tasks.
- A time plan (using a Gannt chart provides good overview)
Some useful hints for the project planning and execution
- Break the project into manageable subtasks
- Establish dependencies between subtasks
- Estimate time required each subtask (man hours/days)
- For each week estimate how many hours every member of the team will work
- Plan deadlines for each subtask using the estimates above
- Put any spare time you might have at the end of the schedule, not the beginning!
- Follow up on your progress weekly, and schedule more time if you are falling behind.
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:
- Project plan
- Feedback seminar 1
- Feedback seminar 2
- Report submission
- Presentation and demonstration
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):