0
$\begingroup$

Rosanswers logo

Hi all!

Following my previous opened thread,

http://answers.ros.org/question/43810/about-tcp-protocol-implementation/

Instalation:

Ubuntu lucid 32bits

ROS Fuerte

Pharo 1.4 / CogVM version 'CoInterpreter VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Aug 13 2012, StackToRegisterMappingCogit VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Aug 13 2012, https://git.gitorious.org/cogvm/blessed.git Commit: aeb0705cde4b8fc57cb262dc051c5ee6dfa72a14 Date: 2012-07-26 16:38:48 +0200 By: Igor Stasenko [email protected]'

I implemented all the Slave API, and finally i have an opened channel with the turtle.

Since beginning to this point i have manage:

PharoNode >> Master: registerPublisher '/turtle1/command_velocity'

Master: >> PharoNode here is the IP:PORT of XMLRPC of the intereseted in this topic

Turtle >> PharoNode: Protocol?

PharoNode >> Turtle: TCPROS IP:PORT

RosTopic-Echo >> PharoNode: Protocol?

PharoNode >> RosTopic-Echo: TCPROS IP:PORT

Turtle >> connectTo:IP:Port. Send connection message. Just a Connection header without data.

RosTopic-Echo >> connectTo:IP:Port. Send connection message. Just a Connection header without data.

PharoNode >> Turtle: send back a connection message, asking for a movement.

PharoNode >> RosTopic-Echo: send back a connection message, asking for a movement.

In both last responses the message is the same:

    |header| 

    callerId:'anArbitraryId';
md5Sum:'9d5c2dcd348ac8f76ce2a4307bd63a13';
type: 'turtlesim/Velocity'; 
latching: true.

 | body |

      linear: 2.0 angular: 0.0

After this, the turtle move 2.0 to the right and the rostopic-echo just print linear: 2.0 angular: 0.0

At this point the rxgraph shows me something like:

(/anArbitraryId)---> [ /velocity ] --->( /turtlesim ) --> [/rosOut|/turtle1/color_sensor|/turtle1/pose]

But then, if i send an other message to the turtle-related socket or to the rostopic-echo related socket, nothing happens. nothing at all.

I looked at the documentation, but it dont say a lot about implementation.

Then i browsed ROS implementation, starting from teleop_turtle_key.cpp and reaching tcp_transport.cpp, and as far as i understood about the code related to TCPROS transport, it dont look to do nothing weird, just send the bytes of the message (in the case of turtle/Velocity, it may send two float32)

The messages i tried to send at this point are the follow

linear: 2.0 angular: 0.0

NOTE: this means just the 8 bytes related to the message. 
    EDIT: 
      the dump of the byte array im tryinto send to the turtle in this case is
      #[0 0 0 64 0 0 0 0] in hex '[0000004000000000]'

0000000000000000000000000000000000000 

    Note: this means a block of 0s or 2s, just to force a log or something, but without success :( 

I tried to implement some of the subscriber logic, and use the /turtle1/pose topic

trying to understand (by hand) the shape of the stream i realized that there are a word that doesnt match with the type format:

expecting these values (in this order) 4.72179222107 #[236 24 151 64]

7.13545799255 #[172 85 228 64].

4.0640001297 #[74 12 130 64].

0.0 #[0 0 0 0].

0.0 #[0 0 0 0].

i received the following bytes (as part of a longer stream)

228 64 74 12 130 64 0 0 0 0 0 0 0 0 20 0 0 0 236 24 151 64 172 85

matching with the expected values, and sorting by expected position:

236 24 151 64

172 85 228 64

74 12 130 64

0 0 0 0

0 0 0 0

[ 20 0 0 0 ] Here, this guy have nothing to do with the rest of the message, but appear in the stream splitting the messages. So, i tried using all the permutations of this word at the beginning and the end of the message with out any success.

It could be related? do i need to send a trail-word? I searched in google about ROS and trails without success too.


In order to get more information i just sniff the conections with wireshark

the hexadecimal sent by the teleop_turtle_key for a rotation (0.0 2.0) is

080000000000000000000040

[8 0 0 0 0 0 0 64 0 0 0 0] in bytes

grouping the bytes in 32 bits words (or 32bits float representation)

8 0 0 0 0 0 0 64 0 0 0 0 [ * ] [ 2.0 ] [ 0.0 ]

  • in float representation is 1.1210387714598537e-44 in integer representation is 8

Someone knows why is there?

Finally i just sent this stream from my client to the turtle and the topic without any success :(

Any ideas? Any place to see? Thank you in advice!


Originally posted by sbragagnolo on ROS Answers with karma: 203 on 2012-09-21

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

You don't get any error messages about the turtlesim_node rejecting packages, do you? Also I don't understand why you differentiate between header and body in your question. After connection negotiation, you have socket that you keep open. The header is only transmitted when connecting. Then only messages are sent. First you have to transmit the length of the message as an int32 and then the serialized message itself.

Maybe you can be a little more specific and provide us a hexdump of what exactly you are sending over the socket?

Edit: Just to explain the data you sniffed with wireshark. You saw three 32bit numbers. The first one is an integer that indicates the number of bytes to follow, i.e. the payload is 8 bytes. Then the first 4 bytes are the float32 representation of the linear velocity and the next 4 bytes are the float32 representation of the angular velocity. If you send exactly that over a socket that you just created when the subscriber connects, you should be fine. But note when the subscriber connects you will receive a header containing the topic, md5 sum, caller id etc. The publisher then needs to send a header containing the type, caller id, the message definition, if the topic is latched and the md5 sum. After that, the publisher should be able to just send the serialized messages as you've seen on wireshark.


Originally posted by Lorenz with karma: 22731 on 2012-09-21

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.