What did I learn from Artificial intelligence for robotics course by Udacity

Introduction

During the last months I did not publish any blog posts. The reason is simple. I was busy with some other topics.

One hand I’m a lucky guy, who did not lose his job due to the current situation, I even had a bit more tasks to be done.

On the other hand, thanks to the flexibility of home office I managed to attend some online courses. Furthermore I’m preparing a material which is giving a great overview on the topic of version control with GIT, you will get more information about this project soon. And of course I occupied myself with non profession related activities.

Now the time is here to become active again on blogging.

During last spring there was an offer from Udacity for taking their “Artificial Intelligence for Robotics” course for free.

Since I have a stronger background of software development, but less experience with robotics algorithms I decided to take it. Let me write some paragraphs about my experience.

How about Udacity

I had no previous experience with Udacity, but I already took several courses from Udemy, which is one of their concurrents, so that’s a good base to compare.

Since I took that time the free version of the Udacity course the service was also limited: I did not have project review and mentorship to the project and I also did not get a certificate in the end. Later on I attended the Self Driving Cars nanodegree program as well, so I also have experience with the commercial Udacity courses, but let’s discuss it in a later post.

While doing the Udemy courses I often found myself bored and lost my attention. In the case of Udacity it was not the case at all.

The material is splitted into lessons, each lesson takes between 1 and 2 hours. During the lessons videos, written materials and quizzes are changing each other. The videos are following a friendly and natural style, while they are explaining well the problem and the solution. The written materials are giving a great summary on the theoretical part of the topics, sometimes even links are attached for some additional materials. The quizzes are either questions with some selectable options or coding tasks where you have to write a small piece of code or extend a given one. All your solutions are evaluated automatically. This is the way how you are making your attention alive and how they are forcing you to really understand the material.

After each session there was a section called “Problem Set”, which contained some tasks which covered the topic of the previous lesson and a “Q&A” session where the most frequent questions are discussed.

In the end of the course there was a practical exam with a list of practical tasks covering the whole material and a final project, called “Runaway Robot” to be solved. It was a real challenge, but it made me learn a lot.

It was a nice experience.

The content of the course

The course itself introduced the most important problems of robotics and their possible solutions. I prepared a very brief summary of these topics.

Since you find a lot of material about these concepts online, I won’t go into details this time, I’m rather just giving an overview.

Localization

The first chapter was about robot localization. The problem to be solved is to decide where the robot is located based on its motion and it’s senses.

Back to the university we learned a lot about distributions and probabilities. That time I did not really understand why we have to learn it, it was pure theory, so I did suffer a lot while learning it.

This chapter brought me at least one purpose, why I had to learn it that time and it also gave a great fresh up of the topic.

Furthermore it introduced me to some robot motion models.

All things considered it gave me a nice overview on the problem of localization.

Kalman filters

Kalman filters are great tools for making some predictions based on historical data. They are based on gaussians, which are functions to represent values with their probability.

So that if there’s a series of measurements with a given probability (for example about the position of the robot or of another object), Kalman filters can update the gaussian after each measurement based on the new measurement values and tell the most possible position of the tracked robot or object. One of its most useful applications in the world of robots and self-driving cars is sensor fusion, where it combines the measurements of several different sensors.

Another fact I have to mention, that it’s named after Rudolf Emil Kalman, who was Hungarian, similarly to me.

As part Udacity Self Driving Cars course I managed to implement an extended Kalman-filter, feel free to take a look: https://github.com/lmarcell/CarND-Extended-Kalman-Filter-Project

Particle filters

The idea of particle filters provides an efficient filtering method, which is really easy to program and which can be used for example for localization. 

The main idea is to randomly create a large amount of particles, which are basically guesses where the robot is located at the moment. Then a weight shall be assigned to each of the particles. After each movement of the robot these weights shall be updated. High weight means that it’s very likely that the robot is around, small weight means that there’s only a small chance for that. By following this method after several movements it will be visible what is it’s most probable position.

Path planning

To find an optimal path between two points in a huge space is a challenging task. However this is a very important topic when we are talking about robots.

In an ideal case we already have a map of the space, but since this space is huge the classical path search algorithms, like breadth-first-search or depth-first-search are not efficient enough to find the most optimal path.

During the course two more efficient solutions have been presented. The first one is the A* algorithm, which is a kind of extension of the classical Dijkstra algorithm. The main idea is to introduce a heuristic function which provides an optimistic guess for the distance from a position to the goal position. So that takes the way where we expect the smallest distance based on the heuristic function.

The main challenge is to find a good heuristic function, since using the wrong heuristic function makes this algorithm really inefficient.

Next to A* algorithm the main concept of dynamic programming was also presented in the course.

PID Control

You have already planned the expected path of the robot, the next step is to let the robot follow this path. This may sound like a trivial problem, but it isn't. Just imagine: your robot is moving with a permanent velocity and you can only tell it if it should turn right or left. And you have the reference path, which should be followed. The most trivial idea is that if the robot is left from the reference path then let it turn a bit right. If it is right from the reference path let it turn left. In this case it will more or less follow the reference path, but it will always overshoot, so cross the reference path and this will result in a very strange and uncomfortable moving for the robot. A PID controller introduces a so-called differential and an integral component as well. If you find the right weight for the different components then you can reach a quite smooth and comfortable moving of the robot.

To find the optimal weight is also not trivial, but fortunately there’s a great algorithm called twiddle, which can help you.

As part Udacity Self Driving Cars course I managed to implement my own PID controller, feel free to take a look: https://github.com/lmarcell/CarND-PID-Control-Project

SLAM

SLAM stands for simultaneous localization and mapping. This can be used in the case when you don’t have a map of the environment of the robot. For example you have a vacuum cleaner robot and you want it first to move around the room and create a map of that, so that later it can find the most optimal path for cleaning it.

This is the problem of SLAM. This problem and one basic possible solution have also been presented as part of the course.

Summary

All things considered I learnt a lot from this course, it let me understand some main concepts of robotics which I could reuse as part of my daily job, while working on autonomous driving.

The course doesn’t go deep into the details, but it teaches and presents the main ideas in a very efficient way. This brought me to the decision to do the Udacity Self Driving Cars course, but let me tell you more about that course later.

How I became a certified scrum developer

Introduction

Some weeks ago I attended a week long training session with the title “Certified scrum developer” (a.k.a LeSS in action), organized by the company Odd-e.

I regularly attend technical trainings in different fields, but I never wrote a blog post about them. Well, I wrote one with the title “How to do a proper technical training for developers”, but that post was the result of attending several trainings which I did not like.

This time the situation is different. I found this training really helpful and motivating. It had a clear effect on the way I'm thinking about agile software development, however there are still some points where I’m not absolutely convinced.

I’d like to summarize here what were the most important messages for me from this training.

And just to be honest: since the training I attended was not certified (even if its title was “Certified scrum developer”), I don’t have such a certificate, but it does not reduce the value of this training in my view.

The training

The training itself was very different from the trainings I attended before. The attendees have been split into four teams and each team had a workstation with huge monitors and computers (2-3 of such stations per team, each team had 5-6 members). Then during the week we simulated a sprint of working on a real product - an online game. We really worked day by day as teams in a large scaled scrum organization, and during these working days we had several sessions where we talked about dedicated topics. These sections were also reflecting on the situation in our sprint.

The first day was focusing on the refinement of the items. We did a nice refinement workshop, and we got a nice introduction into the methodology of specification by example and its connection to acceptance tests. We also did the sprint planning 1 where we decided on the items to be done by each team.

From the second day the teams really focused on the development. There was a CI system, which verified every new commit and notified all teams when something was broken. In this case one team  take over the “fix the build” responsibility. We were doing mob-programming, so usually 3 people were sitting in front of the same computer. There was a navigator of the mob session (who had the keyboard) and others who gave the instructions. The lead of the session has been changed regularly. We started every morning with a daily stand up and we evaluated the results of the day at the end of the day.

In case of any questions we were free to ask the product owner or even the customer. We also had to sync regularly with the other teams, since we had to touch the same code and implement similar functionality.

It was really exhausting, because the training was every day between 9 and 6 and it was really intensive. After the first day I almost lost my voice from speaking too much.

Although I've been working in a LeSS team for about a year (you can find my post about my first experiences and my later experiences part 1 and part 2), but this level of team work with continuous mob-programming was still something new for me.

The main topics of the sessions were: how to work in team and in pairs, how to do proper TDD, how to write good quality code, refactoring and how to do it, how does an agile organization look like, software architecture and design in agile development etc.

None of these topics were absolutely new for me, but they showed me these topics from a totally different perspective with very good practical examples, so I learned a lot.

Finally we closed the week with sprint review and a retrospective, where surprisingly most of the planned features worked properly.

The most important messages for me

First of all I have to clarify that I’m not a religious scrum believer. I started my career in an organization where we followed the classical V-model very strictly. There I have seen some advantages and a bit more disadvantages of that way of software development. Later on I worked in multiple projects which were following some kind of scrum organization, and as I have already mentioned, I'm currently working in a LeSS organization. Here I also see several advantages of the development process, but also some disadvantages. However, I have already realized that some of the disadvantages I observed were because of the wrong adaptation of scrum. So I think learning something new about agile development methodology can only help me. And to be honest this training helped a lot. Here I would mention some important points I learnt.

Proper way of specification by example

I already heard before about the idea of specification by example, but it was nice to apply it in practice. The high level idea is to describe concrete scenarios for your software with exact input and output data and use them as specification. To cover multiple cases (even the corner cases) you can organize the input values (and the expected output) into tables.

This way you can describe your requirements in a way which is well-readable by everyone, even for non-developers.

Additionally you can easily write automated tests based on these scenarios by using some acceptance test framework.

Taking a first bite

It is always a problem to refine and estimate tasks for topics which are absolutely new and unknown for the team. If we have no idea about the topic, how can we estimate it or how can we ask the right questions regarding the task?

The idea of taking a first bite is a solution for that. It means to first take something really small and easy from the topic, work on that and solve it. In the meanwhile you are becoming more familiar with the code base, so as a next step you can take over (and refine) a bit more complicated tasks with the same code. And keep on following this strategy until you are feeling comfortable with the code and topic.

How to do very proper TDD

TDD is a very popular buzzword nowadays. Basically the idea is to implement the code and the unit tests in parallel. But just like in the case of other popular buzzwords (SCRUM etc.) it is also pretty often misunderstood or misinterpreted.

The proper way of TDD is to always implement one test case (better to say, one check for your unit test), let it fail and then make it working in the code with the possible smallest change. Once it’s done you can do some refactoring to make your code nicer.

What is pretty strange for me is that you shouldn’t write more code than really needed. You really have to behave like you are being stupid.  For example if you are adding code where you know that you will have three different cases, you are not allowed to prepare your code for multiple cases as you are implementing the first one. It is absolutely against the way, how I usually work. I’m always thinking about what can be expected in the near future and implement my code to support these upcoming changes. It will still take some time to change this mindset.

The power of strong teamwork

I already realized before this training that teamwork is a really strong power. This training ensured me once again about this fact. I heard several times that pair programming is just a waste of resources, earlier I was not sure if it’s true or not, but now I’m sure that it’s not true. Simply the fact that we were doing mob programming all the time let us learn a lot and helped us to avoid making a lot of mistakes. And the flat communication channels also made it possible to detect issues in time.

However I have to mention that it is mentally really exhausting to work in such a way.

Software architecture in SCRUM/LeSS

There’s a really huge gap between the idea about software architecture in classical development models and agile models.

In case of classical development models software architecture is predefined, planned, well-documented and more or less static. Static in the sense that it should change as little as possible during the development.

In case of agile development there's usually a different practice. The architecture is not really planned, it just happens. It is just the actual state of the code and it is continuously changing. However there’s still a place to talk about the current architecture and to make architectural decisions.

The world is not always ideal

This was maybe the most important message for me.

The world is unfortunately not ideal. There are always issues which make it difficult to implement a proper scrum or to follow proper TDD. There can be thousands of reasons.

All these methods we learned about are working in an ideal world, but even if the situation is not optimal you should make the best of what is possible and try to optimize it.

Remaining open questions

There are some topics where I am still not totally convinced about scrum. Let's see those points.

How to apply scrum with less social developers

There are a lot of programmers who are not so good at communication and other social activities. For some of them that was the reason to become a programmer. But the world changed and soft skills became very important for developers. Especially in case of agile development models.

Of course these soft skills can be improved, but I think we can not expect wonder from developers who are not good at it at all.

I met a lot of developers who had very good technical knowledge, but they could not communicate with their team properly. What’s the future of these developers? How can they be integrated into Scrum teams?

Does it really make sense to avoid thinking about long term software architecture?

It is clear that software architecture is changing frequently together with the requirements. But there are  several cases when upcoming functionalities can be seen in advance. Does it really make sense to use a simpler solution and implement a more complicated one some sprints later if it is already known that the complicated one will be needed soon? At this point I’m still not totally convinced.

How to make sure that our unit testing is really done properly?

The way of TDD is to write test cases and to implement  related code and to keep doing it until we can not think about additional test cases. Well, but these test cases are really just up to us. How can we make sure that we really covered every corner case if our test cases are not connected to any kind of requirements? It is really easy to miss some points.

How to plan an agile project?

Well, agile projects are dynamic, flexible and open for changes.

However in case of projects the question is very often pretty simple from the customer: I need a software with this and this functionality: how long do you need to implement it and how much does it cost.

In case of classical project management both questions can be answered based on some estimations, however these estimations are not always proper.

But how to answer such questions in agiles modus?

Is pair programming always worth it?

I have already mentioned about the power of teamwork. One of the most common teamwork practices is pair programming. It really helps a lot, it makes the knowledge session much faster and it helps to improve the code quality. However there are tasks which are pretty easy, repetitive and even a bit boring and not challenging at all. I think there are such tasks in every big project. Is it really worth it to do pair programming for such tasks?

Final thoughts

I really liked the training. This was the most interactive training I have ever attended and I really appreciate it. From the content perspective it was nice to see a lot of things in practice, it helps much more than just reading about these topics.

It was really a pleasure to have hands-on experience with this way of working: strong teamwork, mob programming, TDD etc.

It was really active, so it is not possible to mention everything well-detailed in this post, but that was not my goal.

It clarified a lot of things for me, but I still did not become a religious scrum believer. I still see a lot of advantages of this working methodology, but it also has its own cons.