## Revision 3b5d148f80155798378a8a1726e1d771b1a4c4b2 (click the page title to view the current version)

# Assessment Guide (Machine Vision)

# Overview

- The exam is viva voce.
**Duration**Normally 20 min. May extend up to a maximum of 30 min. if necessary.- The student manages the first seven minutes of the exam to make their case to demonstrate that the learning outcomes have been achieved.
- The student is free to bring any material desired to serve as a demonstration. However,
- having developed a product is not sufficient.
- The candidate has to demonstrate that they understand how to develop the product. See below for elaboration.
- This is both because depth understanding is a learning objective in itself, and because we cannot otherwise know if the student has developed the demo themselves.

- Unexpected learning outcomes should be valued, in addition to the learning outcomes in the module description.

- The remaining 2/3 of the exam is for further questions from the examiners to make sure that all the learning outcomes are covered.

# Learning outcomes

The assessment is made with respect to the learning outcomes from the Module Description, as follows (with numbering added).

**K1** The candidate can explain fundamental mathematical models for digital imaging, 3D models, and machine vision

**K2** The candidate are aware of the principles of digital cameras and image capture

**S1** The candidate can implemented selected techniques for object recognition and tracking

**S2** The candidate can calibrate cameras for use in machine vision systems

**C1** The candidate has a good analytic understadning of machine vision and of the collaboration between machine vision and other systems in robotics

**C2** The candidate can exploit the connection between theory and application for presenting and discussing engineering problems and solutions

# Interpretation of Grades and Learning Outcomes

## The Grade C

The Grade **C** represents solid working knowledge of the most important techniques in the syllabus. This includes

- Sufficient knowledge to be able to implement and use the technique. (S1)
- Sufficient theoretical understanding to vary the techniques and adapt them to different use cases, including but not limited to parameter tuning. (C2)
- Sufficient theoretical understanding to explain when and why the technique is appropriate. (K1, C1)

Which techniques are most important may be subject to opinion, but the following has a good case,

- Feature tracking - i.e. identification of objects in a video, and tracking of these objects across several frames. (S1)
- Calculation of relative pose and reconstruction of 3d scenes. (C1) The eight-point algorithm is the core of these techniques, but it is also critical to know why the algorithm does not suffice in practice (e.g. with uncalibrated views), and have an overview of practical solutions and challenges.

A student who merits a C can be trusted to implement these techniques correctly in a project without close supervision.

Students who have focused on other techniques which are important for their own education, may choose to focus on them, as long as

- they are taken from the syllabus and learning activities, possibly extended with other sources.
- they constitute a similar volume and challenge as the above.
- they address the learning outcomes (S1, C2, K1, C2) as mentioned above.

The student also needs a cursory understanding of the remaining learning outcomes (K2, S2).

We respect that some students may have a more practical, and others a more theoretical understanding of the technology, and that both may merit the same grade. The **C** Grade is a broad category.

## The Grade A (and B)

The Grade **A** represent broad and deep understanding of all the material discussed in the module. This includes the requirements for a **C**, and additionally the **A** student has

- working knowledge of additional techniques from the syllabus.
- solid understanding of learning outcomes K2 and S2.
- deeper and more complete understanding of the underlying theory than we expect for a
**C**

To merit an **A** the candidate has to impress and surprise. The performance has to be *clearly outstanding*, as it says in the nationaly guidelines:

An excellent performance, clearly outstanding. The candidate demonstrates excellent judgement and a very high degree of independent thinking.

The Grade **B** is an intermediate grade. The candidate demonstrates some features of an **A** and thus exceed the expectations for a **C**, but they do not have to be `clearly outstanding’.

## The Grade E (and D)

Grades below **C** represents working knowledge which can possibly be of value in a development team, but not sufficient for the candidate to be trusted to carry out independent work.

As for the **C**, the candidate has to

- demonstrate working knowledge of the most important techniques in the syllabus,
- be aware of some of features that require tuning and adaptation in practical situation.

Unlike the **C**, a certain awareness of the underlying theory suffices. This is not expected to suffice to adapt and justify solutions to practical uses beyond routine problems.

## Failure

There is not much to say about the grade **F**, other than its falling short of the working knowledge described for E. The most typical case of a failure is probably going to be fragmented or disconnected knowledge. This includes both inert facts which have not been put together to a whole which can be put into practice. It also includes, even if practical, memorised rigid procedures without the ability to adapt and tune them to different needs.

# Some tips on presentation

It is important to emphasise that the focus of the exam is your *understanding* (competency, skills, etc.) and not your achievements. Hence, when you are allowed to present your work from the exercises, the focus should be on what you have learnt, and not what you have made.

A software demo can be useful, but you should *always think carefully* about *what we can learn from the demo*. This can be done in many ways, so these are only ideas.

- Demonstrate both cases where the software works and cases where it does not. Discuss why.
- Discuss the underlying theory of how it works.
- Discuss mistakes you made on they way, and how the experience helped you find a better way to solve the problem.

We derive understanding both from theory and from experience, and both are valuable.

A software demo is by no means mandatory. It is just one way out of many ways to visualise experience. There are other ways to visualise experience, and it is also possible to derive your understanding from theory only.

The underlying theory is important. If you use a software demo, you should expect questions about details in your code, such as how filtering, differentiation, and convolution works. If you do not use a software demo, you can get the corresponding questions about how the algorithm is defined in terms of filtering, differentiation, and convolution.