This is a pointer that's a bit buried. For all the fanciness of different particle filtering algorithms, you are likely not using enough particles. Unless you having troubles related to running out of memory consider using more particles. Even doing fancier things like rejuvenation and stratified sampling benefit from more particles.
Ive never found a practical implementation of particle filters that was deployed on a real system. PF are a poor choice for tracking a solution that does not have wildly divergent measurements that can cause "lost robot" types of situations. Even then, PF is a fine temporary and high cost stopgap to converge to a "filterable" solution with only one predominant mode / a tight cluster of oarticles. At that point, a closed form approximate filter makes better sense in terms of cpu cost, memory, etc. Save the memory for feature maps and the CPU cost for iterations or at worst a few extra hypotheses on your primary filter.
As you say, measurements with multimodal error, but also measurements with horribly non linear observation or time models. It has to be pretty bad though, otherwise a UKF would be better.
For those not familiar, UKF = unscented Kalman filter. And by the way, there is no such thing as "scented" KF. The inventor of the UKF, whose name was Jeff Uhlmann, didn't want this method to be called after his name, so he picked a random word in the dictionary.
UKF is, in my mind, a principled version of the particle filter. Its a really clean way of operating and I cant emphasize enough the power of explicitly conditioning on decision variables, i.e. multi hypothesis formulations of UKF, EKF, or even Batch filters, all of which require orders of magnitude less CPU / mem.
(e.g. I'm not sure about this echo or that, so I'll propegate explicitly conditioned on those unknowns two reasonable hypotheses that are effectively unimodal rather than sampling the entire posterior probability space). The exponential set of probabilities then allows you to take action to remove hypotheses or trim by weight. And, this is only required when you encounter huge uncertainties nonlinearities or multimodalities, so it is explicitly adaptive to the situation. I've never seen a sampling or reweighting strategy that provides a decent job of this. PF is throwing CPU and memory at the problem, and it does reasonably well but for anything Ive worked on or dug into, the CPU and Memory is alwayd better used elsewhere in the system.
Agreed, by using PF you are throwing your hands up and admitting you have no idea how to model your observations. If you can correctly model any aspect of the problem that will be both better performing and more efficient. I use PF to help me figure out a distribution mostly. Even UKF is usually overkill for me. Anything less than 2n+1 sigma points gets beat by a 1st order ekf.
It’s definitely a high cost implementation but it’s worked well as a brute force solution for multiple non linear measurements like multiple cameras + sonar etc.
I can't quite understand from this post what a particle filter is or what the project is. Is this a simulation of a robot using sensor readings to estimate its position in a maze? How are particles emitted, and how does the sensor measure them? What does the "probability" of a particle mean? Does it combine any information about its previous position estimate? And how would this be applied in the real world without a perfect model of the environment?
> Is this a simulation of a robot using sensor readings to estimate its position in a maze?
Yes.
> How are particles emitted, and how does the sensor measure them?
I think I understand your question, and there might be a misunderstanding here. The "particles" are not emitted in traditional sense. They are merely records in an internal data structure inside the robot's head.
The problem: Your robot has a map of the scene, but doesn't know where it is. You have distance measuring sensors on four sides of the robot, but they can't see enough details to say where you are on the map.
What the "particle filter" aproach suggest is that you keep a list of hypothesises of where the robot might be. Each hypothesis is a full parameterisation (x, y, heading in 2d), and for historical reasons we call them "particles".
At the beginning you initialise a bunch of these "particles" with random x, y, h values. Then in a loop you take measurements with the sensors and calculate how plausible each hypothesis is.
Maybe all your sensors can tell you is that there are walls a meter away at the rear and to the sided but there is 3m free space forward.
This would make the "particles" which are in the middle of a big room very unlikely while any particle which puts you in a cull-the-sack heading out would be more likely.
Next you would like to keep the more likely hypothesises while rejecting the least likely ones. What the "particle filter" approach suggest is that you
re-sample your particles such a way that the probability of keeping a particle equals with their calculated "plausibility".
In the next step you move with your robot using your motors. Usually you don't have perfect actuation, but you have a probabilistic idea of how much you might have traveled. You then update each particle by some movement sampled from that probabilistic motion model. After that repeat from the sensing step.
What usually happens is that after a few iterations all the particles collapse to a few well localised spots on the map. Very frequently to a single spot and that means that the "kidnapped" robot has localised itself. This happens because given enough data all the implausible theories can be eliminated and what remains is where you are.
> What does the "probability" of a particle mean?
It gives a measure of how well the location represented by the particle (a particular theory) fits with the last sensor measurements.
> Does it combine any information about its previous position estimate?
Indirectly. The re-sampling step guarantees that the particle is there because it was at least somewhat plausible in the past, but you don't have to keep an ever growing history explicitly.
> And how would this be applied in the real world without a perfect model of the environment?
You need some model of the environment (an occupancy map for example) but it doesn't need to be perfect. Since everything is already probabilistic, you can have a probabilistic map. Changes of how you calculate the plausibility (probability) of a given hypothesis (particle) but doesn't change the whole algorithm.
About how it is applied in the real world... well I will be frank with you I have seen many robots localise in different ways and neither of them used particle filters. Maybe we were all missing out on something cool. :) Thrun et al. describe in Probabilistic Robotics as something which were useful for them in the past.
So you have that.
The term "monte carlo methods" in statistics/probability bothers me, since it literally just means trying out, or simulating. I can't help but think someone started using it to just sound smart. Such shenanigans seem make science harder to grasp especially for newcomers, so I think it would be better to keep naming simple and obvious where possible. There are enough topics that are too abstract, so it can't be done there.
Simulating is an incredibly hard problem and MC methods and theory is an incredibly rich area of study. Some tools I use for my work in probabilistic machine learning models are MCMC techniques like HMC (Hamiltonian Monte Carlo), variance reduction techniques (Rao Blackwellization). If you would like to learn more, here is a great course: https://statweb.stanford.edu/~owen/mc/ -- you can take a look at the syllabus. Also, Casella Berger is a standard MC method book.
The alternative would be calling it something like stochastic methods, which would probably be even more confusing. Monte Carlo is a convenient term to make it clear the stochastic part is in the method itself, and not in the measurements or the modeled system.
I don't think there's universal agreement about terminology, but to many of us who work in the area, Monte Carlo (MC) means specifically using random sampling to estimate a deterministic quantity. For example, MC methods can be used to compute the ground state energy of atoms and molecules. This in principle can also be done by solving the many-body Schroedinger equation, but direct numerical solution is simply not feasiable except for systems with very few degrees of freedom. In contrast, the term "simulation" often (but not always) means to simulate to take a look.
As is usual with these things, the boundary is not sharp. One selling point of sampling is that with greater expense you also get more information about the "energy landscape," can do uncertainty quantification, etc.
19 comments
[ 2.8 ms ] story [ 56.7 ms ] thread[1] https://en.wikipedia.org/wiki/Unscented_transform
(e.g. I'm not sure about this echo or that, so I'll propegate explicitly conditioned on those unknowns two reasonable hypotheses that are effectively unimodal rather than sampling the entire posterior probability space). The exponential set of probabilities then allows you to take action to remove hypotheses or trim by weight. And, this is only required when you encounter huge uncertainties nonlinearities or multimodalities, so it is explicitly adaptive to the situation. I've never seen a sampling or reweighting strategy that provides a decent job of this. PF is throwing CPU and memory at the problem, and it does reasonably well but for anything Ive worked on or dug into, the CPU and Memory is alwayd better used elsewhere in the system.
Also, an economist I dated for a bit used particle filter in her research.
Yes.
> How are particles emitted, and how does the sensor measure them?
I think I understand your question, and there might be a misunderstanding here. The "particles" are not emitted in traditional sense. They are merely records in an internal data structure inside the robot's head.
The problem: Your robot has a map of the scene, but doesn't know where it is. You have distance measuring sensors on four sides of the robot, but they can't see enough details to say where you are on the map.
What the "particle filter" aproach suggest is that you keep a list of hypothesises of where the robot might be. Each hypothesis is a full parameterisation (x, y, heading in 2d), and for historical reasons we call them "particles".
At the beginning you initialise a bunch of these "particles" with random x, y, h values. Then in a loop you take measurements with the sensors and calculate how plausible each hypothesis is.
Maybe all your sensors can tell you is that there are walls a meter away at the rear and to the sided but there is 3m free space forward. This would make the "particles" which are in the middle of a big room very unlikely while any particle which puts you in a cull-the-sack heading out would be more likely.
Next you would like to keep the more likely hypothesises while rejecting the least likely ones. What the "particle filter" approach suggest is that you re-sample your particles such a way that the probability of keeping a particle equals with their calculated "plausibility".
In the next step you move with your robot using your motors. Usually you don't have perfect actuation, but you have a probabilistic idea of how much you might have traveled. You then update each particle by some movement sampled from that probabilistic motion model. After that repeat from the sensing step.
What usually happens is that after a few iterations all the particles collapse to a few well localised spots on the map. Very frequently to a single spot and that means that the "kidnapped" robot has localised itself. This happens because given enough data all the implausible theories can be eliminated and what remains is where you are.
> What does the "probability" of a particle mean?
It gives a measure of how well the location represented by the particle (a particular theory) fits with the last sensor measurements.
> Does it combine any information about its previous position estimate?
Indirectly. The re-sampling step guarantees that the particle is there because it was at least somewhat plausible in the past, but you don't have to keep an ever growing history explicitly.
> And how would this be applied in the real world without a perfect model of the environment?
You need some model of the environment (an occupancy map for example) but it doesn't need to be perfect. Since everything is already probabilistic, you can have a probabilistic map. Changes of how you calculate the plausibility (probability) of a given hypothesis (particle) but doesn't change the whole algorithm.
About how it is applied in the real world... well I will be frank with you I have seen many robots localise in different ways and neither of them used particle filters. Maybe we were all missing out on something cool. :) Thrun et al. describe in Probabilistic Robotics as something which were useful for them in the past. So you have that.
this statement trivializes a very hard problem.
> literally just means trying out, or simulating
Simulating is an incredibly hard problem and MC methods and theory is an incredibly rich area of study. Some tools I use for my work in probabilistic machine learning models are MCMC techniques like HMC (Hamiltonian Monte Carlo), variance reduction techniques (Rao Blackwellization). If you would like to learn more, here is a great course: https://statweb.stanford.edu/~owen/mc/ -- you can take a look at the syllabus. Also, Casella Berger is a standard MC method book.
As is usual with these things, the boundary is not sharp. One selling point of sampling is that with greater expense you also get more information about the "energy landscape," can do uncertainty quantification, etc.
It’s a beautiful piece of math history.