I agree with your assessment. The robot framework may not test these two completely for the reasons you state. But it will be an interesting test. I will eventually test this when I have some time.

When I was working on part six of week six, it wouldn't work so I spent a couple of hours rigging up a graphical thing to plot the maze, the smoothed path, and the estimate of the robot position. When I moved on to part seven, I added the robot's actual position to the display.

What I discovered was that the robot's position and the particle filter's estimate would be the same for a while and then they would diverge, never to meet again. I eventually concluded that the particle filter eventually got reduced to a single particle that matched the position of the robot fairly well, but once the particle loses track of the vehicles's position there's no way it can find it again because it's only got one place to pick from.

So, I went in and extended the particle filter by always introducing new particles and wound up with a system where the two positions were always much closer. It didn't work any better guiding the robot, but it didn't work any worse, either, and the estimates were much closer at the end of the goal

I'm kind of wondering if anyone has any interest in that code.

@JonathanG It sounds like you missed a couple of concepts in your particle filter implementation.

Remember that the measurement step is always supposed to select the same number of particles, so you will never run low. Some of the particles will be duplicates, but on the move step, each particle is projected with random error introduced, so there will no longer be duplicates.

If you get this right, you will never run low on particles, and you will never need to introduce new ones.

@JonathanG That's an interesting finding. I would not expect you to need to add particles like that for this application. If the random noise of the measurement step caused the measurements to jump outside the current range of particles, that's an indication that the Gaussian function used for applying the measurement to the particle filters did not correctly match the true Gaussian behavior of the measurement!

That is, when a measurement is applied it will not cause the paticles to all cluster into exactly one spot. They will form a Gaussian distribution around the measurement. How wide they all spread is a function of the assumed noise in the sensory signal. If the assumed noise is hard coded, but is too small, it will cause the particles to clump together too closely, and then a random measurement could do as you say, land so far away from the clump, that it takes the particle filter a long time to find the location again.

But if that happens, it is generally an indication that too small of a variance was hard coded into either the measurement, or the move steps. If we increase those values to be correct (we know what the real behavior of the measurement is since it's a simulation), then it should not have that tracking problem.

I'll have to look at the code and see if I can figure out what's happening there. Sebastian might not have "correctly" coded the particle filter to match the noise he coded into the measurements and movements.

And it will be interesting to try and test to see if in fact, the particle filter does lose track of the robot. I would like to plot a dot at each measurement number given to the filter and see where those land relative to the path the filter is returning.

BTW, looking at the estimated path the particle filter was producing (I plotted that as well), it did strike me that the path was far more chaotic and jagged than I expected it to be. I expected it should have produced a smoother path (even if the path was off track from the real location due to the noise in the data).

What I'm hearing is that I went to a lot of trouble to add a bunch of code that has the same effect as increasing the noise parameters that are labelled "don't change". So I created a modified version with an unmodified particle filter and I increased the noise parameters just for the particle filter. When I did that, it looks to me like the output of the particle filter looks matches the robot's position more closely than it did with the smaller noise parameters, even after the first big bend that the system has so much trouble with.

I still don't understand why the particle filter lost the robot on a lot of the runs I did with the smaller noise parameters and it didn't seem to have happened with anyone else. Luck of the draw, I guess. I can't get it to do it, now.

I double checked all the code to make sure it was calculating and processing measurements correctly and it is. If you set the noise low enough, you can see the filter actually lose the car. I had never seen that happen before. The result is funny (and surprised me) because the particle filter stays on track, where as the real car goes driving off into never never land. The program in effect is "driving" the particle filter around the track, while ignoring the real car!

Here's an example of what it looks like when the particle filter loses track of the car (and can't find it again due to a lack of particles in the right part of the state space):

http://s18.postimage.org/4nv6osf2h/lost_particle_filter.png

I set the measurement noise down to something like .03 to cause that.

I want to play some more with the particle filter, such as changing the number of particles, to see how that effects it's ability to track.