Detach LOAM from ROS

[YoshuaNava]

Hi, I think that it could be extremely useful to detach LOAM from ROS, such that:

1. It can be used as a stand-alone method for motion estimation, e.g. by instantiating a class "LoamEstimator", which is feed with point clouds and IMU messages. It could return odometry, mapping and integrated motion estimates, as well as point clouds that contain features, the map and the current cloud registered in the map.
2. As a consequence of 1, be able to tune the parameters of the algorithm to increase accuracy.
3. Also because of 1, be able to integrate Loam into more complex systems, non dependent on ROS.
4. Make it easier to run tests with KITTI or other datasets.

There was substantial work in this direction from users @adrelino and @sebdi, contained in this repo. I'm also currently working on this for my thesis, but it may take some time until I submit a pull request.

What do you think? Would anyone be interested in collaborating for achieving this?

Kind regards, Yoshua Nava

[jlblancoc]

I absolutely agree with this approach, not only for this algorithm but for every single Ros package!

But I don't have spare time to help with this package, at least not in the short term.

Cheers

[adishavit]

I did this recently. I plan to submit a PR for this soon. I have it running ROS-free on Windows too.

[YoshuaNava]

@jlblancoc Thank you! Hope we can take this initiative forward

@adishavit That's awesome! Could I ask you some questions about what you did? I have tried to phrase them so that they can be answered in a brief way. Now, I assume you took away all references to ROS message passing present in the registration, odometry, mapping and transform maintenance classes. Then,

1. Did you create individual wrappers for each module, or one wrapper for LOAM as a whole?
2. Did you replicate in some way the presence of ROS callback queues holding new messages (from the IMU, odometry, transforms, etc) with threading and buffers?
3. Did you observe any noticeable impact on the performance/accuracy?

Thank you very much.

[adishavit]

@YoshuaNava :

1. I separated the ROS "transport" layer from each module from the underlying algorithm. So for ScanRegistration I now have the algorithm class BasicScanRegistration which depends only on PCL, and which ScanRegistration derives from, though you could also use aggregation or BasicScanRegistration directly (no protected members and very few virtual functions). This is done for each module and each is still built into an independent lib as before. I kept the original interface as is (even where it is currently somewhat clunky and redundant).
2. The only ROS facility I needed to replace was using std::chrono instead of ros::Time there rest remains in the ROS-using transport layer.
3. The code does not have any tests: not unit tests nor performance and qualitative tests - so it is hard to say for sure. Performance should be identical as I did not try to make any functional changes (up-to any bugs I may have introduced (or fixed)).

[YoshuaNava]

Hi @adishavit, Thank you for your feedback.

This is the fork and branch to which I have been pushing my changes: https://github.com/YoshuaNava/loam/tree/detach_ros

In the last few days, I:

• Was able to detach LOAM from ROS, and build it like a standalone library, with depends on Eigen and PCL.
• Moved parameters that govern LOAM's execution to structs.
• Created some simple ROS nodes that forward new data to the scan registration, laser odometry, laser mapping and transform maintenance modules. The new loam_ros package employs ROS only for transporting the data between the nodes. Also, the LOAM params values can now be set via yaml files, which are given preference over the default params.
• Instead of using std:chrono, stored the time in seconds as a double. (this might not be the best solution, though)

Until now everything seems to be working. I have been testing one module at a time. I hope I can finish this and open a pull request soon. A lot of changes might be going in, so I'll divide it into pieces.

Note: As a future enhancement, I was planning on further taking apart the ROS transport layer, as mvelas. He wrote structs that contain the inputs/outputs of each module, and is able to run it on KITTI without ROS.

However, I wonder if the tests performed by Zhang relied on ROS or not. Something I noticed in one of the Kaarta Contour videos on YouTube is that they do use rviz for real-life operation, which means that ROS is running behind the curtain.

[adishavit]

@YoshuaNava : Would you be interested in seeing my refactoring? I'll try to upload it by tomorrow.

[YoshuaNava]

Hey @adishavit, That would be awesome! Please keep me updated

[adishavit]

I just pushed it - you can see it here. It's far from perfect - my goal was to get it to build on Windows so I could evaluate it in a non-ROS environment - which it does. So this is not the most that can/should be done. Having another set of eyeballs on it would be a tremendous help. Especially with documenting the LOAM code. I'd also like to refactor the math to higher level things - but that's another issue.

Do feel free to add review comments, issues and questions.

I also made it a PR.

[sume-cn]

@adishavit this repo can be tansplanted to windows, I've tested it, but the output trajectory is deformed

[claydergc]

@sume-cn the error in my repo is produced because I didn't add the time stamp to the messages and that's quite important. It would help if someone could do that.