Improved ROS driver for the Leap Motion gesture sensor

[Chris]

Hello!

I have posted this before on the Leap Motion controller's Github page, but it didn't seem to draw any attention. So I am trying my luck here.

After seeing that the ROS driver for the Leap Motion controller was somewhat lacking I wrote one myself using C++. I would like to know if there's any interest in it here, maybe it could replace the current one.

Currently my ROS package supports one person (left and right arm), publishing raw camera images from the controller, gesture detection, basic visualization using Rviz and a pointcloud generated from a stereo_image_proc node. The gesture functionality is somewhat untested currently, because I don't have any particular need for it, but it seems to work.

I have also made a filter node implementing a 2nd-order Butterworth lowpass filter that is used to filter the hand's x, y, z coordinates coming from the Leap controller via custom made Human.msg.

I pieced it together from multiple repositories found on Github with main sources of inspiration being the UTNuclearRobotics, juancamilog repositories. All other functionality that I deemed missing  was implemented by myself.

You can find my current work here for browsing and/or testing the package. If anyone with the right permissions is interested, let me know.   
 

[Jack O'Quin]

There are comments on that github issue. What input are you seeking here?

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drivers+unsubscribe@googlegroups.com.
To post to this group, send email to ros-sig-drivers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/6e9c113c-7448-4dc3-a2a8-33dbc0a3a82b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

 joq

[Chris]

On Thursday, February 22, 2018 at 12:59:00 AM UTC+2, Jack O'Quin wrote:

There are comments on that github issue. What input are you seeking here?

That's true, but I still haven't gotten an answer to my question. Warp1337 said that he would be interested in the merge however " We should discuss that first with the ros drivers community." As a newcomer to ROS, I asked what he meant by that and if I needed to do something specific. Sadly, there was no reply to my inquiry, so I am trying to take the initiative.

As I understand this is the place for official ROS drivers, so I'm trying to see if there's any interest and start a discussion. If this is the wrong place to ask these questions then do let me know and I'm sorry for wasting your time.

[Jack O'Quin]

It's not the wrong place, yours is just a rather vague question. Specifically, what do you propose?​

[Chris]

On Friday, February 23, 2018 at 8:13:17 PM UTC+2, Jack O'Quin wrote:

It's not the wrong place, yours is just a rather vague question. Specifically, what do you propose?​

I would propose replacing the entire repository with code from mine and updating the documentation/Wiki. Everything that the official drives does, mine does too and, hopefully, even better.
I know this would break backwards compatibility with the users of the current implementation and ROS distributions before Kinetic, but I feel that the benefits from the new driver outweigh the annoyance that it might cause to the current users.

[Jack O'Quin]

On Fri, Feb 23, 2018 at 2:55 PM, Chris <woozy...@gmail.com> wrote:

I would propose replacing the entire repository with code from mine and updating the documentation/Wiki. Everything that the official drives does, mine does too and, hopefully, even better.
I know this would break backwards compatibility with the users of the current implementation and ROS distributions before Kinetic, but I feel that the benefits from the new driver outweigh the annoyance that it might cause to the current users.

I can see the advantages.

For backwards compatibility, have you considered retaining the old driver and adding your new one as an additional node in the same package? 

People could choose which they prefer. You could mark the old driver as deprecated, giving users a release cycle to migrate at a time that makes sense for their own projects. We try not to make disruptive changes, when they are not necessary. 

--

 joq

[Chris]

On Saturday, February 24, 2018 at 7:09:26 PM UTC+2, Jack O'Quin wrote:

For backwards compatibility, have you considered retaining the old driver and adding your new one as an additional node in the same package?

Actually, I hadn't thought about it. However, yes, that is totally possible, easy to do and a good idea. 

[Jack O'Quin]

If you are willing to provide on-going maintenance, I see no objection to adding your new implementation. 

--

 joq

[Chris]

On Tuesday, February 27, 2018 at 2:45:15 AM UTC+2, Jack O'Quin wrote:

If you are willing to provide on-going maintenance, I see no objection to adding your new implementation.

Sure, I see no problem in it.