Mini Project

The objective of the mini project is to let the students work in a group on a self-selected project during the whole semester. We encourage groups of max two persons (but single-person groups are ok if need-be). We encourage that students within a group collaborate; however, in the source code, it must be explicitly declared who authored which code. You are allowed to collaborate between groups, but each group must make a separate project.

Table of Contents

1. Equipment
2. Prestudy Phase
3. What kind of project can we make?
4. Requirements of the project
5. Extended Abstract
6. Examination and Feedback on the Abstract
7. Development Environments
8. Resources and Advice
9. Project EXPO

1. Equipment

The project should be done on a ChipKIT Uno32 Links to an external site. or a ChipKIT uC32 Links to an external site. development board together with a ChipKIT Basic I/O  Links to an external site.shield (see manuals on the Literature and Resources page) or other electronics that are connected to the board. This development environment will be handed out to each student group (group of two students) at LAB 1. The students may borrow these boards during the whole semester. Hence, all development should be done at home or at KTH's computer rooms. The project must make use of this hardware, but it is absolutely allowed (and encouraged) to add more hardware and electronic equipment (these boards are compatible with some Arduino Links to an external site. shields). However, any additional hardware needs to be purchased by the students themselves. You do not need to buy any more hardware to make a project that can pass the course examination, but if you do, the project can be even cooler!

2. Prestudy Phase

We consider the time until the submission of the DRAFT extended abstract (see below) the "prestudy" phase, meaning that this is the time when you (in the group) can play around with the board and test different project ideas. However, during this time, you need to decide on what you want to do in the project. You may discuss different ideas at the lectures with the teaching assistants or during the lunch office hours. 

3. What kind of project can we make?

It is very flexible and it is up to you what you want to do. Here are a few examples: 

4. Requirements of the project

There are some basic requirements on all projects (both basic and advanced projects):

  • You must use the PIC32 platform supplied by the course. Note that if you choose to include other electronic components, it is OK to use these components directly with the Uno32 board and remove the Basic I/O shield. However, you do not have to buy extra electronics; it is enough to use the Basic I/O shield as long as you fulfill the next requirement.
  • The project should make use of some other device/component besides the LED lights, switches, and push buttons on the Basic I/O shield. This could for example be the built-in temperature sensor, the display on the I/O board, an external accelerometer, an external motor etc. 
  • The project should be non trivial and actually perform something. This means that there should typically be some interaction, use of I/O devices, and include some program logic. 
  • You may use the MCB32 tool chain or the MPLAB X IDE, but not the MPIDE (a ported Arduino IDE). The reason is that you should learn about low level programming in this project.

If you are aiming for the highest grades (grade A or grade B), you need to do an advanced project. That is, if you have done an advanced project and you score an A or a B on the exam, you get the final course grade A or B. If you get points corresponding to A or B on the exam, but you have done a basic project, you get a grade C on both the exam and the final grade. Hence, if you do a basic project (not an advanced) you cannot get a higher grade than C. Note also that the ability to use the advanced project to get a higher grade is only valid on the ordinary exam and the two following retake exams. 

To be able to counted as an advanced project, one of these requirements must be fulfilled. 

  1. [Graphics] You implement a program or a game using the basic I/O shield using the OLED graphical display, where you have graphics moving around on the whole screen, both in the X and Y directions. Your program must interact with the whole screen pixel-by-pixel and not just using the image and text example code from the labs (graphical objects are moving over pages/segments of the screen). This means that you need to have at least one object of the minimal size of 2x2 pixels (for instance a small image) that can move in both X and Y direction, one pixel in each frame update. The game/program should also be rather advanced, with several modes (1 and 2 players, high score list, etc.). Please see the project suggestions in 4.1 to get a better idea of what is required.
  2. [Protocol] You create some project with external electronic components that are communicating over SPI, I2C, or some other non-trivial data protocol. Your application has a non-trivial logic (that is, it is not enough to simply implement the protocol itself).
  3. [Sound] Your program has an advanced interaction with sound, for instance by sampling sound as input, manipulating the sound signal, and outputting the sound again.

Examples that do not qualify as advanced projects, but would be enough for a basic project.

  • Your program is only using the OLED graphical display by writing text and changing the image using the code that was supplied in the lab templates. Your program is using buttons and some other input device, for instance the temperature sensor. You are using interrupts and timers as part of the logic in your program.
  • Your program is using some external electronic device that has a simple interface, e.g., push buttons that only requires single GPIO ports.

An example that would not be acceptable as a basic project:

  • A very simple project with basically very little program logic where you are just reading the input from buttons, and writing output as texts using the code that was supplied in the lab. Note also that it is not OK to have a lot of code duplication of if-statements etc. in the project. In general, if you start to copy and duplicate your own code, then you are doing something that is not very good. Most likely, it is possible to rewrite your program using loops and/or data structures instead.

When you write your DRAFT abstract, it is important to clearly state if you aim for an advanced project or not. Please state this clearly in the beginning of the PDF-file that you submit. By doing so, we can give feedback if we believe that your proposal can be counted as an advanced project. Note also that it is not until the actual Expo we examine the project and decide if the project can be counted as advanced. If you have any questions, please do not hesitate to email us about your project ideas, or speak with the teacher during the lecture breaks.

4.1 Project Suggestions

Here, we provide a set of project suggestions to give you inspiration. All of these suggestions require only the hardware provided to you in the course. In other words, you do not have to buy any external hardware to complete them. If you have not worked with external hardware before, and are not prepared to invest a lot of extra time to finish the project, we recommend that you choose a project without external hardware of difficulty similar to the suggestions found here. Note that these projects are just that: suggestions. We encourage you to tweak the project requirements to your liking. Even if you choose a project suggestion directly as is, you still need to submit an extended abstract detailing all its requirements (see section 5).

In addition to Lab 3, a number of examples on how to use the various hardware on the ChipKIT can be found here Links to an external site..

4.1.1 Basic Projects

Pong (https://en.wikipedia.org/wiki/Pong Links to an external site.)
Requirements:
- Display game on built-in OLED graphical display.
- Ball moves in X and Y directions.
- Paddles move in Y direction.
- Ball bounces naturally on paddles and sides.
- Detect and display a player wins.

Snake (https://en.wikipedia.org/wiki/Snake_(video_game_genre) Links to an external site.)
Requirements:
- Display game on built-in OLED graphical display.
- Snake moves across the screen in X and Y directions.
- Snake chases apples, which, when eaten, increases the length of the snake.
- Snake can collide with itself and walls.
- Detect when snake collides, and display number of apples eaten (score).

Tetris (https://en.wikipedia.org/wiki/Tetris Links to an external site.)
Requirements:
- Display game on built-in OLED graphical display.
- Blocks of different shapes fall from the top of the screen to the bottom of the screen (and remains there).
- When a row is completed, it disappears, and blocks above shifts downwards to fill the space.
- Detect when the player loses (e.g., screen fills up completely with blocks) and print some kind of score (e.g., number of rows completed).

Flappy Bird (https://en.wikipedia.org/wiki/Flappy_Bird Links to an external site.)
Requirements:
- Display game on built-in OLED graphical display.
- Standard flappy bird rules are implemented. See, e.g., https://flappybird.io/ Links to an external site..

Temperature Sensor
Requirements:
- Display application on built-in OLED graphical display.
- Possible to switch between displaying Kelvin, Celsius, and Fahrenheit.
- Possible to record average, max, and min temperature over a time period. The user should be able to input this time period in seconds (supporting at least all time periods in the range 1-2000 seconds).
- There is a user-friendly menu for configuring the above requirements.

There is an example project showing how to read from the temperature sensors using I2C at https://github.com/is1200-example-projects/hello-temperature Links to an external site.. This is why this project cannot be counted as advanced.

4.1.2 Advanced Projects

Many project suggestions below have the following requirement:
- [Highscore] When a game ends, the player can enter their initials (at least three capital letters) in a high-score list. This high-score list can later be found through a menu system. Note: it is not required that the high-score list is stored in non-volatile memory (i.e., that it is preserved even when the ChipKIT is turned off). Such a memory is, however, available on the ChipKIT (EEPROM). Operating it requires I2C, and can therefore even fulfill the [Protocol] requirement if implemented correctly.

Pong (https://en.wikipedia.org/wiki/Pong Links to an external site.)
Requirements:
- [Graphics] (see above).
- There are both one and two-player modes, where the one-player plays against the computer (controlled by an AI). There are different difficulty levels for the AI.
- The bounce angle is determined both by where the ball hits the paddle, and the current trajectory of the ball. If the ball hits the middle of the paddle, its angle of reflection is not modified. Towards the sides of the paddle, the angle of reflection is increasingly modified (in that direction). The bounce angle must be continuous (e.g., by representing the ball velocity with floating-point numbers). It is NOT OK to have a small discrete number of bounce angles that are, e.g., computed using a large set of if-statements.
- The ball can hit the paddle from the Y direction as well (resulting in a heavily modified angle of reflection).
- [Highscore] (see above).

Snake (https://en.wikipedia.org/wiki/Snake_(video_game_genre) Links to an external site.)
Requirements:
- [Graphics] (see above). Note: In usual snake games, the snake moves more than one pixel in each frame update. To fulfill [Graphics], make sure that the snake moves (or is animated) pixel-by-pixel.
- There are both one and two-player modes, where the one-player plays against the computer (controlled by an AI). There are different difficulty levels for the AI.
- There are different difficulty levels, where there are various amounts and kinds of obstacles in the game world.
- [Highscore] (see above).

Tetris (https://en.wikipedia.org/wiki/Tetris Links to an external site.)
Requirements:
- [Graphics] (see above). Note: this is not how Tetris is usually implemented. Usually, the blocks move more than one pixel in each frame update. To fulfill [Graphics] and still adhere to standard Tetris rules, we suggest animating (pixel-by-pixel) the blocks from one position to another.
- Standard Tetris rules are implemented (including correct rotation of blocks, and game speed increasing over time). See, e.g., https://tetris.com/play-tetris Links to an external site..
- The next block to appear on screen is displayed.
- The current score is displayed on screen.
- [Highscore] (see above).

Flappy Bird (https://en.wikipedia.org/wiki/Flappy_Bird Links to an external site.)
Requirements:
- [Graphics] (see above). Note: In standard Flappy Bird, the bird only moves in the Y direction. Therefore, you must make it so that either the bird can also move in the X direction, or that there are moving obstacles/enemies that move both in the X and Y directions.
- Standard flappy bird rules are implemented (including randomly generated obstacles). See, e.g., https://flappybird.io/ Links to an external site..
- Obstacles gradually get closer to one another, and the gaps get smaller (or similar).
- [Highscore] (see above).

Pac-Man (https://en.wikipedia.org/wiki/Pac-Man Links to an external site.)
Requirements:
- [Graphics] (see above).
- A game inspired by Pac-Man is implemented. See, e.g., https://www.google.com/search?q=play+pacman+doodle Links to an external site.. This specification is intentionally vague, and it's up to you to define the project requirements. Pac-Man logic is usually complex enough for an advanced project (see the other advanced project suggestions for a comparison).
- [Highscore] (see above).

5. Extended Abstract

As part of the examination of the project, each student group shall submit an extended abstract. The extended abstract is a document consisting of one to two A4 page(s) of text that should include the following information:

5.1 Content of the Extended Abstract

  1. Title of the project
    The title must clearly state what the project is about.
  2. Objective and Requirements
    These paragraphs should answer the questions: What should your project do and which are the main requirements?
  3. Solution 
    The solution paragraph should state: How did you design and implement your solution?
  4. Verification 
    The verification paragraph should answer: How did you test or verify that you solution is correct?
  5. Contributions
    This section should explain who did what of the two project members.
  6. Reflections
    The last paragraph should include a few lines of reflections about the project.

Please see the following example abstract [ Download example-abstract-draft.pdf

]. This is an example of the DRAFT abstract that should be submitted in the middle of the course. It is not a real student project and should only be seen as an example of how an abstract can be written.

Note that you may write the extended abstract in either English or Swedish, but not a mixture of the two languages.

5.2 Submission

The submission of the abstract is divided into two important milestones. The deadlines are summarized on the page important dates.

  • A DRAFT of the extended abstract should be submitted using an online tool (see below). The draft should include 1. the title, 2. the objective and requirements, 3. the solution (preliminary idea of how it will be done), and 4. verification (preliminary idea of how the verification is done). You submit the draft of your extended abstract as a PDF-file in Canvas. The submission is a group assignment in Canvas, based on the "Lab & Project groups" group set under "People"/"Personer" (please define your group by adding your names to one of the groups here). Only one of you submits the DRAFT, and this submission is then valid for both members of your group (you should both see the submission in Canvas if you have joined the same project group). Note also that it is very important that you include both your names and your personal identification numbers in the submitted PDF-file. 
  • The final version of the extended abstract does not need to be submitted using the online Canvas system. But, you need to finish it on time before the EXPO, and then bring it to the EXPO. The teaching assistant will then check it during the EXPO. NOTE! The final version should explain what you have done in the project, not what you will do. That is, the requirements and the proposed solution MUST NOT be a copy from the DRAFT. Please make sure that the final version does not contain sentences like "We will do...". This should be part of the DRAFT, but not the final version.

6. Examination and Feedback on the Abstract

We will provide feedback on the DRAFT at the latest one week after the submission. We do not give feedback on the final abstract. It is checked by the teaching assistants at the EXPO. 

6.1 Collaboration and Contributions

In the project, you should collaborate. However, it is important that both of you have approximately done 50% of the actual coding. It is not allowed that one student is writing the abstract, and one student is doing the coding. It is allowed to program together, but both of you must be sitting with the keyboard and actually write the code.

6.2 Code upload

You will have to upload your code on the Project code upload. Here you upload your code as a compressed zip file. Include a readme.txt file with instructions on how to compile and run the code.

6.3 Exhibition

All students present their projects at an exhibition that will take place at the end of the course (see the schedule. Search for EXPO). There will be nominations and awards for the best projects. 

7. Development Environments

There are several alternatives for developing on the ChipKIT platform. We recommend the use of the three main options in the following different ways:

8. Resources and Advice

  • See the course web page "Literature and Resources" for a comprehensive set of links to different material.
  • See the course web page "Uno32/MCB32 toolchain FAQ" for frequently asked questions.
  • If you have any problems, please post the question here on Canvas. The teaching assistants will help you with technical questions.
  • Attend the Lunch Q&As. Please feel free to ask questions about the project.
  • Read section 8.6 in the course book by Harris and Harris (2013). This section includes a lot of relevant information for the project, e.g., info about motor control, SPI, LEDs etc.
  • We encourage you to use LAB 3 as a starting point of your project. That is, it is allowed to use the lab code, as long as you clearly declare in the code the parts that you have developed.

9. Project EXPO

9.1 Before the EXPO

Before the EXPO, you should make sure that your project works correctly, and that your source code includes comments of what you have done in the code. You should also practice a short DEMO presentation of your project. That is, you should be prepared to explain and demo your project for approximately 5 minutes. Please make sure that all team members are part of this demonstration. While we aim for the Expo to be held physically, should the Expo be held online (due to, e.g., Covid-19 regulations), then you must also prepare and test that Zoom works for you. The requirements are the same as for the labs (e.g., screen sharing, microphone, and camera to show the ChipKIT).

You must also bring your final extended abstract to the EXPO and show it. You should show this to the teacher/teaching assistant at the EXPO.

9.2 At the EXPO 

The EXPO is an event where teachers and teaching assistants walk around and examine your project. We will ask questions about the project itself, the challenges you had during the project, and how you designed and implemented the project. The project must be running, so you need to provide all equipment that you need for the demo. You should also be prepared to show the source code of your project. At this oral presentation (at which only a teacher is present, no other student groups), we will judge if you have passed the project. 

In detail, the procedure is as follows:

  1. Make sure to join your designated session SHARP (not quarter-past).
  2. (This applies only if held online) Join the initial Zoom room indicated by the teachers prior to the EXPO. Here, further information about the procedure will be given. The Zoom link will be provided in the course schedule. 
  3. (This applies only if held online) Put yourself in the course queue (http://queue.csc.kth.se/Queue/Dtek), adding your ZOOM ROOM URL in the location field.
  4. A teacher will come to you (or join your Zoom room, if online) and examine your project.
  5. When you are done with the examination, do not leave the expo. We encourage you to "walk" (physically or virtually) around at the EXPO and check out other students' project work. You must be present at the whole 2h session, but you are very welcome to join and look around at the other sessions as well.
  6. Second Opinions Should you disagree with the TA's judgment during the examination of the mini-project, then you have the right to a second opinion. In such a case, one of the senior teachers will join the Zoom room and make an independent judgment of your project. This judgment will be final at the EXPO, and any further dissatisfaction will have to go through the examiner after the EXPO is finished.

We will select certain projects for nominations as "best projects". In such a case, we will take a photo/screenshot of your project, if you allow it. Note that this nomination is not connected to any grades in the course.

9.3 After the EXPO

We will kindly ask you to return the ChipKIT boards according to instructions given for your course round.

9.4 Booking 

You should select one time slot where you present your work. The booking is done in Canvas, and opens at latest a week or so before the EXPO. Please note that only one of the students in a project group should book a slot. Note also that you are expected to participate in the whole session (2 hours). 

Good luck!