Extracting a single line

[SebasPeters]

Hi!

I'm using your algorithm to detect lines in a factory environment for a graduation project on robotics. The code works very nice, so my compliments for that! Nevertheless, one problem I have is that I cannot seem to detect a line when only one line is present in the laserscan data. Can you advise me on which settings to change or where to adapt the code?

Best,
Sebas

[kam3k]

That's an interesting issue. Let's start by looking at some of the parameters in the launch file that could cause the problem:

max_line_gap: Lines may not be detected if the points in the line are spread out too far.
min_line_length: Is the line that isn't being detected shorter than this?
min_line_points: Does the line that isn't being detected have more points than this?
min_range: Are the points making up the line closer to than this?
min_split_dist: Are the points in the line further apart than this?

Note that a combination of settings may be the cause. When you look at the raw scan, there may appear to be enough points. But after the points have been filtered (e.g., outliers, min range), there may be less points left to create the line, perhaps less than min_line_points.

If you can't seem to resolve the problem by adjusting parameters, would it be possible to provide me a bag and launch file, and tell me where to look for the problem? If I can recreate the issue, it will be easier to track down.

Also, I haven't worked on this code in about three years, so bare with me if it takes me some time to get caught up on how things work!

[SebasPeters]

Thanks for your quick response! This afternoon I figured out a solution for the problem. I found that the laserscan readings I was using gave 'Inf' for ranges outside the max range of my laser scanner. By replacing these values to a numeric value the algorithm can now segment the observed line from the background and find a fit through some background lines, as well as the line I'm interested in. As I'm only interested in line segments within a range of about 3 meter, it works fine for me now! Somehow the algorithm seems to need more than one line to make a fit through. I played around with the parameters you mentioned and it worked perfectly as long as there were multiple lines visible. However, as soon as I removed other objects from the view my 'desired' line was not extracted anymore. Nevertheless, I'm happy it works fine now! Thanks for your good work!

…

On 11/07/2017, Marc Gallant ***@***.***> wrote: That's an interesting issue. Let's start by looking at some of the parameters in the launch file that could cause the problem: max_line_gap: Lines may not be detected if the points in the line are spread out too far. min_line_length: Is the line that isn't being detected shorter than this? min_line_points: Does the line that isn't being detected have more points than this? min_range: Are the points making up the line closer to than this? min_split_dist: Are the points in the line further apart than this? Note that a combination of settings may be the cause. When you look at the raw scan, there may appear to be enough points. But after the points have been filtered (e.g., outliers, min range), there may be less points left to create the line, perhaps less than min_line_points. If you can't seem to resolve the problem by adjusting parameters, would it be possible to provide me a bag and launch file, and tell me where to look for the problem? If I can recreate the issue, it will be easier to track down. Also, I haven't worked on this code in about three years, so bare with me if it takes me some time to get caught up on how things work! -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #1 (comment)

[kam3k]

Alright, good to hear it is working satisfactorily for you. I'll leave this ticket open because it sounds like there may still be an issue.

[SebasPeters]

Hi Lin, The code is not originally mine, but I applied an adapted version in my project as well. In the beginning I also had some problems as well. In my case the algorithm didn't appear to work in case there was only one visible line in the 2D-lidar image. I solved this problem by hardcoding a background in the 2d lidar image, such that 'infinite' range measurements don't dissapear but are simply represented by points on a fixed (self-chosen) range. Hopefully this helps you to solve the problem in the original code, or find a similar workaround. Good luck! Sebas Peters

…

On 22/01/2018, eleboss ***@***.***> wrote: Hi! I am a Msc student in China, and trying to use a UAV, assembled with a 2D-lidar, to flying in a tunnel. Lidar is using to detect the surface of the tunnel ,which can be treated as a line in 2D-lidar data. By searching, I found your code in the github and it seems works very well. So I download and catkin_make it. But what confuse me is, I see no segments output data from the /line_segments. I play around the parameters but nothing change, then I trying to use printf to print the data and fail again. I am new to C++ ROS coding， so can you give some advices on how to deal with this problem or usually how you debug the code? I leave my parameter below, and my rosbag link. By the way, I am using the /scan_filtered topic. Best, Lin <launch> <node name="line_extractor" pkg="laser_line_extraction" type="line_extraction_node"> <param name="~frequency" value="30.0" /> <param name="~frame_id" value="rplidar_link" /> <param name="~scan_topic" value="/scan_filtered" /> <param name="~publish_markers" value="true" /> <param name="~bearing_std_dev" value="1e-5" /> <param name="~range_std_dev" value="0.012" /> <param name="~least_sq_angle_thresh" value="0.0001" /> <param name="~least_sq_radius_thresh" value="0.0001" /> <param name="~max_line_gap" value="0.5" /> <param name="~min_line_length" value="0.7" /> <param name="~min_range" value="0.5" /> <param name="~min_split_dist" value="0.04" /> <param name="~outlier_dist" value="0.06" /> <param name="~min_line_points" value="10" /> </node> </launch> bag file: https://github.com/eleboss/UAV/blob/master/2018-01-22-15-28-43.bag -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #1 (comment)

[kam3k]

I'm interested in fixing your bug, would it be possible for you to provide a short bag file which reproduces the issue (i.e., without your hardcoded data)?

[SebasPeters]

Hi, Unfortunately, my graduation project is finished and I don't have access to the accompanying hard and software anymore, nor a representative bag file. The problem occurred when only one line was in sight, so when the scanner was in front of a wall or was facing a line in an empty room. Maybe you are able to mimic this situation. Best regards, Sebas Peters

…

Op 23 jan. 2018 om 19:38 heeft Marc Gallant ***@***.***> het volgende geschreven: I'm interested in fixing your bug, would it be possible for you to provide a short bag file which reproduces the issue (i.e., without your hardcoded data)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.