DEV304 Microsoft Robotics Studio

Martin Calsyn
Abstract:

The Microsoft Robotics Studio is a Windows-based environment for academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware. Key features and benefits of the Microsoft Robotics Studio environment include: end-to-end Robotics Development Platform , lightweight services-oriented runtime, and a scalable and extensible platform.

Diese Session besuche ich jetzt rein aus persönlichem Interesse. Wer weiss, ev, gibt es zu Weinachten ja einen Lego Mindstorm ;-)

Robbotics ist in den Anfängen, es existiert noch keine wirkliche Killer Applikation. Es gibt keine Standard Hardware und auch keine HW"abstraction".Und das "Real World testing" ist sehr teuer.

• The ‘hot buttons’ from Industry, hobbyists, academia and researchers:
• Static and dynamic device configuration
• Coordinating asynchronous device input
• Starting and stopping components dynamically and independently
• Monitoring and interacting with running systems
• Improved development cycle, particularly with limited access to robot hardware
• Spanning multiple compute units
• Reuse of software, particularly across different hardware
• Microsoft Robotics Studio addresses:
• Reusable components: Introduces a paradigm that facilitates reuse
• Standardization: Introduces a hardware abstraction paradigm
• Concurrency and distributed computing: Introduces CCR and DSS to greatly simplify these tasks
• Simulation: Introduces a high-fidelity, extensible virtual world

Barrier to Entry: Introduces a Visual Programming Language to make the advanced features more accessible to newcomers


Was ist eine Robotics Applikation ? :

• A composition of loosely-coupled and concurrently executing components providing:
• Orchestration of sensors and actuators
• User Interaction
• Control or Behavior logic

Architektur:

• Services are the basic building block
• Structured state
• Behavior
• Partner services
• Contract

• Operations
• State retrieval and manipulation
• Create and Terminate
• Notification

• Services
• Can be used to abstract hardware
• Can be composed and provide aggregated functionality (sensor fusion, for example)
• Are inherently remotable and participate in distributed operations
• Restartable and mobile (state transfer)
• Must be inherently asynchronous

• But asynchronous programming is hard!
• Sequential applications
○ Flat or incremental performance
○ Potentially poor responsiveness
• Explicitly threaded apps
○ Hardwired number of threads prefer K processors for a given workload
○ Can penalize < K processors and fail to scale to > K processors
○ Hard to write and even harder to debug



Das Programming Model:

• Zuerst muss ich den Service und die Operations deklarieren;Operations

public sealed class Contract {
public const String Identifier = "http://schemas.coroware.com/2006/10/machinedirectory.html";
}
[DataContract()]
public class MachineDirectoryState {
[DataMember]
public List Services = new List();
}
public class MachineDirectoryOperations : PortSet { }
public class Get : Get> { }
public class Replace : Replace> { }

• Declaring a Service Port
[ServicePort("/machinedirectory", AllowMultipleInstances=false)]
private MachineDirectoryOperations _mainPort = new MachineDirectoryOperations();
• Defining Partnerships
[Partner("NodeDirectory",Contract=nds.Contract.Identifier, CreationPolicy = PartnerCreationPolicy.UseExistingOrCreate)]
private nds.NodeDirectoryOperations _nds = new nds.NodeDirectoryOperations();
• Coordinating Asynchronous Tasks - A compositional, declarative pattern
protected override void Start()
{
ActivateDsspOperationHandlers();
}
[ServiceHandler(ServiceHandlerBehavior.Concurrent)]
public virtual IEnumerator GetHandler(Get get)
{
get.ResponsePort.Post(_state);
yield break;
}
[ServiceHandler(ServiceHandlerBehavior.Exclusive)]
public virtual IEnumerator ReplaceHandler(Replace replace)
{
_state = replace.Body;
replace.ResponsePort.Post(DefaultReplaceResponseType.Instance);
yield break;
}


Beispiel für einen Choice:


// Subscribe to the local node directory service
nds.Subscribe sub = new nds.Subscribe();
sub.NotificationPort = _ndsNotify;
_nds.Post(sub);
Activate(
Arbiter.Choice(
sub.ResponsePort,
delegate(SubscribeResponseType resp)
{ LogInfo("Successfully subscribed to node directory"); },
delegate(Fault fault)
{ _mainPort.Post(new DsspDefaultDrop()); })
);

• Example: Interleave
ActivateDsspOperationHandlers().CombineWith(
Arbiter.Interleave(
new TeardownReceiverGroup(),
new ExclusiveReceiverGroup(
Arbiter.Receive(true,
_ndsNotify, NdsInsertHostHandler),
Arbiter.Receive(true,
_ndsNotify, NdsDeleteHostHandler),
Arbiter.Receive(true, _dirNotify,
DirInsertHandler),
Arbiter.Receive(true, _dirNotify,
DirDeleteHandler)
),
new ConcurrentReceiverGroup()
)
);

• Services run within an execution context called a ‘node’
• Nodes expose http and SOAP/TCP endpoints



Es folgt nun eine Demo im Microsoft Robotics Sudio und er demonstriert, wie er mittels http mit den Services interagiert.

• Nun erfolgt eine Exkursion in die Visual Programming Language
• Ich kann damit joins kreieren, choices und pathways.
• Ich kann partnerships mit externen services kreieren
○ All Services (regardless of language) are available on the diagram surface
Das Studio mit seiner Visual Designer Language sieht ein wenig aus wie der Designer im Workflow. Nur es ist etwas eigenes. Dazu am Schluss mehr.

Es folgt eine Demo, wo das ganze in einem Simulator gezeigt wird. Er kann seinen Robo Steuern, Bilder anschauen von der Robo Cam. Etc. Alles, wie wenn es ein echter Robo wär. Nur eben im Simulator. Ziel ist es, das ich im Simulator wie beim echten Robo immer den selben Code verwenden kann. Somit ist auch sichergestellt, dass die Simulation "realistisch" ist. Die Tests werden so natürlich sehr viel günstiger, so kann ich etwas für eine Laser Spektrometer programmieren, ohne einen kaufen zu müssen.

• Simulation
• Cost effective
• High-fidelity
• Fast, incremental prototyping



• Entities consist of:
○ A graphical representation of your object
§ Geometric shape
§ Complex mesh with materials and textures
○ A physics representation
§ Shape, Mass, CM, friction, joints
§ Physical shape (hull) can be automatically derived from geometric shapes and complex meshes
○ An entity can have both, either or neither representation(s)

• Simulation services
○ Communicate with entities to effect changes in entity state (change position, orientation, physics attributes like torques and forces)
○ Communicate with application services through a service interface
§ This service interface should mimic the interface used for the real device on the real robot
• Application services
○ Your application code
○ Should be identical code for simulation or real-world use


Printscreen des Simulators:



Am schluss zeigt er noch Hardware, welche ich benötigen kann. (Feuchtigkeitssensor, GPS Modul, Infrarot Sensor, Temperatur Messer, und einen echten Robo. Er kann leider nichts am Robo zeigen, da es ihm anscheinend das Netzteil geschmort haben soll.

Sehr interessante Session, über die ich noch sehr viel schreiben könnte. Es ist schwierig hier das Konzept verständlich zu erklären. Typisch Microsoft ist, dass sie eine Visual Language geschaffen haben, die nur im ROBO Studio gültig ist. Hier hätte ein Konzern interner Griff zur WinWF Engine genau dieselben Ergebnisse gebracht. Dies wurde dann auch gefragt, weshalb für die Orchestrierung nicht WinWF gebraucht werde. Die Antwort: Das sei so, und vermutlich habe man nicht miteinander gesprochen. Wenn ich mehr Zeit hätte, würde ich sofort beginnen mit der Robo Programmierung !