General information about the laborations

This course has a number of compulsory laborations that give you hands-on experience with key concepts from the course. These laborations are programming-based projects, but also include textual reasoning parts. The laborations do not have a grade, but you have to pass all of them.

You can discuss the lab problems with students outside your lab group. You can discuss strategies on a high level. But you are not allowed to give away any solutions! We take plagiarism seriously (there’s even a lab about that).

Schedule

Each lab has three deadlines, where the middle deadline is optional.

You must submit something for the first deadline, even if it is not fully working. You receive feedback on your submission soon after the deadline. If it is not accepted, you have time until the final deadline to correct your solution. But if you submit before the middle deadline, you will receive updated feedback so that you can finish your lab in time.

Joining a group

The laborations are done in groups of three. Find other students to team up with. We suggest you do this before the course starts:

Talk to friends, previous lab partners, students you know will be taking this course.
Ask for partners on Slack.

Once you have formed a group, assign yourselves to a free lab group in Canvas. (Go to the People page and then select the tab Lab groups).

Note: All group members need to actively contribute to and understand the whole submission.

Doing the labs

The lab projects are shared, submitted, and graded on Chalmers GitLab. This is a collaborative platform for software development similar to GitHub and Bitbucket, but hosted privately by Chalmers.

The full process is described below (“Working with GitLab”), but briefly:

You will be invited shortly after joining a lab group.
You submit by creating a tag with a special name (submission-X).
The graders give feedback in issues. Ask for clarifications and engage in discussions with your grader by commenting in the issue thread.
Robograder can test your code before you submit it. For this, create a tag with name test-Y.

For help with getting the labs running on your computer, see the appropriate page Running the labs.

Supervision

We offer supervision sessions where you can (and should!) get help from course assistants. They are held in hybrid format, both on campus and online, see the schedule when. During each session, we maintain a queue of supervision requests in the Slack channel #supervision.

To get a live supervision meeting, simply post your group number and where we can find you (for online requests, this should be a Zoom link). A course assistant will join you as soon as possible. The course assistants mark handled requests using emojis. From this, you can see how far in the queue you are.

Note: You can always use the Slack discussion channel(s) to get help for the labs. Outside the lab sessions, it may take longer to get an answer.

Supervision checkpoints

For all labs you need to pass a live supervision checkpoint. This is to demonstrate that all group members actively contribute to and understand the whole submission.

Ask for a supervision checkpoint like you would for an ordinary supervision meeting. This can also be online.
You should have submitted your first version of the lab. If you get stuck before, please reach out during the lab sessions.
All group members must be present in the meeting and able to answer individually. Expect questions about parts other group members have written.

Of course, you can ask for regular supervision as many times as you like, independent of the checkpoint.

Working with GitLab

Getting invited

Before you can do the lab assignments, you first have to be part of a lab group. See above (“Joining a group”) for information about this.

You will soon get an invitation to your student email address to a group on Chalmers GitLab with access to the lab projects. Normally, this happens within 10 minutes. If you do not receive an invitation and cannot see any group when logging in to Chalmers GitLab, contact the course responsible.

Note: If you received the invitation to your GU student email, you have to add that email to your profile on Chalmers GitLab before you can accept the invitation.

Important note: GitLab will send grading notifications for your submissions to whatever primary email address you have configured. By default, this is your Chalmers student address, but you can change it (for example, to your GU email address if you’re a GU student). Make use of this to stay up to date.

Note: If you already had a Chalmers GitLab account, it may happen that your account is added directly to the corresponding group on Chalmers GitLab; depending on your notification settings, you might then not be notified.

Accessing Chalmers GitLab

Opening Chalmers GitLab or the invitation link you have received brings you to to the front page. Sign in with your Chalmers Login (don’t use the username/email field):

After signing in, accept the invitation to your group using the invitation link. You should now have access to your group:

We create each lab assignment as a project here for you. It consists of a git repository with the lab problem. The file README.md contains the lab description (in Markdown format). It is automatically displayed by Chamlers GitLab when you open the project.

You can use the provided repository in any way you like. How you collaborate on the project is up to you:

together on one computer,
separately on different computers (using git to synchronize changes).

Using git to work on a lab

Git is the industry standard for version control and collaborative software development. It will pay off to become familiar with it!

Make sure that git is installed on your system and working.

Adding an SSH key to GitLab

In order for git to access GitLab Chalmers, you need to set up an SSH key and register it with GitLab. To do that, follow the instructions here. The important sections are “Generate an SSH key pair” and “Add an SSH key to your GitLab account” – you can skip all the other sections. If clicking on the link shows an error page, make sure to sign into GitLab first.

We recommend not using a passphrase for the key (the private part of the key is already a secret). That way, you can clone and push commits without being prompted for a passphrase. The details of these setups depend on your operating system (see the given links; there are countless more on the web, e.g. here and here).

Alternative: using a password

If you have trouble with setting up an SSH key, you can instead set up a password for your GitLab account here. After that, continue by following the instructions below. Note that this is less convenient than using an SSH key, as you will have to type in your password every time you pull from or push to the git repository.

Working on a lab project

To interact with the provided git repository, you have several options:

Clone the git repository via SSH. From the browser, select “Clone with SSH” in the “Clone” menu:

Each time you want to do some work,
1. pull the latest changes that other group members might have done,
2. add and commit your own changes, then
3. push to GitLab.
If you can’t remember the commands, there is a git cheatsheet.
If you use an IDE such as IntelliJ or Eclipse, it comes with built-in git integration. For example, in IntelliJ, simply create a project using File → New → Project from Version Control and paste the repository SSH URL you get from the project page on GitLab Chalmers by clicking on Clone.

Note: If IntelliJ highlights lots of strange errors after cloning, this may be because you need to specify the project SDK. Go to File → Project stucture… and specify a Project SDK version.

To simplify things, we suggest you only use the default branch (called main) and do not create extra branches. Then you won’t have to interact with the branching functionality of git. But, of course, you can use the provided git repository in any way you like!

For information on how to compile and run the labs, see the appropriate page for Running the labs.

Each lab comes with specific instructions on what changes to the code you should make and what questions you should answer (typically in a provided file called answers.txt). Please do not change the signatures or behaviour of pre-existing methods unless instruncted, as it will make your submission harder for us to test and grade. Of course, you are allowed to add things (such as new instance variables or private methods) that do not affect the existing functionality.

Note: You can ask Robograder to test your code after you did some work or before you submit. (See the page for Running the labs)

Submitting a lab

We use the tags feature of git to handle lab submission and the Issue feature of GitLab to handle grading and feedback.

When you are ready to submit your code, go to the project page on GitLab and create a tag:

The name of a submission tag must start with submission. If you want to be nice, add a number (0, 1, 2, …) to indicate your submission attempt. For example, for the first submission, use:

You can write a submission comment in the message field.

Once you have created a submission tag, it is immutable. It serves as your proof of submission. You can still continue to push new commits to the repository, but this won’t change the tagged version of your code (the commit the tag points to). Therefore, make sure to tag exactly the version you mean to hand in (be extra careful if you work with multiple branches). If you happen to put the tag in the wrong place, you can use a new tag. For example, if submission0 ended up on the wrong commit, put submission1 on the right one and we will ignore the previous tag.

Note: The tag must live in the Chalmers GitLab repository, not (only) in your local git clone of it. If you create the tag locally and then push, make sure to push tags.

You can check your submission by visiting Repository → Tags. The submission tag should be highlighted as protected:

Getting feedback

After you have submitted your lab and the submission deadline is over, we will grade your submission. Our grading will be entered using one or more issues in the issue tracker of your project.

You ask questions, engage in discussions with your grader, and even contest the grading by commenting in the issue thread. You will receive a response by the grader.
Feel free to close the issues once you have dealt with all the feedback given.

If you did not pass in the first grading and wish to resubmit, create a new submission tag (e.g. submission1).

Robograder

We contracted elite roboticists to build Robograder™. This isn’t just to help us grade your submission. You should test your code with Robograder to iron out bugs before you submit. To call Robograber, create a tag like you would for a submission. But use test tag, starting with test (for example testPlzKThx). Robograder will quickly respond with a GitLab issue (you should be notified by email).

You are allowed to use Robograder five times for each lab. This limitation is put into place to prevent test spamming and encourage you to think instead.