Generic adapter for TCP / UDP / serial communications?
I am writing driver nodes that control various sensors attached to my CPU. For instance, NMEA messages come from a GPS-enabled device over UDP, while temperature readings are reported over serial.
I could write the thermometer driver node to specifically listen for messages over serial, but this seems like a separation-of-concerns violation.
Instead I think I'd rather have a generic serial driver, and a generic UDP driver, and a generic TCP driver, which all publish a generic line message type, then my thermometer driver could be configured to subscribe to the appropriate topic where these lines are coming in, without caring what communication method is being used upstream.
Is there an existing standard package that would offer this? It's not hard to write myself of course, but I'd like to not reinvent the wheel.
(To emphasize one point, this isn't about sending serialized ROS messages over serial or UDP or whatever.)
At least for serial there have been some, and the velodyne_driver package follows a similar design pattern (ie: dedicated nodelet handles network traffic and (initial) deserialisation, other nodelet(s) convert to ROS msgs).
I'm not aware of anything that would be a standard "goto implementation" you could reuse (but that doesn't mean there aren't any of course).
Three reasons why I believe node authors often decide to not separate these concerns:
asio
for C++ orpyserial
for Python, it takes only a few lines of code to get something to workFinally: network and ...(more)
.. typically not examples of shared resources, and require specific interaction patterns to function correctly. Both at the level of the transport, and at the level of communication with whatever is "on the other side".
While that does seem like a responsibility/concern which could be nicely separated -- and some packages that bridge systems like CAN(open)/Ethercat/etc do just that -- it also has a tendency to couple nodes (ie: the bridge and the nodes talking to the bridge), as now two nodes need to work together to maintain proper ordering of messages (fi). This is especially true if the transport/comms channel being wrapped/bridged has no or a different concept of addressing, or doesn't support asynchronous messaging.
Note: I'm not saying your idea is not a good one. I just wanted to discuss it a bit.
That's also why this is not an answer.
I ...(more)