An Architectural Approach to Robotics Software Design, Implementation, and Deployment Brian D’Souza Joshua Garcia Ivo Krka Natachart Laotheppitak Hossein Tajalli Outline • • • • • • • • • Motivation Initial Stage Suggested Architecture Manager Primary Connector Component Example Admin Conclusion Motivation • Provide a more disciplined approach to building embedded systems – Applying software architectural principles to robotics systems • Merging of heterogeneous types of applications in an embedded systems environment • Abstract away lower-level software development details Design using software architectural abstractions and implement using architectural middleware Prism-MW Motivation • Desirable properties – Distribution – Mobility – Scalability – Maintainability – Evolvability – Concurrency Initial Stage – Course Project • 589 – Software Engineering for Embedded Systems taught by Prof. Nenad Medvidovic • Video: http://video.google.com/videoplay?docid=1355003473678326666&q=cs589&total=5&start=0&num=10&so=0& type=search&plindex=1 Next stage • Class project showed that students with very limited robotics experience were able to create a new interesting application • Current objectives – Creating a more general and adaptable architecture – Variety of possible new applications Suggested Architecture Admin Physical Device Component 1 Component 2 Primary Connector Component n Deployment System Manager Manager • Parameters – List of Machine Interfaces (e.g. iRobot, Display, User Input Device, Motion Sensor, Temperature Sensor, camera ,etc.) – List of Components • Discovers other hosts around and communicate with them • Host Rendezvous • Request Admin to download new components from other hosts • Decides whether to connect one of its components to peer components in other entities • Decides to start and stop components (Planning) Primary Connector • Communicating the events between components in the same physical entity or between different entities • Routing, filtering, broadcasting the packages to desired sockets • Connector types may vary Component • Components can use device drivers to communicate with the physical devices – E.g., for a sensor, a component can read the sensor values – E.g., for a robot, one component can control the robot to follow a line, turn a corner, etc. • Cooperation with local and remote components – E.g., they can share positions of discovered obstacles • Components carry information about their supported interfaces and services Example Admin Admin Line Follower Admin Connector User Interface Connector Connector Wall Follower Manager Manager Manager Admin • Supports dynamic adaptation and component mobility • Ability to (re)deploy components onto a different host – Specify connector to attach component to – Dependent files – Requester or replier Admin Manager Admin Connector Component Connector redeploy AdminUI redeploy redeploy Connector Admin Byte Array Component Conclusion • Non-functional qualities of robotics applications need to be better addressed • Raising the level of abstraction of robotics systems development • Encouraging initial results of application of our architectural approach • Future work on realizing details of the approach and introducing new facilities