search

ros-drivers / velodyne

ROS support for Velodyne 3D LIDARs
http://ros.org/wiki/velodyne
Other
657 stars 653 forks source link

ROS2 compatible version #165

Closed aarushg22 closed 5 years ago

aarushg22 commented 6 years ago

Hi, Is there any active development going on for a ROS2 compatible version of the velodyne driver or a ROS2 wrapper?

JWhitleyWork commented 6 years ago

Not in my company, at the moment. We have it on our roadmap but it's some time out.

msemtd commented 6 years ago

Further to a ROS2 compatible version, I'm working with a ROS independent port of a large part of the VLP-16 packet to pointcloud conversion code. It's rather messy at the moment but I hope to make it available sometime.

JWhitleyWork commented 5 years ago

@msemtd - Any progress?

I also heard a rumor that @dejanpan was working on something similar.

msemtd commented 5 years ago

Yes, but there's a lot of work required to make it publicly available: dependencies on proprietary code, based on quite an old branch, getting it past the legal dept. etc.

JWhitleyWork commented 5 years ago

Thanks for the update. It'll stay on AStuff's list to develop it but I won't hold my breath for either option.

dejanpan commented 5 years ago

@JWhitleyAStuff sorry for late reply. Our development is done: https://gitlab.com/AutowareAuto/AutowareAuto/tree/master/src/drivers.

You can see design documents detailing the architecture design:

  1. https://gitlab.com/AutowareAuto/AutowareAuto/blob/master/src/drivers/velodyne_driver/design/velodyne-driver-design.md
  2. https://gitlab.com/AutowareAuto/AutowareAuto/blob/master/src/drivers/udp_driver/design/udp_driver-design.md
  3. https://gitlab.com/AutowareAuto/AutowareAuto/blob/master/src/drivers/velodyne_node/design/velodyne_node-design.md

We have this MR to show how to playback and visualize the data but an issue with rviz is holding it back: https://gitlab.com/AutowareAuto/AutowareAuto/merge_requests/26.

It should be merged in couple of days though.

dejanpan commented 5 years ago

@JWhitleyAStuff I forgot to add that I'd like that we get some feedback and testing on this initial implementation which is a bit large because we wanted to make the driver to be more suitable for safety applications. The design documents motivate and explain the design decisions.

After we will iterate on the implementation above, we should then bring it into this repository here.

Thoughts?

JWhitleyWork commented 5 years ago

@dejanpan Thanks for providing this as soon as it was ready for testing! The design documents and implementation look excellent. However, I want to make sure I understand the limitations of the current implementation:

  1. It appears that the provided driver is designed with sensor-specific parameters for the VLP-16 (Vlp16Translator) only - is that correct?
  2. Since the VLP-16 does not need a calibration file in most cases, this driver does not accept one for adjusting the firing positions, yeah?

Since the driver that you guys have developed appears to be VLP-16-specific and is pretty heavily integrated into the Autoware ecosystem, I think it's going to take a good amount of time to make portions of it generic to all Velodyne sensors, integrate the ability to load sensor-specific calibration files, create and test class implementations for other sensors, and make it a group of stand-alone ROS nodes. With that in mind, the sooner we can get it in the hands of the development community for general use (outside of Autoware), the better. However, I know it is very new and may not have had much testing time. Do you have an idea of when it may be testable as part of the Autoware.Auto infrastructure? After this point, I'd say a month or two of on-vehicle testing should be plenty to prove the concept and copy the contents out for generalization.

Side note: Since the design and implementation of your driver are vastly different from the existing one (this repo), it's likely work will begin on the generalization in a different repo. I will try to get the other Driver SiG members to OK the creation of a new repo in ros-drivers just for this purpose, if others think that also makes sense.

JWhitleyWork commented 5 years ago

Hey, @dejanpan - Any update on this?

klintan commented 5 years ago

I started this work as well, if you create a ROS2 branch I can create a draft PR to that branch.

(Of course if others already have this almost finished I would love to just use that :) )

I saw the Autoware one, and as stated above here, it depends on some stuff which is Autoware specific, I was thinking I would pretty much just try to convert this lib to ROS2.

JWhitleyWork commented 5 years ago

@klintan - You're correct, it is pretty Autoware-specific. I'll create a crystal-devel branch that we can work on here. One second.

JWhitleyWork commented 5 years ago

OK - I created a crystal-devel branch. So we're on the same page, are you creating a full ROS2 port or working on a ROS1/ROS2 hybrid?

klintan commented 5 years ago

Awesome thanks!

Hm I guess I don't I really know the difference/distinction, but the goal would be to be a full ROS2 port.

JWhitleyWork commented 5 years ago

A ROS1/ROS2 hybrid is a node that can build and run in both ROS Melodic (or earlier, in some cases) and ROS Crystal. I'm working on getting one released right now: https://github.com/astuff/ml_classifiers

See the CMakeLists.txt and package.xml for details. The biggest advantage is shared code - the core C++ code can remain unchanged and the ROS-version-specific wrapper is written twice: once for ROS1 distros and once for ROS2 distros. There are a few pros and cons and I would appreciate feedback from the community - hopefully @jack-oquin and maybe @mikepurvis can weigh in.

klintan commented 5 years ago

That is awesome! had no idea it was possible. For now though, my draft PR would be a full port pretty much (still trying to keep it as close as possible to the Ros1 code though) .

JWhitleyWork commented 5 years ago

OK, cool. Hybrid nodes are a pretty new thing. I'll check over the PR and leave this issue open for further general discussion.

nethdeco commented 5 years ago

I was wondering if you guys completed the full ROS2 porting and if there are additional things to be done.

klintan commented 5 years ago

There are still work to be done, I got sidetracked by the pcl_conversions.h dependency, which is in the pcl_perception library. However for that there are a bunch of stuff missing in ROS2 (type masquerading being one of the most important ones) which is why it takes some time.

I'm hoping to get back to this package and PR in a couple of weeks, so any help on this would be much appreciated :)

clalancette commented 5 years ago

I'm thinking we can close this issue out as well; it is covered by the ROS 2 port on the dashing-devel branch now.

JWhitleyWork commented 5 years ago

Agreed, @clalancette.