UDP Packet Abstraction

asked 2017-03-15 05:21:54 -0500

updated 2017-03-15 05:23:07 -0500

I have an OXTS xNav550 and have downloaded the oxford_gps_eth package for it.

It doesn't quite do what I want (only publishes once there is a gps lock and doesn't provide all the packet data). Therefore I want to modify it, so am looking at the code.

I was considering writing (or finding) a generic UDP ROS node. i.e. opens a port (optionally on a specific ethernet device and/or IP address) and publishes all incoming packets on a ROS topic. I would then write a new OXTS node (based on the Oxford source code - maybe). This would subscribe to the UDP topic.

This would have the advantage that the raw UDP packets could be logged into a ROS bag. Until every bit in the packet is published in device specific topics, this would mean prevention of loss of data which may, in future analysis, be useful. It would also mean that the device specific node could be developed away from the sensor by replaying a bag.

The disadvantage would be that there would a slight overhead in effectively retransmitting an incoming UDP node.

So, any thoughts?

  1. Is this design pattern consistent with 'the ROS way of doing things'?
  2. Does the generic UDP node already exist?
  3. Any other reason why I shouldn't do any of this?
edit retag flag offensive close merge delete

Comments

Is this [..] 'the ROS way of doing things'?

I'm not an authority, but in general I try to design my ROS nodes in such a way that they only pub/sub meaningful msgs that don't need any implementation details of other nodes to be interpretable. A transparent bridge (which your UDP node ..

gvdhoorn gravatar imagegvdhoorn ( 2017-03-15 13:58:08 -0500 )edit

.. sort of is) tends to import domain concepts from outside the ROS nodegraph into your application. That will reduce re-usability of nodes, but that could be perfectly acceptable. A pkg that does this is the velodyne driver. A set of nodelets ..

gvdhoorn gravatar imagegvdhoorn ( 2017-03-15 14:00:17 -0500 )edit
1

.. form a cooperating set where one decodes raw traffic from the sensor, uses an intermediary representation (a ROS msg) to publish the result and a subscriber then consumes that and produces 'meaningful' ROS msgs from it (PointClouds).

If you want to do this, be sure to use nodelets.

gvdhoorn gravatar imagegvdhoorn ( 2017-03-15 14:02:31 -0500 )edit