Wikipedia:Peer review/Monte Carlo localization/archive1

Monte Carlo localization

This peer review discussion has been closed.
I've listed this article for peer review because I have recently rewritten the article and spent a lot of time creating new diagrams that will hopefully convey the concepts effectively. I am still relatively new to writing articles and would like some feedback on how to improve.

Thanks, dllu (t,c) 10:01, 25 March 2013 (UTC)

Comments by Garamond Lethe

 Doing... I'll be taking a look at the article over the weekend and expect to have a mostly-complete set of comments by Tuesday. Garamond Lethet
c 06:21, 12 April 2013 (UTC)

First Impressions

0. Overall a solid article on an interesting topic. This article is certainly worth a close review. My suggestions are just that: if you disagree, that's fine. If you have question or want to discuss a point I'm happy to do so.

Lead

1. The lead is a little citation-heavy. My personal preference is to not use cites at all in the lead unless absolutely necessary; WP:LEADCITE is a bit more flexible.

Thanks for bringing that to my attention. I will rewrite the lead when I have time. dllu (t,c) 04:04, 14 April 2013 (UTC)

2. I'd like to see a sentence in the lead that establishes why robot localization is a hard problem. While the lead does an excellent job describing what MCL is, not enough context is provided. Is the algorithm used mostly for fixed industrial robots? "Untethered" robots like roomba and its military kin?

It can theoretically be used for almost any robot that moves, I think. I suppose I can say something about robot localization is a nontrivial problem, but if I make it sound too hard then it might drive readers away. dllu (t,c) 04:04, 14 April 2013 (UTC)

3. I think mentioning recursive Bayesian estimation in the lead goes into too much detail. Save that for the body of the article.

OK, I will move it somewhere else when rewriting the lead section. dllu (t,c) 04:04, 14 April 2013 (UTC)

History and Context

4. The biggest hole in the article is the absence of a "History and Context" section (hopefully you can come up with a better section title). What problem does this algorithm try to solve? When and how did the problem arise? What other approaches were used before this algorithm? What has superseded it, if anything? Where is it being used now? This really needs to be addressed if you want to take the article to WP:GA.

Good point. I will do some research about the history of the algorithm and how it came into existence. dllu (t,c) 04:04, 14 April 2013 (UTC)

State representation

5. Since you're an expert, you know what you mean by "state space". Your reader likely doesn't (including this reader, who used to make his living doing laboratory robotics). Is a particle just an (x,y,z) triple? A set of triples that correspond to beliefs about the locations of all the robot's components? All components of interest, even if they aren't attached to the robot? Basically, what does a "state hypothesis" look like? (I'm not asking for the mathematical representation: tell me what it is.)

For a 2D robot, a particle is typically an (x, y, theta) tuple (c.f. struct particle in the code used to generate File:Particle2dmotion.svg). For a 3D robot, a particle is typically (x, y, z, theta, phi, psi). For the 1D robot in a corridor, a particle is simply (x) -- its position. As you may imagine, the state space varies widely for different kinds of robot. For example, a robotic arm with 10 joins might have a state space that's all of the angles at the joints $(\theta _{1},\theta _{2},\theta _{3},...,\theta _{10})$. In the interest of making the article as general as possible, it is difficult to define what the state space is. Perhaps I can give some examples though (like explicitly stating what the state space of the 1D robot example is). dllu (t,c) 04:04, 14 April 2013 (UTC)

6. It's not clear to me why the algorithm has to be time-invariant (other than convenience).

It relies on an internal map and if the map is always changing, it won't work. The algorithm assumes that the future of the robot depends only on its current state and not, say, what time of day it is, or how long it took to get into its state, or what path it took to get into its state. For example, if what path it took to get to its current state mattered, it would imply that it is changing its environment (e.g. like a snail leaving a slimy trail) or that the environment changes with time and then things would get horribly annoying. An algorithm that keeps a full history of previous states will become slower and slower as time passes. And yes, the reason why we assume the Markov property is for convenience and simplicity. In any case Markov localization algorithms like this are quite robust. dllu (t,c) 04:04, 14 April 2013 (UTC)

7. "Typically, on start up, the robot has no information on its current pose...." That bit of context is hugely helpful and needs to occur much earlier in the article.

It's not always the case though. Sometimes the robot starts up already knowing where it is. Maybe I will say something like, "If, on start up, the robot has no information on its current pose..." dllu (t,c) 04:04, 14 April 2013 (UTC)

Overview of algorithm

8. Perhaps "Overview of the algorithm".

Since the article is all about the algorithm, I changed it to just "Overview". dllu (t,c) 04:04, 14 April 2013 (UTC)

9. Should it be "pose" or "position"? If "pose", could you explain that this is a term of art and what it implies?

It's a term of art (i.e. jargon) that includes both position and orientation. I have now linked the term to the article on pose so hopefully it will be cleared up. dllu (t,c) 04:04, 14 April 2013 (UTC)

10. Can the u_t actuation be optional (or a no-op)? For the robots I worked on, moving when you didn't quite know where you were yet was usually a bad idea.

Yes, sensing without actuation works but it may result in particle deprivation as discussed later. Perhaps I should do more research on this to find out how people deal with localization when the current belief is very poor. dllu (t,c) 04:04, 14 April 2013 (UTC)

11. Second line of the algorithm: This really looks like X_t gets assigned the null value twice. It wasn't until I looked very closely that I saw the bar over the first X. Not sure what you can do about this, but it is confusing.

In the textbook the author uses ${\text{bel}}$ and ${\bar {\text{bel}}}$, but here I used $X$ and ${\bar {X}}$ for consistency. Perhaps I can change ${\bar {X}}$ to $Y$. It's only a temporary variable so it shouldn't really matter. dllu (t,c) 04:04, 14 April 2013 (UTC)

12. Define M in this section so I don't have to go looking for the definition elsewhere. Since M isn't an integer, you might forestall a few pedants (who, me?) by using the construction |M|.

$M$ is the number of particles. I can probably restate that or add a comment in the pseudocode... dllu (t,c) 04:04, 14 April 2013 (UTC)

13. \bar{X} is never read.

In the line "draw $i$" it's drawing from ${\bar {X}}$; but you're right, I forgot to explicitly state that. I fixed that hopefully now. dllu (t,c) 04:04, 14 April 2013 (UTC)

14. I can guess what motion_update is doing with the previous timestep's particles and current timestep's actuation command.... well, no, I can't. What's going on here? (While I'm thinking about it, "actuation" is another term of art that probably could use a definition.)

Actuation just refers to an action, i.e. a movement or motion, that the robot does. The motion update moves all the particles in the same motion that the robot intends to do. I will think about how to better explain it. dllu (t,c) 04:04, 14 April 2013 (UTC)

15. Shouldn't the sensor update be operating on x_{t-1}^{[m]} instead of x_{t}^{[m]}?

Nope, it's operating on the output of the motion update. dllu (t,c) 04:04, 14 April 2013 (UTC)

16. Since I don't understand how the probabilities changed above, I don't understand why the draw would be different.

The particles, having been moved by the motion update, now each have a different probability than before to produce the observed sensor reading. dllu (t,c) 04:04, 14 April 2013 (UTC)

17. I really like the diagrams. However, it's not obvious if they are to be read from top to bottom or from left to right. The t=0, t=1, .... didn't help enough. Could you either label each diagram with a, b, c... (each one getting a unique letter) or find a way to group the three related graphs visually (each set gets contained within a rectangle with a background color unique to each timestep?).

They are meant to be read from left to right. I will think of a way to group them together. dllu (t,c) 04:04, 14 April 2013 (UTC)

18. I didn't realize that the small brown rectangles were doors. Could you add a legend at the top of this figure?

Sure. I had hoped the doorknob would make them obvious, but then I can see why it would be confusing. dllu (t,c) 04:04, 14 April 2013 (UTC)

19. t=0 (b) shows the robot detecting two doors, right? Oh, wait, there are three doors. That wasn't clear at all. I thought the robot was a blue box with a brown outline.

It seems easier to explain the algorithm if the robot already starts at a door (otherwise, like the t=1 step, it doesn't help quite as much to detect an empty wall)... but I will try to think about a way to resolve this source of confusion. dllu (t,c) 04:04, 14 April 2013 (UTC)

20. t=1 (a) "All the particles are moved to the right". Did the robot move a random distance to the right, or a distance calculated to disambiguate the doors?

It's a distance arbitrarily chosen here for educational purposes. This algorithm is a passive localization algorithm, so it just finds out where the robot is but doesn't actually decide where the robot ought to go next. I will try to explain this better in the article. dllu (t,c) 04:04, 14 April 2013 (UTC)

21. t=1 (c) "It now believes it is at one of two doors." Which? I think the point of the example is that by using this algorithm the robot is disambiguating where it is in reference to the doors, but this isn't coming across in the diagram.

I agree that this part is confusing. The idea is that, if you look at the distribution of particles in the diagram, one of the clumps of particles has been mostly destroyed so there are only two clumps left. Also, the phrasing was bad... neither of the two clumps are at a door. dllu (t,c) 04:04, 14 April 2013 (UTC)

Motion update

22. Perhaps move this and the sensor update section ahead of the algorithm section?

That could work, I suppose. If the motion update and sensor update subroutines were moved ahead the algorithm section, then the reader may be confused about what the role of these two subroutines are. I will think more about this... dllu (t,c) 04:04, 14 April 2013 (UTC)

23. The figure is really interesting, but how does the probability function become more dense in the absence of sensor information?

It doesn't. In order for the probability distribution to become more dense, the only way is for it to sense the environment. dllu (t,c) 04:04, 14 April 2013 (UTC)

Sensor update

24. Ok.

I can maybe make a picture for this part too. dllu (t,c) 04:04, 14 April 2013 (UTC)

Properties

25. This section contains a lot of helpful context that would have been useful earlier in the article. You might want to consider placing this information earlier in the article.

Good idea, I should move some of the main properties into the lead section. dllu (t,c) 04:04, 14 April 2013 (UTC)

References

26. The technical report may raise a red flag at the GA review. On the other hand, it has been cited 146 times, so it's probably fine.

27. Again, not an issue unless you go up for GA, but you appear to be relying too much on the MIT book. Removing some of the cites from the lead will help, as will broadening the article by adding more context. There are plenty of articles out there—should you definitely consider citing several more sources.

Agreed, I will do a more comprehensive literature review and add some different sources when I have time. As you have noticed, most of the sources are from the same 4 guys (Thrun, Fox, Burgard, Dellaert) and as a rule of thumb it's always better to have variety in sources. dllu (t,c) 04:04, 14 April 2013 (UTC)

Overall

28. This is a nontrivial article to write and I think you're pretty close to having a GA candidate. For the next iteration of the diagram, you might want to grab a couple of Computer Science undergraduates (or even just folks who know how to program but don't know robotics) and have them read the article and explain what they think is going on. Getting the diagrams right will be the most difficult thing to accomplish here, but when you do this will be a very useful article.

I have shown the diagrams to User:Stigmatella aurantiaca, who has also identified some points of confusion in the diagrams and article text. I am actually myself an undergraduate (of Engineering). I'll show it to some of my classmates, but they are all having final exams now. The diagrams are inspired by Figure 5.10 and Figure 8.11 from Probabilistic Robotics textbook diagrams. dllu (t,c) 04:04, 14 April 2013 (UTC)

29. The writing was quite good. I personally don't like exclamation points in articles, but you've kept that too a minimum here so I won't quibble.

I removed the single use of exclamation mark. Exclamation marks do seem to make the article seem less serious. dllu (t,c) 04:04, 14 April 2013 (UTC)

30. Nice use of code+diagrams+graph.

Thanks. dllu (t,c) 04:04, 14 April 2013 (UTC)

31. Wikification done particularly well.

Thanks. dllu (t,c) 04:04, 14 April 2013 (UTC)

32. Nice work!

Thanks for taking the time to review! I look forward to any other comments you have. Since I have several final exams this week, I will not be able to work on new diagrams or any significant amount of writing until April 23 or so. dllu (t,c) 04:04, 14 April 2013 (UTC)

Garamond Lethet
c 07:41, 12 April 2013 (UTC)