Augmented Reality

Fall term 2013
58313306, 3 credit units

This is the web page for the Augmented Reality seminar held by Elisa Schaeffer, visiting researcher at HIIT, at the CS Dept. of the University of Helsinki on Fridays 12:00-14:00 hours in room C220. The seminar will be held 100 percent in English, but personal guidance for the project work is available in other languages as well.


In a hands-on, workshop fashion, this seminar explores the existing and emergent hardware, software, and applications of augmented reality. Each participant concentrates on a particular case study.

The sessions alternate between study sessions that consist of state-of-the-art reviews combined with brainstorming and discussion, and demo sessions where the participants present the progress of their personal case study.

An augmented-reality headset will be made available to the participants for prototyping, but also smartphones make useful prototyping platforms.

Participants may continue working on their projects in the Spring term 2014 by taking the course Design and User Evaluation of Augmented-Reality Interfaces (582705).


The session contents and schedule will depend on the number of registered participants. The present estimate is around a dozen participants, making the weekly presentations (most rather informal) approximately ten minutes per person.

October 4 & 11 there is no joint session — all work is submitted online at latest by noon the day of the seminar and the feedback is done by using the commentary mechanisms of the publishing platform.

  1. September 6: introductions and topic selection

    No grading for the first session; remember to confirm your enrollment by e-mailing the instructor.

  2. September 13: conceptual designs and feedback

    Explain your contribution on the level of a conceptual design, that is, discuss the "what" without dwelling in details over the "how". Just a few of slides will suffice, preferrably with illustrations.

  3. September 20: reviews of existing products and literature

    Make a BibTeX file of all reviewed sources and use it to prepare your slides in LaTeX. Include your previous work on the conceptural design in the beginning of this second presentation (that is, keep appending the future things to what you already have).

    Place the .bib/.tex/.pdf files of your slides and all reviewed material into a Dropbox folder and share it with the instructor to her GMail account.

    LaTeX/BibTeX use is not optional, neither is storing the full-text PDFs of your references; you will need all of this later on as well. If you choose not to use Dropbox, please contact the instructor for an alternative shared-storage solution.

    If you need help in setting up TeX, please contact the instructor for a personal tutorial session to resolve this.

    Literature-search starting points

    Use the first links within the university domain for full-text access, the second links for outside browsing, when provided.

  4. September 27: functional requirements

    Add a new section to your presentation to discuss the specific features you plan to include in your prototype. You can choose from traditional techniques such as use cases and/or story boards to document the functional requirements of the proposed AR system or invent your own method of communicating this aspect of your work.

    If you consult any new references, remember to add the full-text PDFs to your project folder and include the corresponding entries in the BibTeX file. Please consider using a spell checker (such as ispell or aspell) on your slides.

    Note that the focus of the requierement presentation is on "what can be done and how does the user achieve this". The technical part ("with what technology" everything actually will work) follows next week.

  5. October 4: technical specifications (online)

    Now, turn your slides into a LaTeX article (some guidance) that has sections for conceptual design, existing literature, functional requirements (you may name these as you wish; use the contents of your slides thus far to populate these), and prepare a new section for this week's theme. Turn your slides' bullet points into full sentences and meaningful paragraphs. This will help to build your final seminar report.

    The new section should include, in the format of your choice, all relevant information regarding both the hardware components (which device, with what specifications, using which sensors or device features such as cameras or GPS) and the software components (APIs and libraries you use, open-source projects you base on, etc.) you will base your prototype on. Also specify what you will need to build, additionally, if some custom components are needed for your prototype. This also applies to any software modules you will create.

    Explain for each SW/HW component what you need it for, specifically, and why you chose it; if you had multiple options, please explain what the others were and why they were discarded. Don't forget to include any new references in your BibTeX file.

    For the bibliography, please use numerical references produced by the package natbib with options sort&compress. Do not think of the citations as words; use author last names when needed to write sound, complete sentences (achieved automatically with citet when using natbib).

    Send an e-mail identifying the folder and file name of your resulting PDF to the instructor before noon on October 4th; she will share everyone's documents with the rest of the group so you can comment on them over the week and gain interaction points. The resulting grade will be posted on October 11th.

  6. October 11: demos of partial progress (online)

    Post a video demostrating the first "draft" of your prototype (build, programmed, animated, whatever you choose to use as a prototype) on YouTube, Vimeo, or some similar service. The video should last 5-10 minutes.

    Add the URL to the video to the file in the previous week's Dropbox folder (by noon Oct 11 unless you want late penalties, 10 percent per day) and comment using the comment file in that same folder. The resulting grade will be posted on October 18th.

    Note that the next session will be on November 1st (two weeks break as the university has some mid-term exams).

  7. November 1: collective debugging

    No need to bring a report or a presentation, but please prepare a "bug list" of things that you still haven't been able to implement satisfactorily. In the session, everyone will get a chance to show their present state of the implementation and point out any bugs etc. with which they hope others could help in some way. Points are given for identifying your own bugs and naturally for giving out useful suggestions for the bugs of other people.

    If you are unable to attend the session, please post a list of your bugs in the facebook group beforehand and we can discuss them there. It's easier to get lots of points if you attend, though. And, if you're anti-facebook or something, just attend in person. Let's not make this complicated.

  8. November 8: structuring the project reports

    Bring a tentative TOC of your final report (post it on fb if you are unable to attend); in the session, we will peer-review the TOCs and give suggestions of improvement.

    The final report should be designed to be self-explanatory and to fully document the seminar work in technical report style, that is, somewhat more detailed that would be expected of a conference paper.

    If this sounds like very little work, you're forgetting that you need to have the implementation of the prototype ready two weeks later and the report needs to be written, too.

  9. November 15: revision of written reports / project documentation

    Fill in the TOC from previous session to be the near-final version of the final report of the seminar project. This needs to be prepared in LaTeX, with a adequate bibliography maintained in a .bib file as before. Check the spelling and the grammar before our weekly seminar session. If you cannot attend, send the .pdf to the instructor beforehand.

    The session will be somewhat quiet and boring as everyone will read everyone else's reports and suggest improvements/corrections. We can also help out if anyone is struggling with last-minute bugs, as the prototype implementations need to be almost finished already.

  10. November 22: prototype demonstrations (live and/or video)

    Prepare a 10-minute (neither much less nor much more) presentation, considering that some of the public may not have seen any of your previous presentations nor the report beforehand, of your seminar project. Make sure that both the slides of the presentation and the final report are available someplace online and that you mention this location in your presentation. It is also desirable for at least some of your code to be available at an online repository and that this location is mentioned in the presentation.

    If you are unable to or do not trust the robustness or portability your demo environment enough to carry out a live demonstration, prepare a video of that part. Preferably, post the video online and mention the URL in your slides and the report. For the smoothness of the presentation, however, try to bring the video file with you in case it won't load online.

  11. November 29: final feedback and future work

    The last session is dedicated to discussing what we could have done differently to make the projects or the seminar itself better and also for planning where and how to continue with the projects.

    You'll receive one point for active attendance. There will be a votation regarding who did best in different aspects of the seminar and the winner of each category receives a point. The points of the final version of the report will also go here. Special awards will be considered for people who get more than 100 points in total.


I will be happy to receive you at my office A337 to discuss and/or debug your project work. Please make an appointment a couple of days before you wish to meet by e-mail to — once I know you personally, I can also add you on Facebook and/or GMail and we can talk online by chat.


Peter Hedman developed an application for recognizing people, for those of us that cannot recall names or faces too well. His slides and report are available online.

Zachary Laster proposed a system for integrating AR-techniques into LARPing. The report, the slides of the final presentation, and the mobile application for Android are available online.


There are no examinations. The first week there is no grading whatsoever, but in the following weeks, 10 percent of the final grade is accumulated per session.

Arrangements for online participations (both to present your work and to discuss that of others) or offline video participations (presenting your work when you cannot attend a specific session) can be made on a case-by-case basis, contacting the instructor beforehand (at least a couple of days before each session). Expect the people present to receive on average slightly higher grades than those absent, as they have a better opportunity to fully participate.

The grade limits are adjusted at the end of the seminar and are the following (expect no further changes), in terms of the accumulated total (T):

Each person is identified by a unique suffix of the student ID assigned by the university. The score received from each graded session (zero to ten) is shown in the columns. The final column shows the accumulated total.

ID suffix Graded seminar session Σ Grade
12345 678910
3775 7 8 7 8 9 5 5 5 1 1 56 1
4471 8 9 9 10 10 10 10 9 9 9+4 97 5
5669 9 10 10 10 10 10 10 10 9 10+1 99 5
6345 8 8 8 9 10 10 10 10 8 9 90 4
6479 7 6 8 8 10 10 10 8 7 8+1 83 3
6775 9 7 9 7 10 - 10 8 - - 60 1
6918 8 8 8 7 9 10 10 9 8 7 84 3
7475 7 7 8 8 8 10 5 7 8 5 73 2
9731 10 10 10 10 10 10 10 10 10 10+6 100+ 5

Updated on December 19, 2013.