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.

Wiki: Implementing Client Libraries (last edited 2011-07-13 21:40:55 by VijayPradeep)