ROBOTIS-GIT / turtlebot3

ROS packages for Turtlebot3
http://turtlebot3.robotis.com
Apache License 2.0
1.5k stars 1.03k forks source link

How to tf scans to PointCloud2 while TurtleBot3 LDS Lidar rotates clockwise ? #633

Closed MikeHallettUK closed 4 years ago

MikeHallettUK commented 4 years ago

ISSUE TEMPLATE ver. 0.3.0

  1. Which TurtleBot3 you have?

    • [x ] Burger
    • [ ] Waffle
    • [ ] Waffle Pi
  2. Which ROS is working with TurtleBot3?

    • [ ] ROS 1 Kinetic Kame
    • [x ] ROS 1 Melodic Morenia
    • [ ] ROS 2 Dashing Diademata
    • [ ] ROS 2 Eloquent Elusor
    • [ ] etc (PLEASE, WRITE DOWN YOUR ROS VERSION HERE)
  3. Which SBC(Single Board Computer) is working on TurtleBot3?

    • [ x] Raspberry Pi 3
    • [ ] Intel Joule 570x
    • [ ] etc (PLEASE, WRITE DOWN YOUR SBC HERE)
  4. Which OS you installed in SBC?

    • [x ] Raspbian
    • [ ] Ubuntu MATE 16.04 or later
    • [ ] Ubuntu Server 18.04 or later
    • [ ] etc (PLEASE, WRITE DOWN YOUR OS)
  5. Which OS you installed in Remote PC?

    • [ ] Ubuntu 16.04 LTS (Xenial Xerus)
    • [ ] Ubuntu 18.04 LTS (Bionic Beaver)
    • [ ] Linux Mint 18.x
    • [ ] Linux Mint 19.x
    • [x ] etc (PLEASE, WRITE DOWN YOUR OS) = Windows10
  6. Write down software version and firmware version

    • Software version: [x.x.x]
    • Firmware version: [x.x.x]
  7. Write down the commands you used in order

    • Tried laser_geometry::LaserProjection... transformLaserScanToPointCloud in C++ on Rasberry PI
  8. Copy and Paste your error message on terminal

    • NO error = ran ok ... but did not produce correct results because LDS spins clockwise and ROS standard is for anti-clockwise scan points. Therefore start of scan (0 degrees) at scan stamp time is actually at end of lidar rotation, while 359 degrees is the first scan to be read .. so "End time" at 359 degrees is negative time increment: which transformLaserScanToPointCloud does not seem to handle.
  9. Please, describe detailedly what difficulty you are in

    • Therefore can you please advise: 1) what python or C++ functions should I use to correctly transform a moving Turtlebot3 LaserScan To PointCloud2 ? 2) and / or can the LDS lidar be set to spin anti-clockwise ?

Thanks

Michael Hallett

ROBOTIS-Will commented 4 years ago

Hi, You might want to checkout laser_geometry package to transform the laser scan into PointCloud. http://wiki.ros.org/laser_geometry Thank you.

MikeHallettUK commented 4 years ago

Yes... I already had... and tried = transformLaserScanToPointCloud

... but this assume an anti-clockwise lidar (eg "start" time 0 is after "end" time @ 359 degrees)

ROBOTIS-Will commented 4 years ago

@MikeHallettUK I refered below thread to transform /scan to /cloud on my TurtleBot3 burger, and didn't have any problem creating the PointCloud2. https://answers.ros.org/question/11232/how-to-turn-laser-scan-to-point-cloud-map/

1599099873481 remmina-2020-9-7-4:28:18 008387

MikeHallettUK commented 4 years ago

Yes, I agree "transformLaserScanToPointCloud" runs .... but the point cloud is not correctly compensated for TB3 odom movement, because : a) LDS Lidar rotates clockwise b) your published scan time_increment is 20 x too small

????????????

ROBOTIS-Will commented 4 years ago

@MikeHallettUK I see. Though we cannot change the rotation of the LDS, I've fixed the incorrect time_increment value. Could you try with updated code in the below hotfix-laserscan branch?

$ git clone -b hotfix-laserscan https://github.com/ROBOTIS-GIT/hls_lfcd_lds_driver.git
MikeHallettUK commented 4 years ago

I do not believe this is "a specific case" for only my application. This is fundamental to correcting any clockwise lidar scan for movement of any robot. I am very surprised there seems to be no other issues raised about this.

**Q1) Has the TurtleBot3 LDS Lidar always been clockwise ? I assume there are many TurtleBot3 LDS Lidar customers out there: so I assume I am not the only one with a clockwise lidar scan ? ... so all customers must have this issue ? ( are most other Lidars (e.g. for ROS) anti-clockwise ? )

Q2) If so, then how does anyone using the standard ROS library produce a stable PointCloud2 from a scan while TurtleBot3 is moving ?**

The only partial fix I found was:

So I added this line into "hls_lfcd_lds_driver" to give negative increment...

scan->time_increment = -scan->time_increment; // make negative to account for clockwise spin of lidar

which gives ...

rostopic echo /scan -n1
…
time_increment: -0.000559284118935
scan_time: 0.201342284679

Then "transformLaserScanToPointCloud" works quite well.

BUT.... then Cartographer SLAM no longer works with the negative scan time increment.

so the next question is can you make a change to Cartographer ~ "cartographer_turtlebot" ? to solve this clockwise spin of lidar issue...

a) does Cartographer have a parameter to set this ? in LUA ? ... I cannot find it. b) or can the code that takes the scan in Cartographer be changed to accept either a negative scan time increment, or explicitly reverse the scan order some other way ?

Q3) What is the generix fix for the clockwise spin of any lidar within the ROS system (which is set positive for anti-clockwise spin) ?

... your sugestion of "installing the lidar LDS-01 upside down (though you'll have to sacrifice some angles where supports are installed)" seems like a last resort.... since this surely can be fixed relatively easily in the software (without sacrifice of some angles where supports are installed).

MikeHallettUK commented 4 years ago

I have now fixed this issue with Cartographer ROS SLAM, using a point-cloud as sensor input instead of the laser-scan directly; by changing parameters in the turtlebot3_lds_2d.lua file in ~slam/config to:

num_laser_scans = 0, { instead of = 1, } num_point_clouds = 1, { instead of = 0, }

So this works if you correct the laser scan-lag, converting it to a PointCloud2 (e.g with laser_geometry package routine "transformLaserScanToPointCloud" and changing the scan time increment to be negative for the "end" time at 359 degrees for the clockwise lidar), and publishing this in a topic called "/points2" for SLAM Cartographer ROS to subscribe to.

In fact I also wrote a similar transform LaserScan To PointCloud routine in Python which seems to performs faster, and also feeds the required fixed PointCloud2 into Cartographer ROS.

I do not now have a "kink" in my "walls" when I approach them, and more importantly the whole Cartographer ROS map is much more stable with the Turtlebot3 spinning or turning.

For further discussion on this, with RVIZ screen shots showing the effect, see @ Using Cartographer ROS with clockwise Lidar and Python