Implementing Client Libraries

NOTE: this page is just a collection of notes right now. Apologies.

It is highly recommended that you read the ROS Technical Overview first. It describes the general interaction of these APIs.

At a minimum, a client library MUST:

• implement the slave side of the master/slave API. This involves managing an XML/RPC server, and issuing and responding to XML/RPC requests.

• handle node-to-node transport negotiation and connection setup. A client library may only support a subset of the possible transport mechanisms, most likely ROS/TCPROS

• handle transport-specific serialization and deserialization of messages.

A client library SHOULD also:

• parse command-line Remapping Arguments. A node that cannot do this will not be reconfigurable.

• Subscribe to a simulated Clock

• publish debugging messages to rosout

• depend on the roslang package, which allows rosbuild and other tools to perform appropriate actions, such as msg- and srv-based code generation

In addition, client libraries generally offer other features, such as:

• object representation of message types
• event loop for connection servicing
• user callback invocation on message receipt

Message generation

Message generators commonly include two fields within the generated source code that is required during Topic/Service connection:

• md5sum: this is computed by roslib/scripts/gendeps --md5 msg-file

• Message definition: this is computed by roslib/scripts/gendeps --cat msg-file

Topic/Service Connection

Nodes usually spin up a TCP/IP server socket to receive both TCPROS-based Topic connections as well as all Service connections. The client will send the server a ROS/Connection_Header, which can be used the route the inbound connection to the appropriate Topic/Service handler. For more information on these fields, see the ROS/Connection_Header documentation.