Kristoffer Gryte

Kristoffer Gryte

Researcher on Software for Autonomous Systems

Guidelines for Master and PhD students

The intention of this document is to make the collaboration of you, the student, and me, the supervisor, as fruitful as possible. To achieve this, we need to establish a foundation.

I will also include some useful hints related to working on a thesis. There are many good sources of information regarding this, but I would like to point out a few:

Note that these guidelines are somewhat opinionated. You will not fail your project if you do not follow them, but I hope they are useful and that reading this document will give you a head start.

Style of supervision

As a supervisor I will try to show you how to fish, but you will be the fisherman. The perhaps biggest challenge with master/phd projects is that they are research based, and thus have never been done before. This makes them difficult to plan. Fortunately, I have some years experience with this and am here as a resource that can guide you through your project, but it will be your project and you will be responsible for the progress. Enthusiasm is contagious, so the more interest you show, the more interest I will have :)

It is my current understanding that there are two main ways of doing this (but feel free to suggest other ways :)). I will let you decide which approach we should choose, a decision you should take based on how you know yourself to work best (I have no knowledge of this, and thus no preference).

  1. some work better under pressure and deadlines. Then I suggest that we schedule short meetings every N weeks where we discuss your past findings and future milestones.
  2. some work better with more freedom. Then I will leave it more up to you when you feel it is time for a meeting.

A mix between the two strategies could be that we schedule a deadline every M weeks before which you will send me an email with an update on your status, to ensure progress while maintaining freedom.

I will of course be available for questions over email outside of these meetings. Formulating a question in an email is a good strategy for sorting ones thoughts! (I have started writing a lot of questions in emails, only to realize that I had the answer myself, or have been able to find it). I will generally be very available on email, at least for shorter replies, and if needed we can schedule syncs for longer discussions. Note that I say “work better”, as opposed to “prefer”. Be critical; there is no free lunch, and there will be work involved no matter what approach you choose. Regardless of the strategy we choose, I expect that you will be well prepared for our meetings, which means being well informed about your recent findings, current problems and have an idea about what should be your next milestone (which we will agree upon at the end of each meeting/sync).

I also recommend that you share the report and/or work log with me (see “Writing a report” below). Then I can drop by to give comments and view your progress from time to time, or per request. This also applies for the code you are writing.

Kick-off meeting: the first meeting

See Step 1 in (Lundteigen 2022).

In the kick-off meeting we will

  • Discuss the topic for the project
  • Establish a collaborative environment, where feedback and motivation make us better. Please think through the following prior to the meeting:
    • What can you expect from me?
    • What should I expect from you?
    • What do you expect from yourself?
    • What motivates you? (both in general and regarding this project)
    • Pushing vs freedom
  • Style of supervision, see above. How often? How should we communicate?
  • Go through any questions from this documents
  • Discuss how to plan the project, see (Lundteigen 2022) section 2.1. Note that this is not compulsory, and its form can vary, but “Failing to plan is planning to fail”.
  • Plan for the “MSc seminar”, after 2-4 weeks, where all my students present the topic of their project to each other.

Supervisor meetings

The day before each meeting you should communicate the following information:

  • What is the current status of your work? (What has changed since our last meeting?)
  • A list of what you would like to discuss or questions you may have; an agenda. Can also be non-technical. It is advisable to start with the most important, to make sure we have time for it.
  • What (do you think) will be your next step? We will agree on this during the meeting.

This is motivated by

  1. You are forced to take a step out of your project, and get an overview. Perhaps you discover that you are heading in the wrong direction?
  2. I can “prime” my brain, to make our meetings more effective.
  3. It is emphasised that you run the project. I’m here to guide you along the way.
  4. It enables more efficient use of our time together (Don’t waste meeting time by e.g. changing the code to plot some weird behaviour; plot it in advance)

This communication should be informal, for the sake of efficiency (but formal enough to get the message across). I would prefer if we did this through google docs or Office365: create a document based on this template and invite me to the document (for google, my email is the same as my NTNU email, but @gmail.com). We will use the same document throughout the semester, by adding the newest meeting at the top of the document. Also send me a notification when you have added the material for the next meeting, to remind me.

Planning

See (Lundteigen 2020).

Also, keep in mind my favourite quote: “A plan is nothing, planning is everything” (Churchill). Things rarely go as we plan, since research by definition is to do things that have never been done before. But we should try, and we learn a lot from the planning process itself.

Various tools exists for planning, such as Gantt diagrams, but do not over-do it! The power of pen and paper should not be underestimated. I personally use a simple todo-note application (Todoist), that lets me sync my todos/refs/thoughts between my phone and computer. One simple “planning tool” is to start writing the table of contents as soon as possible. Although the project will almost certainly change, thus also the table of contents, this trick will make it aparrent what gaps you will need to fill.

If you want feedback on your final report, plan to finish at least one week before the deadline and “book” time in my schedule. I have several students, and several other projects, so time around report deadlines tend to get busy.

Writing a report

See (Lundteigen 2020) and NTNU Academic writing, in particular “Using and citing sources” (covers reference management tools, plagiarism/copyright), Latex+bib(la)tex, Planning, structuring and writing your thesis.

Remember;

  • the report is a live document. Use it as as a document in which you can express/recite what you have learnt, to make sure you have completely understood it and its implications
    • another approach is to have two separate documents; one as a “work log” that you can use to document your progress and questions, and which we can communicate through comments.
  • the report should not be a mere work log (first I did this, then I did this, then I realized that I had screwed up and went back to the first step), but an academic document. This means that sometimes there is a very nonlinear relationship between time spent doing something and how much space it is given in the report, but this is how it is and is something the sensor will know :) (In my PhD I spent around two months on work that resulted in the sentence “The inertia matrix was found to be …”)
  • A common structure for academic writing is IMRAD(Introduction, Method, Results And Discussion/Conclusion), but I usually also include a part with theory. The parts/chapters are not necessarily named e.g. method, but it should be apparent to the reader what he is about to read. It can be challenging to find the right structure for your work, and where to put a certain section, but below are some advice (also; google is your friend).
    • Introduction: Focus on motivation. Why are we doing this? What has been done before, and why is this not adequate (why is our additional contribution needed?)? What is the research question or hypothesis that is investigated? Should not be under estimated, see “Litterature study” below.
    • Theory: The theoretical background needed to understand the rest of the work, including notation. Consider your reader; what does he need to know? (Hint; he probably already knows e.g. matrix multiplication and the definition of rotation matrices).
    • Method: How did you arrive at the results? Explain what you did (why this way, and not another?). Should be clearly separate from the result section.
    • Results: the outcome of the experiments. Try to be objective.
    • Discussion: what are the implications of the results, in a bigger context? Is this as expected, wrt previous work/common sense/established truths?
    • Conclusion: should be a final conclusion on the entire report. This means that
      • It should be the final section (apart from maybe appendicies), definitely after the discussion and future work, as it conludes these sections as well.
      • No new arguments or views should be brought up in the conclusion
  • Readers, also sensors, are lazy.
    • Ask yourself; Who is the reader? A rule of thumb regarding the level of detail to include (for project/master theses) is to write to someone in your grade that is working on a different topic for their thesis, or to write what you would have liked to read when you started this work.
    • Writing well is more difficult, rewarding and important than writing long. Do not add material simply to fill more pages. No one likes to read more than they have to, this also applies for sensors.
    • Consider how you can get you message across as easily as possible; would a figure make this more intuitive?
  • Consider the thesis an hourglass; it is at its widest, most general in the beginning of the introduction. The writer should ensure that the reader follows the arguments as the pyramid narrows. When reading the theory and method it should be apparent why this material is included. Towards the end, in the discussion and conclusion the thesis widens its focus again, linking back to the introduction and considering implications.
  • Do not include a “List of Figures”, “List of Tables” etc. This is my opinion, but no one reads it so it only wastes paper. A notable exception is of course the table of contents.
  • Do not include figures “at random” (particularly; do not merely add plots to the result section as “proof of work”). Each figure should have a clear purpose, which should be explicitly stated in the text, and you should be sure that the figure illustrates this in the best possible manner. Create the figure based on what you want to illustrate/emphasise (example; your controller performs similar to the benchmark-controller except for in the down-wind turn, where yours reduce the crosstrack error. Zoom in on this section of the dataset) (another example; plotting roll/pitch/yaw for a long dataset is often not very interesting because the interesting (small-scale, e.g. a two degree difference in the roll response) details are invisible when viewed alongside the (large-scale, e.g. a roll angle change from -40 to +40 degrees) motion of the vehicle).

At the end of the master thesis I ask my students: “What would you have done differently if you were to start over?”. The unanimous answer is: “Starting to write sooner”. There are a number of reasons why this is a good idea:

  • writing forces you to face, and understand, all the aspects of the material.
  • writing a report is a maturing process: most writing improves by revisioning, and the sooner you start the more you will reconsider and revision the material.
  • by writing you will see connections between the different topics

However, there are also some drawbacks of writing early:

  • early in the process, before the final results are ready, it is difficult to know exactly what the conclusion will be. Thus, some material might need to be re-written slightly when we have the full picture.
  • easy and endorphin-fulfilling to write (“copy”) too much background theory, since it feels like you are doing something useful. But this can be a waste of time, battling Latex equations etc. To be clear; writing is an excellent way to learn, but be critical on your time consumption and don’t spend time on e.g. pretty formatting for things that does not end up in the report.

Goals/objectives

The introduction should make it clear for the reader, and the sensor, what your goals and objectives are for this work.

One word of advice; think ahead to the results, discussion and conclusion when you set these objectives, and plan how you can show that you in fact have accomplished them:

  • be specific: “make it work” is a very vague objective. It is also somewhat limiting for the thesis, as “it worked” is a very minimal conclusion. Instead say that you will compare your solution to some other algorithm (compare your MPC to a PID), (and plan how you will compare it). This will lead you to discuss your work in a much greater detail, and show that you actually know what is going on, which often is what the sensor is looking for.
  • use metrics: to compare different solutions, some “objective” way of assessing their quality is needed, to motivate your conclusion and to show what you have emphasised. This could be as simple as the mean error and standard deviation, or could also be a (possibly weighted) assessment of more subjective metrics as “complexity”. Regardless; this needs to be presented.
  • think big: why is this problem important in a bigger context, and how good must the solution be to be applicable?

Literature study

This step is often under estimated! When doing research, the majority of the time is spent familiarizing with others peoples work, to understand what is the current “state-of-the-art” within a field of research. How do these solutions relate to the problem you are trying to solve? Can they be applied directly, or will they need some modification?

I like to think of the shared knowledge of all mankind as a large sphere. When you are born, your knowledge only spans a very small, central volume of that sphere, but by the time you start primary school it has grown significantly, in many directions. As you choose your high-school discipline, your knowledge-volume will grow more, but in a bit more narrow direction. Throughout university, this growing and narrowing continues. At the start of your master project, you are quite close to the boundary of the knowledge sphere in areas related to engineering cybernetics. The goal of the project and master thesis is to take you all the way to the boundary in the topics covered by your project. When you are at the boundary of the knowledge sphere you can answer the question; will the shared knowledge of all mankind be sufficient to solve the problem of my project, or will I have to push the boundary slightly further?

My advice is therefore to not underestimate the literature study. It might seem counter productive and less fun to read how other people solved a problem, compared to solving the problem yourself, but I can promise you that it beats spending a lot of effort to solve the problem yourself first only to find that it was solved more elegantly by some Russian in the 1850s.

It is also very easy for the sensor that is evaluating your work to guesstimate if your work has merit. If your literature review seems inadequate, which is often seen from a poor introduction chapter in the thesis, chances are that your work does not have a sufficient foundation on the current state-of-the-art. To avoid this, I would recommend that you keep your introduction section in mind as you read thorugh the literature, and that you aim to include at least 15-20 quality references in the introduction (as a rule of thumb, for a master thesis). The aim of the literature study is not to show that you have read a lot, but to argue that your way of solving the problem makes sense. The literature study will often be on the form “these people solved this part of the problem by method X, which was later improved by this other group by considering Y. However, the problem considered herein is more complex, as adds . The work presented in this thesis extends method X by applying , to account for ”.

Make it a habit to

  • organize everything you read
    • take notes when you read new material, both as a cognitive hack, as you learn better when doing this, but also to help the future you when you have forgotten what you read (this will happen!). This applies to everything from academic articles to code review. There are many different thoughts around this, but find something that works for you. Personally, I have found Joplin to work well (but now I use a personal wiki written in Markdown using vim (specifically wiki.vim), but this is probably too nerdy for you).
    • keep track of academic articles you read, and keep them organized, i.e. using tools like Jabref or Mendeley, so you don’t forget what topics they where on. Possibly add a quick “remember to cite kalman1960new as the origin of the Kalman filter” to you manuscript. I use a consistent naming scheme for papers and citation keyes: authorYYYYfirst_word_of_title. The paper “A new approach to linear filtering and prediction problems” by Rudolf E. Kalman from 1960 is saved as kalman1960new.pdf, and is referenced as \cite{kalman1960new}. (The “A” in the beginning of the paper title is ignored, as this is the default behaviour of Jabref)
  • take notes in your own words! Not only will this help you understand the material better, but you will also avoid issues with plagiarism}
  • visualize concepts, ideas and thoughts (“A picture is worth a thousand words”). Paper drawings are fast, trigger your brain, and work well for sketches, but for the final report it is advisable to digitalize them. It is often tempting to re-use a figure from a web site or a previous publication. To avoid problems with plagiarism and copyright infringement, it is important to 1) reference the original source and 2) obtain permission to use the figure (by contacting the author/publisher or using figures that have an open licence, such as Creative Common licences that apply to e.g. everything on wikipedia).

Tips on how to find good references

  • See NTNUs information on Literature search and master thesis
  • Search engines: I primarily use Google Scholar (open) and Scopus (accessible for NTNU students and faculty). I find Google Scholar more user friendly, but Scopus has more advanced search options which is useful to narrow down a search with many results. Another option is IEEE Xplore, but everything there is also indexed by Scopus and Scholar.
  • When on a new topic, it is tempting to start by a very general search (“Adaptive control”), which will produce overwhelmingly many results. I advice you to instead find one or two very relevant sources, and continue from there. By reading these you will become more familiar with the topic, and can refine your future searches. You can also leverage the research community; what relevant sources are cited by the sources you read (in the list of references)? Unfortunately, this limits you to sources that are older than the original source. Both Scholar and Scopus provide details on who has cited the source you read (i.e. after it was published). Another interesting tool is Connected papers, which creates an connected graph of relevant papers based on your input. It used to be free, but now it is only free for up to 5 graphs per month.
  • Finding information:
    • references of other articles
    • who has cited
    • other work by the same group?
  • obtaining the article/book: most articles are available online, as long as you are on the NTNU network/VPN. If not, the University Library can help
  • reflect on the quality of the source. Most academics seek to publish in the most prestigious publication channel that will accept their work, so be sceptical to work found in “strange” and unknown conferences/journals, but there are exceptions. To assess what is a prestigious publication channel, consider e.g. Google Scholar Metrics.

Latex

Serious reports are written in LaTex. Find a template that you like (from e.g. a friend, or the internet where I found this), and make sure that it follows the NTNU printing requirements. Do this first thing, as fixing latex problems introduced by changing templates can be annoying! A friend with latex-skills could be useful at some point, so make sure to buy him/her lunch :)

Many students prefer to write the report in Overleaf/Sharelatex. Make sure to link it with your NTNU email to get a “premium” account, which will allow you to share it with multiple people. Other, local latex editors are also applicable (again I use vim (with vimtex), and again it is probably too nerdy for you), but make sure you have a backup of your work, through e.g. OneDrive or git.

Tips:

Useful packages

  • siunitx: \SI{0.5}{\meters\per\second}. Ensures typographically consistent units. Perhaps a bit overkill for master theses, but very useful for articles, since different publishers might have different requirements on how units should be printed (m/s or ms^-1, which then easily can be re-defined in the preamble). Also provides the table-alignment mode S, that aligns table columns on decimal points.
  • todonotes: \todo{make sure to fix this}. Add a nice, visible box with a reminder for you. Also includes \missingfigure{Figure of a ship}, so that you can start referencing your figures in the text before you have included the actual, final figure. \listoftodoes creates a (temporary) list of todos. But the best part is; by simply adding the argument disable before you hand in your thesis (\usepackage[disable]{todonotes}), all the todos are magically hidden and you can be sure that there aren’t any silly “is this correct?” notes in the version you hand in.
  • cleveref: Unifies referencing to equations/figures/tables/chapters/sections/.. You only have to write e.g. \cref{eq:newtons_first} (as opposed to “Equation \ref{eq:newtons_first}”), and cleveref will figure out that eq:newtons_first is an equation, and appropriately add “Equation”. Simple to specify if you want it to say Equation 1, equation 1, eq. 1, Eq 1, (1), or any other style. It is also possible to write “In this \namecref{chap:intro}…”, which will read “In this section” or “In this chapter” depending on whether “chap:intro” is a section or a chapter (maybe you move them around?)

Continuing the project thesis into a master thesis

When continuing the topic from the project thesis in the master thesis, the project thesis should be submitted along with the master thesis so that the sensor has access to both. Keep in mind that the master thesis will be publicly available, while the project thesis is an internal document which is not accessible to others. It is possible to re-use material from the project thesis directly in the master thesis, but this should be explicitly stated (“The following section on X is copied directly from the project thesis”). It is advisable to keep this to a minimum (rephrase where possible). Sensibly, equations can be re-used so you do not have to re-invent math or change variable names :)

Working on a (large) codebase

Make backups

While walking around in Trondheim, looking for a place to live before I started my studies, the city center was covered with notes saying something like “Dear you who stole my Mac! Please return it, as it contains the only copy of my master thesis work!”. Needless to say; this should be avoided, by taking backups.

There are several alternatives for backup (Dropbox, SVN, memory stick copy,…), but for code, the #1 tool is git. If you are not already familiar with git, it is highly advised that you spend some time learning the basics (clone, pull, push, commit, merge, rebase). Do some google searches for “git howto”, “git guide”, “git tutorial” etc. See for instance this guide, and Learn Git Branching is an excellent interactive guide. Create a github-account, experiment. See also this extensive list of common commands. Also, stackOverflow usually has you covered.

Other git resources:

When times get tough

Keep in mind that progress is inherently nonlinear; it is completely normal to get somewhat “stuck” from time to time. Do not get stressed about getting stuck (remember; “Det er i motbakke det går oppover”), but keep pounding the problem. Talk to a friend, can you look at the problem from another angle? what is the cause of the problem? Try writing out the problem as explicitly as you can, for example in an email to a friend or in your work log to me, and see if that makes you understand it better.

Sometimes, life throws you a curve ball. In my experience, most problems are bigger inside ones own head, so I encourage you to talk/write about it. Your well being is important to me, so do not hesitate to contact me. If you feel uncomfortable by talking to me about your problems, there are some NTNU resources that I would like to inform you about:

References

Lundteigen, Mary Ann. 2020. “Tips til å skrive rapport.”

———. 2022. “Tips til planlegging og gjennomfœring av fordypningsprosjekt og masteroppgave.”