11

I am trying to fit more than one line to a list of points in 2D. My points are quite low in number (16 or 32).

These points are coming from a simulated environment of a robot with laser range finders attached to its side. If the points lie on a line it means that they detected a wall, if not, it means they detected an obstacle. I am trying to detect the walls and calculate their intersection, and for this I thought the best idea is to fit lines on the dataset.

Fitting one line to a set of points is not a problem, if we know all those points line on or around a line.

My problem is that I don't know how can I detect which sets of points should be classified for fitting on the same line and which should not be, for each line. Also, I don't even now the number of points on a line, while naturally it would be the best to detect the longest possible line segment.

How would you solve this problem? If I look at all the possibilities for example for groups of 5 points for all the 32 points then it gives 32 choose 5 = 201376 possibilities. I think it takes way too much time to try all the possibilities and try to fit a line to all 5-tuples.

So what would be a better algorithm what would run much faster? I could connect points within limit and create polylines. But even connecting the points is a hard task, as the edge distances change even within a single line.

Do you think it is possible to do some kind of Hough transform on a discrete dataset with such a low number of entries?

Note: if this problem is too hard to solve, I was thinking about using the order of the sensors and use it for filtering. This way the algorithm could be easier but if there is a small obstacle in front of a wall, it would distract the continuity of the line and thus break the wall into two halves.

sensors

hyperknot
  • 13,454
  • 24
  • 98
  • 153
  • How many lines would you expect for the example point set? I can "see" three walls: one on the left (4 pts), one on the bottom (6pts), and one on the right (3 pts). I can't decide whether the lowest point of the wall on the right also belongs to the bottom wall. I also can't decide whether the 2 points at the top form a wall, or the left one is part of the wall on the left, and the right one forms a wall with the point in the middle. Maybe the "connect points within limit and create polylines" method would work, but it is very hard to determine a proper limit for such a small point set. – kol Nov 19 '11 at 23:01
  • I could filter for at least 3 points on a wall. That would make this example have 3 walls. – hyperknot Nov 19 '11 at 23:18
  • Are these walls always either parallel or perpendicular to each other? – kol Nov 19 '11 at 23:23
  • Yes, it's a rectangular room. – hyperknot Nov 19 '11 at 23:27
  • @zsero Did you find any solution? this is what I was looking for – mudin Feb 17 '17 at 01:47

4 Answers4

6

A good way to find lines in noisy point data like this is to use RANSAC. Standard RANSAC usage is to pick the best hypothesis (=line in this case) but you can just as easy pick the best 2 or 4 lines given your data. Have a look at the example here: http://www.janeriksolem.net/2009/06/ransac-using-python.html Python code is available here http://www.scipy.org/Cookbook/RANSAC

2

The first thing I would point out is that you seem to be ignoring a vital aspect of the data, which is you know which sensors (or readings) are adjacent to each other. If you have N laser sensors you know where they are bolted to the robot and if you are rotating a sensor you know the order (and position) in which the measurements are taken. So, connecting points together to form a piecewise linear fit (polylines) should be trivial. Once you had these correspondances you could take each set of four points and determine if they can be modeled effectively by only 2 lines, or something.

Secondly, it's well known that finding a globally optimal fit for even two lines to an arbitrary set of points is NP-Hard as it can be reduced to k-means clustering, so I would not expect to find an efficient algorithm for this. When I used the Hough transform it was for finding corners based on pixel intensities, in theory it is probably applicable to this sort of problem but it is just an approximation and it is probably going to take a fair bit of work to figure out and implement.

I hate to suggest it but it seems like you might benefit by looking at the problem in a slightly different way. When I was working in autonomous navigation with a laser range finder we solved this problem by discretizing the space into an occupancy grid, which is the default approach. Of course, this just assumes the walls are just another object, which is not a particularly outrageous idea IMO. Beyond that, can you assume you have a map of the walls and you are just trying to find the obstacles and localize (find the pose of) the robot? If so, there are a large number of papers and tech reports on this problem.

fairidox
  • 3,358
  • 2
  • 28
  • 29
  • Do you think I should use SLAM? I know the dimensions of the room and that it is rectangular. Also, I could attach a virtual 1D LIDAR to the virtual robot. What do you think I should use in this case? – hyperknot Nov 20 '11 at 00:18
  • So if you know the room is rectangular and you have the dimensions you have a map. Once you have a map you can determine the position of the robot in a whole host of ways, the most common being the Kalman filter or Monte Carlo Localization (particle filter). Just check out the standard textbook for the details on this: (http://www.probabilistic-robotics.org/). Once you have the robot position relative to the walls you can detect obstacles by finding which points do not match the map. – fairidox Nov 20 '11 at 00:28
  • Also, SLAM is a generic term for algorithms that do localization without a map, and they can be very complex. Since you do have a map I would not suggest going that way. – fairidox Nov 20 '11 at 00:28
  • "finding a globally optimal fit for even two lines to an arbitrary set of points is NP-Hard as it can be reduced to k-means clustering" - Can you please explain your reasoning? It is not obvious to me what reduction you have in mind, nor specifically which formulation of k-means clustering you are reducing to. Also, do you mean "reduced from"? – D.W. Jul 02 '23 at 22:23
1

A part of the solution could be (it's where I would start) to investigate the robot. Questions such as:

  1. How fast is the robot turning/moving?
  2. At what interval is the robot shooting the laser?
  3. Where was the robot and what was its orientation when a point was found?

The answers to these questions might help you better than trying to find some algorithm that relies on the points only. Especially when there are so very few.

The answers to these questions give you more information/points. E.g., if you know the robot was at a specific position when it detected a point, there are no points in between the position of the robot and the detected point. that is very valuable.

Emond
  • 50,210
  • 11
  • 84
  • 115
  • The problem is that all the sensors have a lot of noise (even in the simulated world), as well as the wheel encoders couldn't really be used for tracking exactly how much it has traveled / rotated. I am trying to get the corners because then I would have a set of fixed points in the room. – hyperknot Nov 19 '11 at 23:31
  • The main thing about my answer is that you should use every bit/byte of information you have. Including the noise, any knowledge about the shape of the room. If there is so much noise you will never be certain; in fact, you won't even be able to steer the robot or know its position based on the data. – Emond Nov 20 '11 at 06:46
1

For all the triads, fit a line through them and compute how much the line is deviating or not from the points.

Then use only the good (little-deviating) triads and merge them if they have two points at common, and the grow the sets by appending all triads that have (at least) two points in the set.

As the last step you can ditch the triads that haven't been merged with any other but have some common element with result set of at least 4 elements (to get away with crossing lines) but keep those triads that did not merge with anyone but does not have any element in common with sets (this would yield three points on the right side of your example as one of the lines).

I presume this would find the left line and bottom line in the second step, and the right line the third.

  • If the "line" is a slight curve, this process finds that curve as well. It is a question if it is beneficial for you or not. If not, you can do some more tests during merging. –  Nov 19 '11 at 22:56
  • As for "where to begin", I think you should merge two triads that result in shortest and straightest line (play with parameters how to build the score from these two properties as you cannot guarantee you will have them both at the first place), and then merge to this set until you cannot more and then repeat the process with the left triads. –  Nov 19 '11 at 23:04
  • My problem is that I'm not sure it's not too computationally intensive. Testing all those thousands of possibilities in MATLAB might not be an option for fast operation. – hyperknot Nov 19 '11 at 23:22
  • This should be O(n^3), is it too much (maybe more, but I think it could be polynomial anyway)? And of course, you should prune... I said the first step is to prune all not-good-enough triads. Maybe try it and you'll see how it performs. –  Nov 19 '11 at 23:23
  • I don't know I feel like in MATLAB this couldn't run in real time. In C++ maybe, as the computation is quite easy. I think maybe Hough transform could be a better choice. – hyperknot Nov 19 '11 at 23:29
  • If you fear about the performance, make some variants of it... like not to compute triads before, but start with two nearest points and adding point-by-point until it is still reasonably straight. This should be faster (but trickier than with triads, I think; where to continue if two two points I used proved to be a failure; problems can arise if I remove all pints since big lines could be crossing but the crossing point vanished...) –  Nov 19 '11 at 23:30