Microsoft Robotics Studio

1. Microsoft Robotics Studio Runtime, Simulation & VPL

2. Microsoft Robotics StudioRuntime, Simulation & VPL Overview Zeddy IskandarAcademic Developer Microsoft Indonesia

3. Presentation Outline • Microsoft Robotics Studio Runtime • Overview, Components and Concepts • Decentralized Software Services (DSS) • A lightweight, service oriented application model based around state manipulation • Concurrency and Coordination Runtime (CCR) • A message based model enabling fine grained concurrency and coordination without resorting to threads, locks while avoiding traditional asynchronous programming pitfalls

4. Highly Diverse Market…

5. Shared Challenges… Input from industry, hobbyists, academia, research, … • Configuring sensors and actuators in running system • Coordinating sensors and actuators asynchronously • Starting and stopping components dynamically • Monitoring/Interacting/Debugging running system • Development when access to robot is limited • Span multiple compute units • Re-use of components across hardware platforms and devices

6. Overall Runtime Goals • Distributed Application Model (DSS) • Simple, flexible, and service oriented • Coarse grained and loosely coupled • Compatible with existing Web infrastructure • Concurrent Programming Model (CCR) • Focus on coordination of messages • Hide traditional threads and locks primitives • Enable non thread blocking sequential execution between I/O, avoiding nesting/callback chains

7. DSS Application Model The definition of a Robotics application

8. What is a Robotics Application? An application is a composition of loosely-coupled components concurrently executing Orchestration of sensors/actuators User interface Controlled/Autonomous behavior A service is the unit of orchestration

9. Anatomy of a Service • Service Properties • Identity • Structured State • Composition through partnering • Uniform Behavior • State retrieval and manipulation • Service creation & Termination • Event notifications Port FIFO Service Handlers State

10. Service Abstraction • Services can represent any computation • Hardware: Sensors, actuators,… • Software: UI, Storage,… • Aggregation: Sensor fusion, mash-ups,… • Reuse through composition • Separate State from Behavior (don’t hide state!)

11. Sample Bumper Service • Structured State • Non-structured state handled out of band • Uniform Operations • Define operations over the state • GET, QUERY, UPDATE, DELETE, DROP, SUBSCRIBE

12. Sample Partner Relationship Orchestrator Service subscribes to bumper Service waiting for sensor input A service can partner with arbitrary number of other services

13. Service Interactions Runtime, Hosting Environment, and System Services

14. Service Interaction • Service Interaction happens through protocols • HTTP is available for interactions from Web browser and for providing UI • Enables deep integration with existing Web infrastructure • DSSP is a SOAP-based protocol available for inter-service communication • Augments HTTP model with structured data manipulation and event notifications

15. Distributed Applications • Services can run directly on a single robot • Services can run on swarms of collaborating robots • Services can run on computers in the network • Applications typically a mix

16. Runtime Performance • Service-to-Service message throughput: • Same process (with full cloning): 50,000 msgs/second • Cross node,cross machine: 3,000 msgs/sec • Numbers from dual core 1.8GHz, 2GB RAM • Performance allows consistent use of service model for both local and distributed case

17. CCR Programming The foundation for writing Robotics Applications

18. The CCR Runtime • Asynchronous Programming model • A concurrency model without manual threading, locks, semaphores, etc. • Based on asynchronous message passing • Focus on coordination primitives • Sequential execution but with no thread blocking, with no need for callbacks, when necessary • Execution context for services • Isolation from infrastructure • Isolation from other services

19. Messages, Ports, and Arbiters • Messages are sent to Ports Port<int> myPort = new Port<int>() ;myPort.Post (42) ; • Ports contain • A FIFO data-structure holding values in a port • A list of continuations that can be executed pending message arrival and arbitration • A continuation is represented by a C# delegate • Can either be named or anonymous • Arbiters • Implement common concurrency constructs like join patterns and interleaved calculations

20. IEnumerator<ITask> MultistageIterator() { bool result = false; Port<bool> port = new Port<bool>(); // Stage A, send request port.Post(true); yield return Arbiter.Receive(false, port, delegate(bool b) {result=b; }); // Stage B, received first result, send second request port.Post(result); yield return Arbiter.Receive(false, port, delegate(bool b) {result=b; }); // Stage C, received second result, print it Console.WriteLine(result); } Example: Iterators make a difference

21. PortSet<int, string> port = new PortSet<int, string>(); Activate(Arbiter.Choice(port, MyIntHandler, MyStringHandler) ); void MyIntHandler(inti) { Console.WriteLine("Received: " + i); } void MyStringHandler(string s) { Console.WriteLine("Received: " + s); } Example: Choice

22. PortSet<Result,Exception> resultsPort= new PortSet<int>(); // parallel computation by posting requests For (inti=0;i<N;i++) { computePort.Post(new DoWork(someData,resultsPort)); } // requests complete asynchronously with unknown number // of failures vs. successes Activate( Arbiter.MultipleItemReceive(resultsPort, delegate (ICollection<Result> successes, ICollection<Exception> failures) { foreach(Result r in results) { …… } }); Example: Dynamic Join

23. Declarative Coordination for Services [ServiceHandler(ServiceHandlerBehavior.Concurrent)] public IEnumerator<ITask> GetHandler(Get get) { get.ResponsePort.Post(_state); yield break; } [ServiceHandler(ServiceHandlerBehavior.Exclusive)] public IEnumerator<ITask> UpdateHandler(Update update) { _state.CurrentResult += update.Body.Value; update.ResponsePort.Post(new UpdateResponse()); yield break; }

24. Simulation Because hardware is expensive 

25. Why a Simulator? • Robotics hardware is expensive • Hardware can be difficult to debug • Hard for a team to work concurrently with limited hardware

26. Why a Simulator?Benefits • Low barrier to entry • Staged approach • Easy prototyping • Useful for education • Good learning and research tool

27. Why a Simulator?Limitations • Lack of noisy data • Incomplete or inaccurate models • Accurate tuning takes time

28. Simulator ArchitectureThe Simulator Engine Service User Interface / Editor Simulation Engine Service Ageia Physics Engine XNA Graphics Library Display Hardware • Implemented as a service • Maintains world state • Manages input devices • 3D rendering using XNA • Ageia Physics Simulation • Graphical User Interface • Editor for modeling and debugging

29. Visual Programming Language Rapid Robot Prototyping

30. MicrosoftVisual Programming Language • Visual programming environment • Simple programming with drag and drop • Application are diagrams • Blocks • Connections • Integrated into Microsoft Robotics Studio

31. Guided Tour

32. Hello, World!

33. How does it work? • Exchange of messages between activities • Activities • Perform an action on input message • Send result of the action as output message • Connections • Make output of one activity input of second Input message Output message

34. How does it work? • Exchange of messages between activities • Activities • Perform an action on input message • Send result of the action as output message • Connections • Make output of one activity input of second Input message

35. Data Activity • Output message is a new data value • Ignores content of input message • Different types of data • int, string, double, bool, …

36. Service Activities • SimpleDialog is a DSS Service • All DSS services are activities in VPL • Provide access robot hardware, input devices, behavior … • You can add your own activities!

37. Service Activities • Services can have multiple actions, e.g. • AlertDialog, PromptDialog, ConfirmDialog • Most actions have two output messages • Success – may contain output values • Fault – action could not complete

38. Selecting Services • Services appear in the Services toolbox • Use the search box to quickly find services.

39. Making Connections • Drag output message of first activity …

40. Making Connections • … to second activity • Possible targets are highlighted

41. Selecting Actions • When connecting an activity with multiple actions, select the desired action. Selects the action to which to send the message. Selects the output message that is used as input message for the action.

42. Data Connections • Service actions define format required for input message • Data Connections format messages AlertDialog requires an input value called AlertText. Selects the part of the input message that is used for the target.

43. Hello, World! Revisited

44. Hello, World! Revisited Not connected. Automatically receives an empty input message. Value:

45. Hello, World! Revisited Value: “Hello, World!” (string)

46. Hello, World! Revisited Value: “Hello, World!” (string)

47. Hello, World! Revisited Data connections formats the input message before it is sent to the activity Value: AlertText = “Hello, World!” (AlertText string)

48. Hello, World! Revisited Not connected. Output message is ignored. Value: Empty (Success)

49. Example 1 • Create a new activity that translates the thumb-stick value of the XBox360 controller to left and right power values of a differential drive. • User defined activities

50. XBox360 Controller • ThumbsticksChange notification • X, Y coordinates for both thumb-sticks: • LeftX, LeftY • RightX, RightY • float 1.0 Y -1.0 1.0 X -1.0