-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PowerBot Laser scan and point cloud mismatch #53
Comments
What node are you using for the laser, rosaria or a separate node? (I.e. what is publishing tf data and the laserscan and pointcloud data?) Maybe it's just publishing the data on the wrong axes or the tf is wrong. If you can also post the tf tree (from rviz or view_frames) that could help. |
Maybe its a problem with the way the laserscan is constructed? Thanks for the very clear and detailed info including screenshots. I'll try to look at the problem at some point but if you or anyone else wants to look into it I'd start in LaserPublisher.cpp and where the laserscan topics are published. |
No problem. I'll take a look at LaserPublisher.cpp and see what I can find. |
I have a hack that works as a temporary fix (at least for me). After spending some time looking at LaserPublisher.cpp I couldn't find anything that struck me to be the source of the error. I'm using the lms5xx node from the sicktoolbox_wrapper2 package. It works pretty well except for the fact that now the scans are rotated 180 degrees along the x-axis. To fix that, I wrote a quick and dirty hack where the scan data in the range and intensity fields are reversed (got this idea from LaserPublisher.cpp). I don't have pointcloud data now but I don't need it for the time being and I can now use the laser to navigate. |
Hi, sorry I haven't had time to work on this issue for a while. Glad that 'sicktoolbox_wrapper2' is working, I'll refresh my memory on it and update the /Robots/Pioneer page on the ROS wiki. I also plan on eventually looking at the issue as well. I am guessing your laser on your PowerBot is upside down? It can be mounted either way on the PowerBot, when it's upside down the scanning plane is closer to the floor, so I think that's the typical or default orientation. In the ARIA parameters there is a flag for "flipped" or not you can toggle. If using a separate ROS node for the laser, I think the recommended way of flipping the laser scan data would be to use one of the There are tools/nodes such as |
Good ideas. I'll give the |
Hello, i have the exact same problem and i can't seem to find the solution. Have you had any progress on the bug? Without using the sicktoolbox_wrapper. Thank you in advance. |
Hi, I had a similar problem to this, but with an lms1xx sensor instead. From what I can gather, the lms1xx and lms5xx assume that 90 degrees is the forward ray. Our driver didn't take that into account, so when I tried transforming with Venturing a guess, you probably saw that behavior from Rviz because I think it also uses |
I'm using the most current update of RosAria on the PowerBot and I'm having an issue with the laser scan being offset by 90° as shown below. The red arrow is a pose message taken from the odometry topic and visualized by rviz. The odometry is correct as I've tested and verified it. The problem is that the laser scan is offset by 90° in the counterclockwise direction.
Something strange is going on with the laser scan. I've attempted to create a crude map by using the odom frame as the fixed frame and driving around with the laser scan decay time set to 600 seconds. What should happen is a map is built up from the laser scan data over time. What is actually happening is that when my robot translates the laser scan frame translates as well. This is also shown below.
The point cloud is working fine and is lined up as it should (shown below).
And the laser scan and point cloud visualized together for reference below. The colored dots are from the point cloud and the white dots are from the laser scan. As shown in the screen capture, the two frames are 90° apart.
The laser scan frame "dragged" during translation.
The text was updated successfully, but these errors were encountered: