Public place to ask questions, post and discuss issues

[Maofei]

The NaN results found in matX during odometry L-M iterations is due to the duplicated points in surfPointsLessFlat, which results in same tripod points in planar patch tripods when matching. This can be solved by doing VoxelGrid filter after all scan surfpoints are collected in scanRegistration process.

[vkee]

Has anyone gotten this to work on the KITTI dataset?

I created a bag (https://www.dropbox.com/s/o0h9ej0vfoaylrx/test.bag?dl=0) of one of the sequences with this tool (https://github.com/ethz-asl/kitti_to_rosbag) but when I try and run loam_velodyne on the dataset, the scanRegistration node just dies after handling a few callbacks of the point cloud.

[Maofei]

@vkee You need to check the previous posts here to figure out some necessary modifications in scanRegistration for 64HDL datasets.

[vkee]

@Maofei ah, thanks. I got it to work.

However, there is a bit of an delay when LOAM starts as you can see in this screencapture (https://www.dropbox.com/s/inoly5d19osed38/loam_offset.mp4?dl=0). The tf in front is essentially the ground truth of the velodyne and other sensors created from GPS INS.

I assumed the frame camera_init is the initial pose of the velodyne sensor so on the first laserCloudHandler callback on the subscriber subLaserCloud, I lookup the velodyne pose from the ground truth truth and then set camera_init as a static frame. Is what am doing here correct? Should I be setting camera_init at a different point in the code?

Does anyone know what may be causing the delay for LOAM to display the estimates when the node and bag start playing?

Thanks!

[vkee]

I found that the main cause was the variable systemDelay in scanRegistration.cpp (https://github.com/laboshinl/loam_velodyne/blob/master/src/scanRegistration.cpp#L57). Does anyone know the purpose of this?

[jackiechenxd]

Is there any clustering algorithm in LOAM to reject moving objects from PCL? If not, this could be implemented to improve odometry accuracy.

[Kailegh]

@XuDongTL I don't think there is anything like that, i have get fucked up by moving objects quite a few times, but is not something easy to achieve, you would need another way of getting your actual speed to be avaible to discriminate between static and dynamic objects, and would probably be slower than the current algotithm

[Kailegh]

@laboshinl Do anybodyy know why the error for the rotation and the traslation is has the same threshold? I mean, is the rotation error in deg or rad and the traslation error in m? I do not know what units do they use

[jackiechenxd]

@Kailegh I am not surprised that you mention moving objects will screw up SLAM, it may depends on how near is the moving object to velodyne. I think I do also encountered a few times when I am really near to my velodyne. I will be looking on how to cluster and differentiate moving object from environment.

[xiaozhuka]

Does anyone know what's wrong with my data? When I test this algorithm with VLP16, the result data seems to be awesome. One frame of pcap like this

[MuhammadMoeedUllah]

Can I use use Kinetic with Loam. Will it cause any problem ?

[MuhammadMoeedUllah]

why cant i display with loam on kinetic. While it works fine with rviz only/

[tcts-mvcp]

As stated in https://github.com/daobilige-su/loam_velodyne using loam for one of the test data gates_oscillating_motion.bag does not get the clear result as in the demo video of the original author. http://www.frc.ri.cmu.edu/%7Ejizhang03/Videos/gates_oscillating_motion.mp4 In my thought it might be an issue of IMU data processing in the code, as gates_oscillating_motion.bag containing IMU data, and in my experience including IMU data does not improve loam.

[MuhammadMoeedUllah]

So i must not use loam, thats your suggestion?

[ZulunZhu]

@laboshinl Sorry to disturb you but I really met a mistake when I use C++11 to compile the project.The process of compiling have no problem ,but when I run these four nodes,the scanregistration,lasermapping,laserodometer will down for Segmentation Fault.Do you have any suggestion to solve this problem?

[yangfei1223]

@laboshinl Why can not I download the 'VLP16 rosbag'? Does the link become invalid?

[LiShuaixin]

Hi @laboshinl ,thanks for you sharing. LOAM works well with the public dataset you provided, and I’d like to test it with other dataset like KITTI. To insure LOAM can fit the HDL-64E Lidar in KITTI dataset, I change the scanRegistration.cppas you asked in other issue. However, it failed. I debugged the node and found that KITTI dataset just provide 4 values (x y z intensity) without rings. Do you have any idea that how to put points into different rings as you did with VLP-16 Lidar? Looking forward to your reply!

[StefanGlaser]

Hi @LiShuaixin , that's interesting. What ring values are reported in this case? All zero?

[LiShuaixin]

@StefanGlaser KITTI Velodyne data are stored as binary files. Data contains 4 values, where the first 3 values correspond to xyz, and the last value is the reflectance information. There is not ring value at all. When I read the code, I noticed that rings value can be determined by elevation of every point, and I am trying to use the same scheme. I checked the specification of HDL-64E and changed the code according to the distribution of scans. However, it’s not suite for every dataset.

[LiShuaixin]

Hi @CansenJIANG , have you tested LOAM with KITTI dataset? Could you please give me some advice?

[swarmt]

Hi everyone!

Is it possible to make loam publish odom in the map frame in: x forward y left z up

With a static transform?

I would like to have /camera in the same frame/orientation rotation as the raw /velodyne_points

Cheers!

EDIT: Just saw this has been answered above. For anyone else: <node pkg="tf2_ros" type="static_transform_publisher" name="camera_init_to_map" args="0 0 0 1.570795 0 1.570795 /map /camera_init" /> <node pkg="tf2_ros" type="static_transform_publisher" name="velodyne_to_camera" args="0 0 0 -1.570795 -1.570795 /camera /velodyne" />

[Gurkirand]

In the LOAM paper, the authors represent the rotation matrix using the Rodrigues formula which I believe is based on an axis angle representation. I was just wondering why the code base uses euler angles? Wouldn't axis angle be easier for calculating the rotation matrix, its Jacobian, and converting to quaternion?

[FaiScofield]

Hi @laboshinl @CansenJIANG , thanks for your sharing.
I wonder how to use the CloudCompare to get a result like the sample map, showed in the README.md file. And I followed @CansenJIANG 's step, I got this result: They seem not to be a good result as detailedly as the sample map, and I don't know how to improve. Here are some results of using my dataset: Please tell me how to get such a result if you are free. Thanks a lot.

[Mysmith]

Recently，I have tried it with VLP16, the rviz cann't show point cloud, the process occour the error:

[multiScanRegistration-2] process has died [pid 9368, exit code -11, cmd /home/smith/catkin_ws1/devel/lib/loam_velodyne/multiScanRegistration /multi_scan_points:=/velodyne_points name:=multiScanRegistration log:=/home/smith/.ros/log/4186c616-eca3-11e7-9ecb-506313c305da/multiScanRegistration-2.log]. log file: /home/smith/.ros/log/4186c616-eca3-11e7-9ecb-506313c305da/multiScanRegistration-2*.log

I can't find out what exactly causes the crash. Any help please. Thank you!

[StefanGlaser]

@Mysmith it's hard to guess what's going wrong without further information. I would be very interested to get your particular dataset in order to reconstruct the error.

[Mysmith]

@StefanGlaser Thank you for you answer. I learn to loam_velodyne recently. I run the loam_velodyne according to https://github.com/laboshinl/loam_velodyne.
In first terminal $ cd ~/catkin_ws/src/ $ git clone https://github.com/laboshinl/loam_velodyne.git $ cd ~/catkin_ws $ catkin_make -DCMAKE_BUILD_TYPE=Release $ source ~/catkin_ws/devel/setup.bash roslaunch loam_velodyne loam_velodyne.launch

In second terminal play sample velodyne data from VLP16 sample pcap roslaunch velodyne_pointcloud VLP16_points.launch pcap:="/home/smith/download/2014-11-10-10-36-54_Velodyne-VLP_10Hz-County Fair.pcap"

but, when I run roslaunch velodyne_pointcloud VLP16_points.launch pcap:="/home/smith/download/2014-11-10-10-36-54_Velodyne-VLP_10Hz-County Fair.pcap" the rviz cann't show point cloud, the process occour the error in first terminal :

[multiScanRegistration-2] process has died [pid 9368, exit code -11, cmd /home/smith/catkin_ws1/devel/lib/loam_velodyne/multiScanRegistration /multi_scan_points:=/velodyne_points name:=multiScanRegistration log:=/home/smith/.ros/log/4186c616-eca3-11e7-9ecb-506313c305da/multiScanRegistration-2.log]. log file: /home/smith/.ros/log/4186c616-eca3-11e7-9ecb-506313c305da/multiScanRegistration-2*.log

I also test these data: nsh_indoor_outdoor.bag,the error is the same.

I can't find out what exactly causes the crash. Any help please. Thank you!

[StefanGlaser]

@Mysmith that's strange...

Just to be clear, rviz is fine. The reason it doesn't show anything is because the scan registration node crashed and thus no data is processed. However, I'm not sure why the scan registration component crashes in the first place. It works fine for the "nsh_indoor_outdoor.bag" and other test datasets on my machine, using ROS kinetic and Ubuntu 16.04.

I'm currently downloading the datasets you mentioned and try to reproduce your crash scenario. I'm not very confident to find much, but I'll let you know once I have some results. In the meantime, you could either debug the "ScanRegistration" and "MultiScanRegistation" parts, or at least add some console outputs to narrow down the problematic code sections.

[FaiScofield]

@LiShuaixin Are you the one who shared 4 articles about LOAM on Zhihu website ? I find your name so familiar... Have you solve the KITTI problem ?

[StefanGlaser]

@Maofei @drscopus did you have any success in figuring out the jacobian entries for arx, ary and arz?

I would expect something like the cross product of the point location and the axis of rotation, projected onto the direction. However, I can't find the cross product terms within the calculations.
One option to implement the above calculation without directly performing an actual cross product is to transform the point of interest into the "local" system, build the cross product there and then rotate the result back into the original system. But I was too lazy to verify this guess, as it is not that trivial.

EDIT:
I meanwhile did the math myself and recognized that the equations for arx, ary and arz are the actual partial derivatives of the cost function. I guess I was a bit biased in approaching the calculation of the Jacobian as I was used to in previous inverse kinematics problems...

[Mysmith]

@StefanGlaser Thank you very much for you answer! I will use your method to have a try.

[StefanGlaser]

@Mysmith I'm happy to help, but unfortunately I wasn't able to reproduce your error.
On my machine all the VLP16 pcap files from here work just fine. No crashes, no errors. RViz shows the resulting map, which also looks reasonable to me. So I can't really tell what's going wrong in your case. Did you have any luck in debugging the application on your machine?

[swarmt]

Is it best to use a cloud_nodelet or transform_nodelet from the velodyne driver?

[Rolanding]

@laboshinl I want to build a big outdoor map by using the Loam. But in the rviz, it just show a fixed-size map. Actually all the points cloud still exist in the rviz but it just show the sub map around the car. So how to show the complete map? And further more, how to save the full map into a .PCD file, Thank you.

[mishrasubhransu]

200 Hz Localization? Has anyone here used a high frequency lidar based localization system based on LOAM? Or any links to similar projects?

[arjunsuresh22]

@laboshinl Please suggest a method by which i can localize using LOAM on a given map? Given that LIDAR is the only sensor i am using

[KitKat7]

@StefanGlaser I agree with your explanations on the Jacobian matrix. Taking the planar points as an example, the cost function should be f = w^T(R^T(X-t))+b, where R is rotation matrix from ZXY order euler angle, t is the translation, w is the direction of the plane and b is the distance of the plane to the origin. Doing partial derivative on rx, ry, rz, tx, ty, tz will get the exact results as shown in the program.

But do you know how the degeneration is solved by the following program? How does the "eignThre" work? Thanks a lot!

[StefanGlaser]

Hi @KitKat7,
I haven't really looked into the calculations in detail. But here are my thoughts after doing so for a couple of minutes (so I may be totally wrong ;) ).

We are trying to solve a linear system Ax = b with six unknown values. In order to be able to solve successfully for x, we need six independent equations that are non-zero. In practice, we typically have measurement errors, etc. and we usually do not know in advance if a set of point correspondences will result in six independent equations. This is one of the reasons we use a lot more than 6 correspondences to construct A. However, even infinite point-to-plane correspondences could result in A becoming singular or near singular.

For example, consider the scenario in which a robot has a limited field of view and is placed in front of a flat wall (not sensing the ground). Even though it can extract plenty of point-to-plane correspondences, there is no way it is able to argue about its 2D translation parallel to the wall, nor its rotation around the axis perpendicular to the wall. The resulting A matrix will only contain three independent equations and thus be degenerated. So far the theory. In practice, due to measurement errors, we typically have an over-specified system and therefore need to check for near singularities within the A matrix.

Now, in the first iteration, the implementation checks the A matrix (matAtA) for near singularities, starting with the lowest eigenvalue. If it's below a specified threshold, the corresponding eigenvector is zeroed out in the matV2 matrix. This is repeated for each eigenvalue / eigenvector combination, until the eigenvalue exceeds the specified threshold. Afterwards, matV2 is pre-multiplied with the inverse of matV to obtain matP. If we would not have zeroed out some eigenvectors within matV2, matP would be the Identity matrix. However, with each zeroed out eigenvector in matV2, we practically cancel out the effect of the optimization in the corresponding direction.

In other (simple) words: If the variance of the data along a certain direction is below a certain threshold, this direction is ignored during the state update step of an iteration. This prevents the optimization from moving along directions it has no valid information about.

Again, keep in mind that this is just my first guess after a relatively short look at the code. So please don't take anything for granted. Best luck in finding the correct answer ;)

[KitKat7]

@StefanGlaser Thanks a lot for your answers! So illuminating :D.

EDIT: But in the program it seems not from the lowest eigenvalue, but from the largest eigenvalue. I will check it later, and update if I have any process. Many thanks.

[StefanGlaser]

@KitKat7 well, I'm happy to help! But experience shows that even if something sounds plausible, it's not necessarily correct ;)

Regarding the order of the eigenvalues, they are usually sorted from high to low (at least that's what I'm used to). As the loop goes from 5 to 0, I assumed that it checks the lowest eigenvalue first.

[afasc]

I am trying to perform Aerial LiDAR mapping on a dji drone with the Velodyne Puck Lite. The onboard sdk provided by the dji developer website is not compiling correctly (the package pointcloud2las is not compiled). Anyone has had any experience with that? Sorry if this is the wrong spot for posting this, but I am really desperate trying to find a solution for this problem.

[KitKat7]

@StefanGlaser I think your explanation sounds pretty plausible ;).

One thing confused me before was the implementation in the codes. In an older version 3feae58, the OpenCV's cv::eigen was used, which returned eigenvalues in decreasing order. However, the current version d146f4b uses Eigen's SelfAdjointEigenSolver, which returns the results in increasing order.

I guess the inconsistency might be buggy, but not verified yet.

[Xiangzhaohong]

@laboshinl I just found a problem, how can I solve it? The same palce ,but the hight is not the same.

[Shantnu12345]

Hi,

I have the same question as @RuochenYin. Can someone please suggest how to see the complete registered point cloud in RViz? Currently, the previously built map gets deleted. I would like to see the whole of the previously built map.

If doing that is not possible in RViz, then I would like to save the whole map as a .pcd file, so that I can view in pcl_viewer. For that, I am doing "rosrun pcl_ros pointcloud_to_pcd input:=/velodyne_cloud_registered". But this saves only the current map, and not the previously built map.

In conclusion, please suggest me: 1) How to visualize the fully registered map in RViz 2) How to save the fully registered map in .pcd

---

Update: According to a suggestion by @StefanGlaser, I got it working by changing one of the for loops in the LOAM's original code. The registration is really good. I was able to register over 2 miles of data (from a pcap file) and view it in RViz simultaneously. I am out currently and will post the change here soon, once I have access to my lab's computer.

[StefanGlaser]

Hi @Shantnu12345 ,
issue #41 sounds very similar to what you are looking for.

What do you mean with current map and previously built map?

[Xiangzhaohong]

Hi, How could I get the registered map with intensity? In loam the intensity of pointcloud is not use.

Thank you!

[StefanGlaser]

Hi @Xiangzhaohong,
unfortunately you can't. Any additional information apart from x, y and z coordinates are discarded during the processing. I tried once to make the implementation generic with respect to the input point types. However, it's not that trivial and requires a major refactoring of the inter component communication, etc.

[ashnarayan13]

Hi,

Can the X and Z be interchanged? When I run the loam on my test data. The map is being built well, but the Z and X axis are interchanged. This is affecting my planning. I am not sure which part of the code handles this. Any insights would be great!

Thanks!

[StefanGlaser]

Hi @ashnarayan13,
are they really interchanged, or is the system just rotated around 90 degrees? I tried to "interchange" the X and Z axis once, but noticed that one would have to respecify the optimization problem. Not really a problem - just a lot of code to change and potential to do things wrong.

I wonder if you could not achieve the same effect by simply transforming (rotate) the incoming, respectively outgoing point cloud accordingly?

[ashnarayan13]

Hi @StefanGlaser ,

There seems to be some issue. The direction of motion for my vehicle is in the Z axis as per loam. I do not know why. I have enclosed two screen shots of the LOAM. It directly starts perpendicular to the grid in RVIZ.

You can see that the LOAM considers the vehicle to be moving in the Z axis. Is there any way to alter this? When I just play the data (PCAP file) with the velodyne driver, the direction of motion is in the X axis.

Screenshot from Velodyne

I could rotate the final pointcloud, but I will also have to rotate the odometry in that case. I was wondering if this is an issue with my data or it is an issue with LOAM and if so, is there a way to fix it in the code.

Thanks!

[jec1key]

@FaiScofield hi，how to obtain the .pcd file from .bag or .pcap file?