I went into my research project with lots of ambition. Looking at my original plan, I believed I could hammer out a working algorithm within about 2 weeks. After that I was going to fly drones and generate pretty maps. I managed to get my first algorithm working about a week into the project, only to find that it didn’t work. Or rather, it did work, but only sometimes: the worst kind of “it doesn’t work”. What followed was weeks of frustration. In this post I will detail everything that went well, everything that didn’t, and lessons that I learned from working on this project.

For my project I tried to adopt a strategy that I heard of shortly before starting. The strategy, at its core, is the idea that any project will run into known unknowns and unknown unknowns. While we can predict the former, we will inevitably run into issues that were unforeseeable. In my case, I knew that one of the biggest threats was going to be scope. 6 weeks sounds like a million years to a college student until you’re in week 5. Additionally, there were plenty of skills which I knew I would need but didn’t know how to do yet:

• Feature matching in images
• Feature triangulation and re-projection
• Camera pose extraction
• Black box function optimisation
• Outlier rejection
• Streaming algorithms

The strategy I used is the principle that we should try to hit unknowns as fast as possible. This allows us to more accurately predict how on track the project is to hit the deadline. One way of doing this is to scale back the idea or concept to something that can be implemented in a short amount of time, and then fleshing it out with more data and optimisations once you get something working.

However, something I wasn’t prepared for was how demotivating the frustration of being unable to get something to work can be. The process of coming up with an idea, to trying it, to finding out it doesn’t work; is extremely demoralizing. Especially as the process can only continue by figuring out exactly why the idea doesn’t work. This shows how working as a group can really shine. Having others working on the project with you can help to prevent the crushing hopelessness from becoming overwhelming.

The most helpful interactions I had during the entire experience were the ones with my colleagues and my supervisor. Knowing that your friends are struggling too can be morbidly uplifting to hear when you’re struggling yourself. In my case, my supervisor also helped me to see the bigger picture when I had my head stuck in the weeds with a particular problem, giving me lots of ideas on different ways I could proceed.

On a side note, I found commonly while working on my project that explaining exactly what I was working on seemed to generally puzzle others. “It’s something to do with drones” was the most common way in which my project was explained by my friends to others. The actual title of my project was “Improving Incremental Structure-from-Motion Efficiency and Performance with Physical Sensor Data”, and drones were just one area in which the research was applicable. There will always be people who don’t get it, who inadvertently undermine the value that you place in your project.

While the simplest solutions are often the best, I managed to get unlucky – 3 times. It was only on the 4^th try, at the end of week 5, that the most complicated thing I had built yet reduced those critical error values to 0, or as close as could be reasonably expected. Working on this project, I found that what I learned while doing it was much more rewarding than the end-result. I gained a huge amount of knowledge on areas of Structure from Motion and Visual SLAM that I had zero prior experience with. My advice for future scholars is: be ambitious. However, your goal should be to learn as much as possible, not to achieve the most fantastic results. If for no other reason, then because the former is in your control, while the other firmly is not.