When deriving methods that contend with examining an incoming message object and/or creating messages to send there are several key considerations to take into account.

  • presence vector
  • optional vs required fields and supported capabilities
  • configuration vs capabilities


Presence Vector

The presence vector will have a specific intent depending upon the message type.

For the query and command(set) type messages the presence vector will indicate what optional fields of a record the requester would like to receive information about or what optional fields the requester would like to alter.

For the inform(report) type messages the presence vector indicates what fields of a record will have valid data.


When responding to query messages that contain a presence vector it cannot be assumed that the query will request all of the fields that the robot is capable of providing data for. 

Thus, it is best to examine the query's presence vector and only provide data for the fields that are being requested and that the robot supports. This implies that the presence vector of the outgoing message consist of the logical AND of the query's presence vector and the robot's supported fields.


When handling an incoming command(set) message that has a presence vector it is not good practice to simply set all of the values related to the service that the robot supports. This is because the values provided by the set message may contain invalid data if the presence vector for the incoming message does not indicate a particular record field is enabled. Thus, it is important to examine the presence vector and only perform operations with values that are enabled as indicated by the presence vector.


Optional vs Required Fields and Supported Capabilities

Some services utilize a capabilities related message. This provides a means for a robot to describe what aspects of a service it is capable of supporting. A report capabilities message may include records that contain fields which are listed as required (non-optional). This might be an issue for some system designs as a robot might implement a particular service but it might not implement a particular field of the services' capability record.

When this occurs, the best approach is to report a value that is not likely to disrupt the system if that value is acted upon.

If the unsupported record field represents a maximum range of some activity, report of value of zero. 

If the unsupported record field represent some modes of operation, select only one mode that best represents what the robot is capable of.

What to report will depend upon what the field represents. If the field is required then it is important to provide some reasonable value even though the robot might not actually implement it.


Configuration vs Capabilities

Services that utilize capabilities related messages might also utilize configuration related messages. This allows a robot to indicate its current configuration state for a particular service. The configuration message will contain records with fields to indicate the current mode, level, condition, etc. of some attribute. Some of these fields may be equivalent to fields present in a capabilities record of the service. Therefore it is important that the fields in a report configuration message be in sync with what was given in a report capabilities message. This implies that if a particular field of a capability record was stated to be supported the corresponding field in the  confiiguration record should provide valid data.