unknown_entity1's profile - activity

Dear ROS Supporters,

Why is a ROS UDP Datagram support limited to a block size under 2K? TCP/IP v4 supports a Datagram up to 65535, while IPv6 supports TCPIP, and UDP Jumbogram up to 4GB. It seems that the video latency due to increased CPU processing, and network message bandwidth decrement justifies larger UDP block sizes?

Any constructive input will be appreciated.

Thanks,

Aaron

Dear ROS Community,

How can we setUp turtlesim to support UDPROS topics/services? I'd like to test my ROS Client UDPROS implementation on ROS Subscriber Topics, and Services, and do not know what to configure to achieve this.

Thanks,

Aaron

Hi ROSAnswers Friends,

I have been developing my own Java based ROS Client, and I am receiving the following error: Below is the message I am attempting to process in the form of a Java byte array. The protocol finished the getTopic method via XMLRPC, and now is my Robot controllers attempt to obtain the following Topic via the returned TCPROS protocol message: public final static byte[] MESSAGE={(byte)0xd6,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x20,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x63,(byte)0x61,(byte)0x6c,(byte)0x6c,(byte)0x65,(byte)0x72,(byte)0x69,(byte)0x64,(byte)0x3d,(byte)0x2f,(byte)0x72,(byte)0x6d,(byte)0x64,(byte)0x6d,(byte)0x69,(byte)0x61,(byte)0x18,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x74,(byte)0x6f,(byte)0x70,(byte)0x69,(byte)0x63,(byte)0x3d,(byte)0x2f,(byte)0x63,(byte)0x6c,(byte)0x6f,(byte)0x63,(byte)0x6b,(byte)0x4e,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x6d,(byte)0x64,(byte)0x35,(byte)0x73,(byte)0x75,(byte)0x6d,(byte)0x3d,(byte)0x61,(byte)0x39,(byte)0x63,(byte)0x39,(byte)0x37,(byte)0x63,(byte)0x31,(byte)0x64,(byte)0x32,(byte)0x33,(byte)0x30,(byte)0x63,(byte)0x66,(byte)0x63,(byte)0x31,(byte)0x31,(byte)0x32,(byte)0x65,(byte)0x32,(byte)0x37,(byte)0x30,(byte)0x33,(byte)0x35,(byte)0x31,(byte)0x61,(byte)0x39,(byte)0x34,(byte)0x34,(byte)0x65,(byte)0x65,(byte)0x34,(byte)0x37,(byte)0x30,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x74,(byte)0x79,(byte)0x70,(byte)0x65,(byte)0x3d,(byte)0x72,(byte)0x6f,(byte)0x73,(byte)0x67,(byte)0x72,(byte)0x61,(byte)0x70,(byte)0x68,(byte)0x5f,(byte)0x6d,(byte)0x73,(byte)0x67,(byte)0x73,(byte)0x2f,(byte)0x43,(byte)0x6c,(byte)0x6f,(byte)0x63,(byte)0x6b};

Can anybody tell me what is wrong with the above message?

Thanks,

Aaron

Per the wiki on ROSUDP, the UDP Header starts out with Connection ID (8 bytes), Opcode (1 byte), Msg ID (1 byte), and Block Number(unspecified byte length).

What is the byte length of Block#? and what additional fields are missing from the documentation that are required by ROSUDP preceding the Connection Header and Message? I did a UDP trace using Wireshark, and I am not able to explain some of the bits. All help will be appreciated!

Thanks,

Aaron

Connection ID - This 32-bit value is determined during connection negotiation and is used to denote which connection the datagram is destined for. This parameter allows a single socket to service multiple UDPROS connections.

Opcode - UDPROS supports multiple datagram types. The opcode specifies the datagram type. This 8-bit field can have the following possible values:

DATA0 (0) - This opcode is sent in the first datagram of a ROS message
DATAN (1) - All subsequent datagrams of a ROS message use this opcode
PING (2) - A heartbeat packet is sent periodically to let the other side know that the connection is still alive
ERR (3) - An error packet is used to signal that a connection is closing unexpectedly

Message ID - This 8-bit value is incremented for each new message and is used to determine if datagrams have been dropped.

Block # - When the opcode is DATA0, this field contains the total number of UDPROS datagrams expected to complete the ROS message. When the opcode is DATAN, this field contains the current datagram number.

Dear ROS Answers Users,

Does the TCPROS probe connection header field work on topics?

Thanks,

Aaron

Update: Unknown Error XMLRPC message on requestTopic for UDPROS is caused by invalid base64 UDPROS connection header.

@ahendrix - reading the roscpp tutorials, generating talker and listener, then replacing listener with unreliable_listener did the trick. I did not understand the prerequisites of your suggestion, but after a few hours of research I came up with the following Request and Response for requestTopic on XMLRPC for UDPROS (Now I know why multiple implementers have built the UDPROS, and not finished them. The state of my client the last year was hung up on the missing requestTopic documentation that is required to establish a connection on the UDPROS Clients components I wrote. I hope this helps other ROS Client implementers - if you decode the base64 you will discover it is the typical connection header parameters from TCPROS Protocol being passed in as base 64 String. Behavior Note: The Subscriber port is connected to from the Publisher, and in the test I performed the Publisher Port did not match the response port provided by the Publisher in the XMLRPC Request):

POST / HTTP/1.1 User-Agent: XMLRPC++ 0.7 Host: thyatira:46120 Content-Type: text/xml Content-length: 590

<?xml version="1.0"?> <methodCall><methodName>requestTopic</methodName> <params><param><value>/listener_unreliable</value></param><param><value>/chatter</value></param><param><value><array><data><value><array><data><value>UDPROS</value><value><base64>HQAAAGNhbGxlcmlkPS9saXN0ZW5lcl91bnJlbGlhYmxlJwAAAG1kNXN1bT05OTJjZThhMTY4 N2NlYzhjOGJkODgzZWM3M2NhNDFkMQ4AAAB0b3BpYz0vY2hhdHRlchQAAAB0eXBlPXN0ZF9t c2dzL1N0cmluZw==</base64></value><value>thyatira</value><value><i4>39861</i4></value><value><i4>1500</i4></value></data></array></value></data></array></value></param></params></methodCall>

HTTP/1.1 200 OK Server: XMLRPC++ 0.7 Content-Type: text/xml Content-length: 569

<?xml version="1.0"?> <methodResponse><params><param> <value><array><data><value><i4>1</i4></value><value></value><value><array><data><value>UDPROS</value><value>thyatira</value><value><i4>33184</i4></value><value><i4>1</i4></value><value><i4>1500</i4></value><value><base64>EAAAAGNhbGxlcmlkPS90YWxrZXInAAAAbWQ1c3VtPTk5MmNlOGExNjg3Y2VjOGM4YmQ4ODNl YzczY2E0MWQxHwAAAG1lc3NhZ2VfZGVmaW5pdGlvbj1zdHJpbmcgZGF0YQoOAAAAdG9waWM9 L2NoYXR0ZXIUAAAAdHlwZT1zdGRfbXNncy9TdHJpbmc=</base64></value></data></array></value></data></array></value> </param></params></methodResponse>

I spoke to soon. The stack trace shows that requestTopic is passing in TCPROS as the protocol. I wonder why the UDPROS example is running TCPROS? POST / HTTP/1.1 User-Agent: XMLRPC++ 0.7 Host: thyatira:46487 Content-Type: text/xml Content-length: 302 <methodcall><methodname>requestTopic</methodname> <params><value>/rosout</value><value>/rosout</value><value><array><data><value><array><data><value>TCPROS</value></data></array></value></data></array></value></params></methodcall>

Thank you ahendrix! That is exactly what I needed! Aaron

I'm contemplating building a new controller board for this purpose, to integrate with my java based autonomous robot controller. Nothing I've found available off the shelf has low enough latency response times, power usage, and high enough system resources to handle hundreds of simultaneous ros topics/services and equal numbers of high speed low latency hardware connections.

Is it possible somebody who has a functional UDP Subscriber implemented can perform a Wireshark trace on the XML in the XMLRPC call and post it as the answer to this question?

It will help me out greatly, as I will be able to cross reference what my client is sending vs what is supposed to be sent.

My Java client calls requestTopic by passing in an array of String Protocol names (I am aware the ROS Java client does not support UDPROS, this is a different client). If I pass in using TCPROS, followed by UDPROS, then XMLRPC returns correct protocol information on TCPROS the default protocol. If I reverse the order, or only specify UDPROS, ROS returns an Unknown Error message. I've traced it back to a ROS cpp method called requestTopicCallback (or something like that, I was debugging this morning, and may be off on the exact method name).

All help will be appreciated!

Sincerely,

Aaron

Thanks Austin, I see a need for this, and I am going to add proxy support to the Happy Artist Java based ROS Client. Aaron

This seems like a must have for any TCP/IP connection. Does anybody else feel this way if it is not currently implemented?

Dear ROS Community,

Does ROS support proxy connections (like SOCKS) between client/server (to get through firewalls/VPNs)?

Thanks,

Aaron

Dear ROS Supporters,

Is there developer documentation for TCPROS connection header probe attribute for discovery?

Thanks,

Aaron

I believe probe was used by rossrv for introspecting service type information that is not available via the XMLRPC API. This made me wonder what else is not documented. I've been working on a Java client for over a year, and this sort of information would of been like gold. My client did discovery of service types via an auto-generated shell script that is not platform independent, and required the user to manually run the script, then import the discovered data to the client.

This data trace was performed in February 2014 on the latest version of ROS.

The changelist at the following URL mentioned the probe... http://wiki.ros.org/ROS/ChangeList/1.2

The following is the Hex of a Wireshark data trace: 410000000e000000736572766963653d2f737061776e0700000070726f62653d311400000063616c6c657269643d2f726f7373657276696365080000006d643573756d3d2a The following is printable text of the above hex string: service=/spawn probe=1 callerid=/rosservice md5sum=*

Is Latching handled by the Master or Node?

Thanks,

Aaron

Dear ROS Community,

My recent adventure into development of a Java based UDPROS protocol left me with some unanswered questions that will be beneficial for the ROS Community to discuss, and create a specification of some sort.

Single Packet Message issues:

• Issue 1: Out of Order message handling.
• Issue 2: Dropped message handling.

Multi-Packet Message issues:

• Issue 1: Dropped Datagram Packets in a single message.
• Issue 2: Out of sequence datagram packet handling.

• Issue 3: Timeout before dropping message entirely, or passing on received data with missing packets.

• Option 1: Drop entire message immediately if a received datagram contains a new message id, and the preceding multi-packet message is incomplete.

• Option 2: Wait for messages to complete in any/every order until a timeout is reached regardless of order until the entire message is received, and pass message into a topic queue. Drop message if message times out.

Both options have advantages depending on the topic type, and robot requirements. Option 2 requires more processing power and energy usage to maintain timeouts, and Option 2 handles out of sequence/out of order messages/packets. Option 1 performs more quicker/efficiently, at the cost of more lost messages. Both options seem like they could be valuable if they are implemented in the UDPROS API.