Robotics StackExchange | Archived questions

Why is RosAria PointCloud and LaserScan mirrored?

Is there a reason why the pointcloud and laserscan readings from rosaria (when running MobileSim) is mirror in relation to eachother when observing in RVIZ? It seems like the pointcloud (flat squares) is correctly oriented in relation to the simulation in MobileSim while the laserscan (boxes) are mirrored. Why is this?

pointcloud and laserscan illustration

image description

image description

Asked by fendrbud on 2019-11-12 03:37:45 UTC

Comments

Please attach your image directly to the question, so we can keep things self-contained.

I've given you sufficient karma to do that.

Asked by gvdhoorn on 2019-11-12 04:01:18 UTC

Thank you, corrected now.

Asked by fendrbud on 2019-11-12 04:12:38 UTC

Are you sure your transforms are properly set?

It is like you are publishing the Pointcould in a frame and the laser scan in another frame with a different transformation.

Asked by Weasfas on 2019-11-12 05:15:04 UTC

I believe the OP is using one of the .xacros from the MobileRobots/amr-ros-config repository (#q335375), so I would assume those are OK, but perhaps there is some configuration that needs to be updated.

Asked by gvdhoorn on 2019-11-12 11:16:03 UTC

I Indeed use the urdf from MobileRobots/amr-ros-config. Specifically this one which I believe should be correct, right?

Asked by fendrbud on 2019-11-12 15:06:23 UTC

I don't see any mention of a laser scanner or anything about sensors in that .urdf. Did you add something yourself? Or how did you 'attach' the laserscanner to the robot model?

Asked by gvdhoorn on 2019-11-12 15:21:03 UTC

The transformation between the base_link and laser_frame is published by RosAria (see the image I added to the original post).

Asked by fendrbud on 2019-11-12 15:28:38 UTC

The transformation between the base_link and laser_frame is published by RosAria

that could be, but that does't mean it necessarily correct.

If you visualise the TF tree in RViz (add the display), does it have the expected orientation?

From your RViz+rosaria screenshot it looks to me like the entire robot is 'backwards'. Does rosaria require any configuration? Perhaps you need to tell it which model Pioneer you have and what sensors are mounted and how?

I've never used rosaria or these robots though, so I could be wrong.

Asked by gvdhoorn on 2019-11-13 02:29:56 UTC

I uploaded another picture showing the frames in rviz which to me seems to be correct. However, the TF tree in the left panel does not show the expected tree and it seems like there is some kind of bug since the "odom" tab between "Tree" and "base_link" is invisible.

When using MobileSim I explicitly tells it that it should simulate a Pioneer LX robot ($MobileSim --robot pioneer-lx), specifically this Aria/params/pioneer-lx.p.

edit: line 135 in the file mentioned specifies that the laser is flipper (LaserFlipped true; Laser_1 is upside-down.)

Asked by fendrbud on 2019-11-13 06:36:07 UTC

edit: line 135 in the file mentioned specifies that the laser is flipper (LaserFlipped true; Laser_1 is upside-down.)

if rosaria flips the laser, but the TF frame is not flipped, that could cause what you are seeing.

Again: I don't know whether that it 'normal' for this robot/rosaria, or whether there are other ways to configure things properly.

Also: amor-ros-pkg/rosaria#43 seems related.


Edit: looks like LaserFlipped is checked (here). Just to see if it makes a difference: could you set LaserFlipped to false and see what happens?

Asked by gvdhoorn on 2019-11-13 07:42:00 UTC

I just set LaserFlipped to false and made a new map using SLAM, then run the navigation stack. Everything works fine now! amcl need some tuning, but the posearray arrows now converge and the robot navigates fine. This has been a source for headache for me the last couple of days.. Thanks for your help!

Asked by fendrbud on 2019-11-13 08:23:36 UTC

No, this is not a solution.

It merely gives us an indication where the cause of your problem is.

If the LaserPublisher is being used, then the real question is: why is LaserFlipped not taken into account?

That would be something to figure out.

Asked by gvdhoorn on 2019-11-13 08:42:05 UTC

This is then a bug in rosaria's LaserPublisher.cpp which should take this into account, right?

Asked by fendrbud on 2019-11-13 09:21:25 UTC

I'm not sure it's a bug, or on which side it would be a bug, if it were one.

Could you add a print statement or something else to determine whether LaserPublisher actually inverts the laser scan when LaserFlipped is true?

Are the settings on the rosaria side correct for the robot you are using (ie: does it really have a flipped laser)?

Asked by gvdhoorn on 2019-11-13 09:41:59 UTC

Answers