What is the best way to perform query and response over Tcp/Ip network?

asked 2017-04-19 21:29:47 -0500

updated 2017-04-19 21:31:22 -0500

Hello All,

ROS distro: Indigo

Ubuntu 14.04

I have been trying to do some query and response with my sensor using TCP/IP protocol. However, after proceeding to some extent, I totally doubt the efficiency of what I am writing. I would really appreciate any input or advice on the same. So here is the scenario:

I have a sensor that takes in data packets (Modbus data packets, don't worry about Modbus) as query throws out response in data packets over TCP/IP network (all using static IP). My work can divide into 3 sequences as of now. Each sequence consists of a series of query and response using these data packets. I already have the TCP socket communication established. So no worries about that. My data packets are in HEXADECIMAL format. E.g.

{0x00, 0x84, 0x00, 0x00, 0x00, 0x06, 0x54, 0x01, 0x00, 0x01, 0x00, 0x03};

Now based on the type of response I get from the sensor my Robot vehicle and arm moves accordingly, i.e. unless this sensor signals that it is ok to move the arm shall not move. My approach was to create nodes and subscribe to a topic lets say "write" that would write to the sensor and listen to a topic let say "read" that publishes from this network and based on the response and write back to "write" again same. In between also thought of sending out the status i receive as another topic for my arm to subscribe to and based on that it would move.

However, now my concerns:

  1. I believe I am oversimplifying the case in hand. The code or my approach doesn't look efficient.
  2. My hex packets need to be sent as strings as my TCP send function that I am inheriting from my TCP class only supports string messages ( don't want to change that ). I don't have an issue with that, as I can change the hex packet to decimal manually and convert it to string or some conversion, however it becomes tedious when I need to do that at every step after every few seconds or milliseconds slowing down the process heavily. What would be a good approach to make this happen in a faster way?
  3. I might consider these sequences as an action (not much oriented with actionlib yet), and send out statuses. That is what is expected from me, however, that is a later stage.
  4. The response is a not human readable string. How can I decode it and access specific bytes/bits and read the sensor status? To be specific, my packets have header bytes and then the tail bytes contains the message.
  5. Is the topic approach good? What else can I do to make the messaging and response more efficient?

I would further edit my question. It's already long, let's do step by step. Thanks in advance.

edit retag flag offensive close merge delete

Comments

I'm having a hard time following your question due to all of the generalities. I might be easier to explain the specifics of the messaging protocol and the desired interactions with your ROS system.

ahendrix gravatar image ahendrix  ( 2017-04-20 02:39:00 -0500 )edit

Got packets to send over tcp network and query and listen back and forth. What would be the best way to do it. The packets are in Hexadecimals. I need to send em in string. Also the response is in string which needs to be interpreted. Particular bytes need to be accessed and status of the [cont]

arunavanag gravatar image arunavanag  ( 2017-04-20 03:19:03 -0500 )edit

[cont] sensors need to be broadcasted as a message for my robot. That is all I can get specific. What I wanna achieve is to avoid the tedious conversion every time I send out and tedious interpretation every time I receive the packets. Some mechanism should do it for me.

arunavanag gravatar image arunavanag  ( 2017-04-20 03:21:21 -0500 )edit

Right now planning to break down my each process into number of actions. Each action would contain exchange of data packets and at the end of each action I will have a result broadcasted as message. However I am open to other advices. @ahendrix

arunavanag gravatar image arunavanag  ( 2017-04-20 03:22:52 -0500 )edit