Using the Ros1 bridge

[Brad Baillio]

If I want to send my own custom ROS2 messages through the bridge for connecting to a ROS1 node, do I need to do anything special?

I'm getting the failure

failed to create 2to1 bridge for topic 'mytopic' with ROS2 type 'mytype' and ROS1 type '': No template specialization for the pair

Thanks.

[Brad Baillio]

 I guess my 2 thoughts are, I need to:

1. Compile bridge with knowledge of my custom message, or
2. Add something to my custom message to include template specialization code

[Dirk Thomas]

Hi Brad,

you have to first compile the package containing your messages and the the bridge again. Otherwise the bridge doesn't know about your message types.

Cheers,

- Dirk

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Baillio]

Ok. So do I source the local_setup.bash script from my messages compile in the shell I compile the bridge in? Then compile the bridge again, and it should know about my message?

Did I understand that right?

Thanks.

[Dirk Thomas]

Yes.

Cheers,

- Dirk

[Brad Baillio]

Ok. I did that, but the bridge is still complaining about "No template specialization for the pair".

I'm basically porting the Velodyne driver code to ROS2 and trying to pass the VelodyneScan message through the bridge.

When I did the recompile of the bridge, I saw

Found velodyne_msgs: 1.2.0

so I think it compiled properly.

But it still gives the same complaint.

Anything I'm missing? You said I needed to recompile my messages. Should I recompile them with ROS1 env sourced? Or something else I could have missed?

Thanks.

[Dirk Thomas]

The ROS bridge finds all ROS 1 and ROS 2 messages in the current environment when being built. Either by relying on the same name or specifying a custom mapping (https://github.com/ros2/ros1_bridge/blob/master/doc/index.rst). So make sure that you source the right ROS 1 and ROS 2 environment before building the bridge. Afterwards make sure to source the right environment to use the newly compiled bridge rather then the previous one.

Cheers,

- Dirk

[Brad Baillio]

Ok, cool.  I failed to connect, in my brain, that you need the ROS1 custom message sourced AND the ROS2 custom message sourced before you compile the bridge.

Once I did that, it all came together.

Thanks again!

[Jack O'Quin]

On Mon, Apr 4, 2016 at 3:43 PM, Brad Baillio <brad.b...@gmail.com> wrote:

Ok, cool.  I failed to connect, in my brain, that you need the ROS1 custom message sourced AND the ROS2 custom message sourced before you compile the bridge.

Once I did that, it all came together.

Cool! I would be very interested to see the results of your work on this, Brad. 

--

 joq

[Brad Baillio]

Sure thing.

I kind of cannibalized the Velodyne driver supplied for ROS1.

I ripped out a ton of stuff to begin with and just repurposed the driver portion to get the raw packets and put them into the VelodyneScan message.

Then I use the other half of the ROS1 velodyne code to grab the VelodyneScan and convert it to PointCloud2.

The bridge facilitates the 2to1 translation.

Viewing Puck data in RViz right now. :-)

My next task is to see if I can do the translation to PointCloud2 in ROS2-land.

[Brad Baillio]

I'm still a super-noob with ROS, so I was really aiming at just brute-forcing the ROS1 code to be functional.

Jack, I didn't realize that you're the author of that code, until now. :-)

I essentially ripped out all the parameter/config stuff. Plus I had to brute-force some of the PointCloud2 packing since PCL isn't ported to ROS2 yet.

But I have a working prototype of the velodyne_driver node and the cloud_node running in the ROS2 framework with hard-coded params for working with a VLP-16 only. With the addition of the bridge and a simple PointCloud2 passthrough, I can view data in RViz using a fully-realized ROS2 velodyne driver. :-)

There is a noticeable lag issue I've got to figure out and then slowly add back in the config stuff. So still lots of work to do. But exciting none-the-less.

[Brian Gerkey]

That's great news! Please keep us posted and report problems that you
run into along the way.

Did you find the (incomplete) migration guide
(http://design.ros2.org/articles/migration_guide_from_ros1.html) to be
of any use? Given that you're going through the process right now, it
would be invaluable to capture your experience in an improved version
of that guide. Would you be willing to contribute your notes? Perhaps
we should move it from the design site to the github wiki
(https://github.com/ros2/ros2/wiki), where it can be a more fluid
document.

[Brad Baillio]

I didn't use that doc at all.  I'll take a look at it now to see if it would have been helpful.

I've been dinking around with OpenSplice DDS and the ROS2 examples for weeks now, so I've got a pretty good handle on what that looks like.

It's mostly the ROS1 stuff that I just never got too deep into in my career so far.

So I'll look at the doc and would be happy to contribute any notes on my experience.

[Jack O'Quin]

On Tue, Apr 5, 2016 at 1:55 PM, Brad Baillio <brad.b...@gmail.com> wrote:

I'm still a super-noob with ROS, so I was really aiming at just brute-forcing the ROS1 code to be functional.

Jack, I didn't realize that you're the author of that code, until now. :-)

I am one of many authors, but I do maintain it, and that's been hard to keep up with, lately.

I essentially ripped out all the parameter/config stuff. Plus I had to brute-force some of the PointCloud2 packing since PCL isn't ported to ROS2 yet.

But I have a working prototype of the velodyne_driver node and the cloud_node running in the ROS2 framework with hard-coded params for working with a VLP-16 only. With the addition of the bridge and a simple PointCloud2 passthrough, I can view data in RViz using a fully-realized ROS2 velodyne driver. :-)

There is a noticeable lag issue I've got to figure out and then slowly add back in the config stuff. So still lots of work to do. But exciting none-the-less.

People normally run the driver and the point cloud conversion as nodelets in a single process to save sending two or three megabytes per second (depending on model) through a socket connection with the required serialization and deserialization. 

It would not surprise me for there to be noticeable delays when running through the bridge.

--

 joq

[Geoffrey Biggs]

> On 2016/04/06, at 4:55, Brian Gerkey <ger...@osrfoundation.org> wrote:
>
> That's great news! Please keep us posted and report problems that you
> run into along the way.
>
> Did you find the (incomplete) migration guide
> (http://design.ros2.org/articles/migration_guide_from_ros1.html) to be
> of any use? Given that you're going through the process right now, it
> would be invaluable to capture your experience in an improved version
> of that guide. Would you be willing to contribute your notes? Perhaps
> we should move it from the design site to the github wiki
> (https://github.com/ros2/ros2/wiki), where it can be a more fluid
> document.

Although we can all contribute to it now via pull requests, the wiki approach would be much simpler and fluid. I support moving it to a wiki.

Geoff

[Jack O'Quin]

On Tue, Apr 5, 2016 at 5:01 PM, Geoffrey Biggs <gbi...@killbots.net> wrote:

> On 2016/04/06, at 4:55, Brian Gerkey <ger...@osrfoundation.org> wrote:
>
> That's great news! Please keep us posted and report problems that you
> run into along the way.
>
> Did you find the (incomplete) migration guide
> (http://design.ros2.org/articles/migration_guide_from_ros1.html) to be
> of any use? Given that you're going through the process right now, it
> would be invaluable to capture your experience in an improved version
> of that guide. Would you be willing to contribute your notes? Perhaps
> we should move it from the design site to the github wiki
> (https://github.com/ros2/ros2/wiki), where it can be a more fluid
> document.

Although we can all contribute to it now via pull requests, the wiki approach would be much simpler and fluid. I support moving it to a wiki.

+1 

I found the pull requests too cumbersome when I tried to contribute a while back. They are fine for reviewing changes to stable, infrequently-updated documents, like REP's. Not so good for rapidly-evolving material.

--

 joq

[Brian Gerkey]

New location for the migration guide:

https://github.com/ros2/ros2/wiki/Migration-Guide