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.
