Udacity Self-Driving Car Nanodegree: My three term review
Almost a year has passed since I started the Self Driving Car Nanodegree, offered by Udacity. It was my first Nanodegree and it was a very new offering so I did not know exactly what to expect.
I am writing this review in order to give feedback, from my perspective, to make the Nanodegree even better, so I will focus on what I think its missing, than writing a list of the good points the course offers.
My positive review can be summed up in one simple question. Will I do it all over again? The answer is simple. Yes. Yes. Yes.
I understand that a good and positive vibe is important for every effort, but I am going to focus on things that need to get better.
First of all, I have to state my starting point of the Nanodegree. Since this is an almost open course, people with different backgrounds will be taking the course, so different learning curves are to be expected.
Here is my starting point. I am a Mathematician and a Civil Engineer with a PhD background (dropped it, but done 99% of it, so I know what research is). At the start of the course, I was pretty good in C++ and above average in Python (the two main programming languages needed in the course), and it was quite easy for me to write down my thoughts as an algorithm. People with different backgrounds might have very different feelings from what follows.
- One of my main concern during the course was that I did not know how the material I am learning compares to the state of the art. After I finish the lesson, what are the steps I need to do, to get a state of the art coverage for that topic.
- There are many references to material inside every lesson , but there is no centralized list of those references. If you want to look up something you have to go through every video to find it. A centralized and structured reference is absolutely missing.
- In the second term topics they refrained using mathematics although the topic of filtering is basically a mathematical one. I can understand that they try to keep the material as accessible as possible to everyone, but many times the easiest way to describe something is write it in Maths.
- The projects in the second term were too easy. Felt like a copy pasting material presented from the lessons. Too easy compared with the first term.
- Term 2 , which is all about sensor fusion, is missing some material I think. First of all, the step of transforming the point cloud we get from various sensors to objects and ‘tracking’ them and second applying a unified SLAM (Simultaneous Localization and Mapping) project, that connects all the pieces learned in Term 2
- Term 3 started great with a path planning project and it was great because we were not given code to copy paste. All labs were given either with no solution, or with python examples and then the project presented a lot of unexpected difficulties and I though YES that is a hard problem and it felt good when I solved it, but then there was a walk-through presented with a solution that was not in the spirit of the lessons presented, but the big problem is that when you are given any solution, good or bad, you will most likely follow it when you hit a dead end trying to solve it by yourself. I really think that there should be no walk through of solutions.
There are other minor issues, but those are mostly a result of the first iteration of the course and they are to be expected. I am pretty sure the simulators will be improved and new and more challenging examples will replace the current ones.
Last but not least. The final project is System Integration. Putting your code in a real car. Unfortunately, as a part of the first cohort, this project is not as interesting as it could be. Every team of five (5) persons has to tackle two basic problems (a) program a controller for the car (b) identify traffic lights and make the car stop at predefined positions. Just that. No sensor fusion, no other cars, no path planning. It feels limited for a team of five. Hopefully that might change in future iterations of the nanodegree.
The hardest part in this project was actually the lack of specification and the continuous guessing, because we could test our code in the simulator but the specifications of the car are not determined fully. For example, we are asked to provide throttle in percent but we do not know what throttle 1.0 (100%) corresponds too. Normally when you press throttle all the way down in a car, you command the engine to provide all available torque to the driving wheels, but that value depends on current speed, shift, rpm and maybe more values. We have no clues on how the car behaves and every team tries to address that problem instead of having clear specs.
I am pretty sure, that most of the issues will be resolved when you read this article and are mainly issues that every first iteration has
I almost forgot. The best part of the program are fellow students. They all share the same passion to learning, regardless of age or learning backgrounds. The Slack channel is the best part of the course. You exchange ideas with other people, you help and you are being helped. That is what makes the experience 100 times more interesting from being done in isolation.