Aaron Lahman - MSFT

RoboticsCommon.dll (and Proxy) contains some generic interfaces that are becoming standard for robot implementations (ex: drive.html, motor.html, encoder.html). I noticed the Visual Studio documentation has a one-sentence description for each member of the state for the contract.

1) Do any documents exist for the invariants for each message type

2) Do any documents exist for specify which parts of the state are optional for each contract

3) For example, in samples\Config, the manifests for the Lego NXT robots always omit the MotorState.Pose member -- when writing an orchestrator, can i count on motorStatePose == NullPose means that the parameter is not in use As well, how should I interpret this if it isn't set to 0 Is this the location of the motor's axle, the location of the typical contact point of the wheels, should orchestrators assume the pose can change over time (ie, a 'transformer', such as a robot arm)

It would be helpful to have some specifications on these contracts so that I can implement and test them correctly.

Thanks,

#aaron



Re: Microsoft Robotics - Hardware Configuration and Troubleshooting Where's the documentation for the generic contracts?

George Chrysanthakopoulos

Hi Aaron, currently the generic contracts are not documented. They are only indirectly documented through

1) the description attributes on every class and every field, of every contract (which is used by VPL to describe them to users building diagrams)

2) the reference samples

In general the schema (the structure) of a generic contract type, like the state for example for a generic drive, can vary within the limits of the C# language. So some fields can be null for some services implementing, others will not be in other instances. I would not assume the presense of a reference field on one contrte implementation, as saying that field is always non null.

What is important however, is that all services faithfully implement all DsspOperations of a generic contract in a handler, and at least respond to a message ( a fault indicating not implemented is acceptable as an intermediate step)

The DssPatterns wiki would be a good way to start documenting further these contracts, but so far, by keeping them simple, they are fairly easy to use (at least most of them).

As we start seeing our partners release commercial bots, you will see more of the fields that are now empty (like Pose for example) to be consistently used.

We are also at the same time willing to adjust the contracts, based on use cases from the field.

We will also do a better job aggregating links to all the services people have created using MSRS, so people can find them more easily.