- Safety first: we have to keep an eye on our environment to make sure we react appropriately to other cars
- Fast: within legal limits, overtake other cars if necessary
- Comfortable: passengers should be comfortable with the acceleration and jerk, our trajectory planner should keep these variables under certain limits

We have at our disposal information about our position and our environment (data about other vehicles in our direction). We provide the simulator a list of coordinates to be visited at regular intervals (Thus also speeds and accelerations).

The project boils down to solving three problems:

- Behaviour planner: take decisions about changing lanes and determine maximum speeds.
- Trajectory planner: based on the directives from the behaviour planner, create a good trajectory that respects all constraints.
- Interface with the simulator: there are some artificial difficulties which arise from the clunky interface to the simulator, i.e. faulty coordinate conversions.

This was one of the coolest parts of the course, since it is in this project that we can really shape the way the car interacts with its environment. Below a video showing my results:

The report I submitted:

https://github.com/hectorratia/CarND-Path-Planning-Project/blob/master/README.md

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-Path-Planning-Project

The inputs to the MPC are:

- Waypoints, approximated by a third degree polynomial.
- Car status: position, orientation, speed, and current state of the actuators

MPC uses a model to predict future states based on actuators input and tries to find a series of actuators inputs which minimizes a cost function. The model can be kinematic or dynamic, but I used a simple kinematic model for this project. The selection of MPC parameters and cost function are key to having a capable and stable controller. The cost function I defined is based on factors such as:

- Reduce position and orientation error w.r.t. the waypoints trajectory
- Keep a reference speed
- Reduce actuator use
- Reduce actuator derivatives, i.e. no sudden changes

The optimizer (a C++ library) is fed the discretized kinematic equations, constraints and the cost function. It is important to balance the number of steps and the time step for good and timely performance.

I tuned the cost function for the MPC to be able to drive up to 80mph. Video performance below. Yellow line in the video are waypoints, green line is the solution from the MPC.

It is nice to explore another “simple” controller which can safely drive the car (in the simulator at least!) but it also showcases the need of self-driving cars to integrate several systems into one coordinated unit. This method is dependant on dynamic information (Waypoints) and it disregards most of its environment. I hope part 3 of the self-driving car nanodegree will feature some kind of “integration” scenario where different systems have to be combined to give the car some autonomy, rather than mere automation.

The controller driving ~65mph:

The controller driving ~80mph:

The report I submitted:

https://github.com/hectorratia/CarND-MPC-Project/blob/master/REPORT.md

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-MPC-Project

- cross track error: how far the car is from the circuit

- orientation error: the angle between the car’s orientation and the tangent to the path.

The mission for our controller is to give steering and throttle commands to drive safely and as fast as possible around the circuit.

Implementing the PID controller is straightforward, tuning its gains however is not and can get very tedious.

I programmed the twiddle algorithm to tune the gains for me. Twiddle is an algorithm that alters the parameter by a small amount each iteration, and checks if the error is smaller. If that is the case, it will change the parameter by a bigger amount the next time. If not, it will reduce the amount of change. It will iterate over the parameters making a couple trials for each of them, ad infinitum. This is easy to program and can find a local optimum.

Since the controller behaves differently depending on the speed, I first trained it on a speed function which set low speeds, and then gradually increased the speed.

The speed function is basically an on-off controller coupled to a “desired speed” function. The “desired speed” is selected in linear dependence of the cross track error like this:

The speed stays constant for CTE greater than 2, so that the car keeps moving even when it has deviated from the path.

The algorithm to train the PID is like this:

The resulting controller in action:

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-PID-Control-Project

Particle filters are very intuitive and easy to implement. The drawback is speed and, I guess, difficulty to use in real situations. In a real life implementation it would be necessary to decide what is a landmark and to be able to tell if the feedback form the sensors corresponds to a landmark in the map or not.

This video shows the performance of the filter within the simulator provided by Udacity:

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-Kidnapped-Vehicle-Project

Here is the action:

The algorithm I devised is something like this:

Point in the general direction of the other car

If we are confident about our predictive abilities (Coefficients of covariance matrix are small)

Try the following for time intervals starting from 0.1 seconds to 5 seconds, increasing them by 0.05 seconds each time

Predict the position of the other car after this time interval

Check how far it will be from our current position

If we are able to reach it in time with our max speed or less, set course!

As with many other projects, it is easy to get stuck on the little details. For me in this project the problem was passing the heading and speed to the simulator. I guess the simulator is using some crude controller to implement the commands, which results in unprecise controls. This situation is aggravated by the time lags between command inputs. I solved this by implementing a kind of proportional control. While I calculate the exact values for heading and speed, I pass them multiplied by a small value to the simulator. This results in a smooth control which catches the car in the first try.

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-Catch-Run-Away-Car-UKF.git

This table shows the comparison between Unscented using one or two sensors and Extended using two sensors:

Using the Unscented filter required to tune two parameters, the process noises standard deviations of linear and angular acceleration. To guide us in the process we calculated Normalized Innovation Squared values and compared them with the 95% confidence of the corresponding Chi Square distribution. This is the result for the final tuned version of my project:

This video shows the performance of the Unscented Kalman Filter in the same task we used to evaluate the Extended one:

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-Unscented-Kalman-Filter-Project.git

]]>

The filter performs sensor fusion of Radar and Lidar data, using a non-linear model for the update of radar data. In the video below, radar and lidar data is represented by red and blue dots. The predictions of the filter are shown as green dots.

It was a relatively easy project, since Udacity gave all the framework required for the programming task. Nonetheless, a good warm up for the more advanced topics this term.

The code for my project is hosted in github:

https://github.com/hectorratia/CarND-Extended-Kalman-Filter-Project