ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

In that case I don't believe you'd "integrate" anything with ROS: ROS is transport-layer agnostic, so as long as you have an IP network available, everything 'should just work'.

Note: I have no experience with DSRC, but if packet loss and transport delays are common events, ROS 1 will probably ..

Yes, I essentially want to use it as a transport layer to communicate between infrastructure and my autonomous vehicle.

In that case I don't believe you'd "integrate" anything with ROS: ROS is transport-layer agnostic, so as long as you have an IP network available, everything 'should just work'.

Note: I have no experience with DSRC, but if packet loss and transport delays are common events, ROS 1 will probably ..not work very well, due to it using standard TCP by default. There is a UDP transport, but it's not universally supported and has some unresolved issues (no automatic fragmentation+reassembly fi).

I'd look at ROS2, or directly at technologies such as DDS. Those will be much more reliable.

If you're not looking to route IP over the radios in the device you link to, then things become rather different.

Yes, I essentially want to use it as a transport layer to communicate between infrastructure and my autonomous vehicle.

In that case I don't believe you'd "integrate" anything with ROS: ROS is transport-layer agnostic, so as long as you have an IP network available, everything 'should just work'.

Note: I have no experience with DSRC, but if packet loss and transport delays are common events, ROS 1 will probably not work very well, due to it using standard TCP by default. There is a UDP transport, but it's not universally supported and has some unresolved issues (no automatic fragmentation+reassembly fi).

I'd look at ROS2, or directly at technologies such as DDS. Those will be much more reliable.

If you're not looking to route IP over the radios in the device you link to, then things become rather different.


Edit:

Thanks so much for that info! We would definitely try to have an IP network available but it will be a little difficult.

Without IP in the mix, you're probably going to have to implement an application-level gateway that subscribes to the relevant msgs, encapsulates them properly for Wave, sends them off (using the Wave transceiver) and another gateway on the receiving side that does the opposite (ie: publish).

You could take a look at one of the many multi-master implementations for this and see how they implement such gateways.

Unfortunately we might not be able to use ROS2 because we won't be able to port our python code in ROS1 to ROS2 yet. We're also using a Velodyne which doesn't have new drivers yet

using the ros1_bridge ROS2 pkg you can connect 'islands' of ROS1 together with ROS2 comm infra. Like so: [ROS1 <-> ROS2] <-wireless-> [ROS2 <-> ROS1] ([] is one PC).

Technically this should let you use all your ROS1 nodes and benefit from the improved ROS2 networking capabilities.

Yes, I essentially want to use it as a transport layer to communicate between infrastructure and my autonomous vehicle.

In that case I don't believe you'd "integrate" anything with ROS: ROS is transport-layer agnostic, so as long as you have an IP network available, everything 'should just work'.

Note: I have no experience with DSRC, but if packet loss and transport delays are common events, ROS 1 will probably not work very well, due to it using standard TCP by default. There is a UDP transport, but it's not universally supported and has some unresolved issues (no automatic fragmentation+reassembly fi).

I'd look at ROS2, or directly at technologies such as DDS. Those will be much more reliable.

If you're not looking to route IP over the radios in the device you link to, then things become rather different.


Edit:

Thanks so much for that info! We would definitely try to have an IP network available but it will be a little difficult.

Without IP in the mix, you're probably going to have to implement an application-level gateway that subscribes to the relevant msgs, encapsulates them properly for Wave, sends them off (using the Wave transceiver) and another gateway on the receiving side that does the opposite (ie: publish).

You could take a look at one of the many multi-master implementations for this and see how they implement such gateways.

Unfortunately we might not be able to use ROS2 because we won't be able to port our python code in ROS1 to ROS2 yet. We're also using a Velodyne which doesn't have new drivers yet

using the ros1_bridge ROS2 pkg you can connect 'islands' of ROS1 together with ROS2 comm infra. Like so: [ROS1 <-> ROS2] <-wireless-> [ROS2 <-> ROS1] ([] is one PC).PC / ros nodegraph).

Technically this should let you use all your ROS1 nodes and benefit from the improved ROS2 networking capabilities.

Yes, I essentially want to use it as a transport layer to communicate between infrastructure and my autonomous vehicle.

In that case I don't believe you'd "integrate" anything with ROS: ROS is transport-layer agnostic, so as long as you have an IP network available, everything 'should just work'.

Note: I have no experience with DSRC, but if packet loss and transport delays are common events, ROS 1 will probably not work very well, due to it using standard TCP by default. There is a UDP transport, but it's not universally supported and has some unresolved issues (no automatic fragmentation+reassembly fi).

I'd look at ROS2, or directly at technologies such as DDS. Those will be much more reliable.

If you're not looking to route IP over the radios in the device you link to, then things become rather different.


Edit:

Thanks so much for that info! We would definitely try to have an IP network available but it will be a little difficult.

Without IP in the mix, you're probably going to have to implement an application-level gateway that subscribes to the relevant msgs, encapsulates them properly for Wave, sends them off (using the Wave transceiver) and another gateway on the receiving side that does the opposite (ie: publish).

You could take a look at one of the many multi-master implementations for this and see how they implement such gateways.

Unfortunately we might not be able to use ROS2 because we won't be able to port our python code in ROS1 to ROS2 yet. We're also using a Velodyne which doesn't have new drivers yet

using the ros1_bridge ROS2 pkg you can connect 'islands' of ROS1 together with ROS2 comm infra. Like so: [ROS1 <-> ROS2] <-wireless-> [ROS2 <-> ROS1] ([] is one PC / ros nodegraph).

Technically this should let you use all your ROS1 nodes and benefit from the improved ROS2 networking capabilities.

Yes, I essentially want to use it as a transport layer to communicate between infrastructure and my autonomous vehicle.

In that case I don't believe you'd "integrate" anything with ROS: ROS is transport-layer agnostic, so as long as you have an IP network available, everything 'should just work'.

Note: I have no experience with DSRC, but if packet loss and transport delays are common events, ROS 1 will probably not work very well, due to it using standard TCP by default. There is a UDP transport, but it's not universally supported and has some unresolved issues (no automatic fragmentation+reassembly fi).

I'd look at ROS2, or directly at technologies such as DDS. Those will be much more reliable.

If you're not looking to route IP over the radios in the device you link to, then things become rather different.


Edit:

Thanks so much for that info! We would definitely try to have an IP network available but it will be a little difficult.

Without IP in the mix, you're probably going to have to implement an application-level gateway that subscribes to the relevant msgs, encapsulates them properly for Wave, sends them off (using the Wave transceiver) and another gateway on the receiving side that does the opposite (ie: publish).

You could take a look at one of the many multi-master implementations for this and see how they implement such gateways.

Unfortunately we might not be able to use ROS2 because we won't be able to port our python code in ROS1 to ROS2 yet. We're also using a Velodyne which doesn't have new drivers yet

using the ros1_bridge ROS2 pkg you can connect 'islands' of ROS1 together with ROS2 comm infra. Like so: [ROS1 <-> ROS2] <-wireless-> [ROS2 <-> ROS1] ([] is one PC / ros nodegraph).

Technically this should let you use all your ROS1 nodes and benefit from the improved ROS2 networking capabilities.


Edit2:

Thanks so much for your suggestions. I'm not very knowledgeable in communication theory so please tell me if I'm understanding this right: If I make available an IP network using a router, my publisher node will contact the subscriber (through the Master) and decide the protocol (say TCP). After that the message is sent from the computer to the radio device (perhaps via ethernet) and published using radio as the communcation media. On the receiver side the radio device transmits the message to the computer (again via ethernet) and finally reaches the subscriber. Does this sound right?

Network stacks are layered. At some layer (IP), what you describe is correct. But at the application layer (ie: where ROS messages 'live'), depending on the exact configuration and setup, the router is transparent in the sense that ROS nodes on one side of it can receive traffic from the other side without realising that there is a router in between (in the same way that your web browser does not realise there are 10 routers between you and Google fi).

But all of this is getting rather off-topic: IP networking - even if for V2V or V2I - is not a ROS topic, so best discussed on a more appropriate forum.

If you are not going to use an IP network with this, then, as I wrote earlier, things become different.

And just to reiterate: you don't have to use an IP network if that is not the best way to make use of the capabilities of the DSRC networking stack. As I wrote: I don't have any direct experience with the technology, so I advise you to seek some more expert knowledge.