Barriers to Adopting Robotic Solutions

1. Software Development and Integration in Robotics 2007 IEEE International Conference on Robotics and Automation Greg Broten Autonomous Intelligent Systems Section Greg.Broten@drdc-rddc.gc.ca Barriers to Adopting Robotic Solutions

2. Overview Background DRDC Requirements Candidate Solutions Experiences Barriers of Adoption Conclusions

3. Background Defence R&D Canada (DRDC) conducts basic research and development with respect to national security and defence matters. Development of tele-operated vehicles began in the late 1980’s.

4. Background

5. Background • Emphasis switched to autonomy in 2002/03. • The Autonomous Intelligence Systems Section focuses on unmanned vehicles. • The Collective Intelligence Group - Autonomy. • A multi-disciplinary approach involving the collaboration of numerous researchers. • Long term focus that extents from research to product delivery. • Recognition that the software approach is critical. • Implementing autonomous capabilities is dominantly a software problem • “Treat Autonomous Navigation as a software problem” S. Thrun

6. DRDC Requirements Robotics’ software requires: Programming languages, compiler, operating system with longevity Compatibility with other research institutions Middleware Component based: Flexible, modular, scalable and extensible Framework approach The architecture emerges from the requirements Open Source Tools

7. Software Development Environment • Influence by major robotics research centres: • C.M.U., Stanford, Georgia Tech., JPL and others • C/C++ programming language • Derived from Open Source software: • Linux • GNU GCC Tool chain

8. Candidate Solutions • Expended a significant effort examining the current state-of-the-art for robotics software • Reviewed and tested numerous robotics “solutions”: • Networking Middleware • Robotics Architectures/Frameworks • Even though the effort was significant, it was governed by time and resource limitations: • Not all avenues could be thoroughly investigated • Outside deadlines drove the timeline, which demanded a solution be selected within a reasonable time period

9. Networking Middleware • Subjectively evaluated middleware toolkits • Identified two trends: • Robotics-specific, IPC, IPT and RTC • Generic ACE, TAO, NDDS, ICE, .NET • Generic middleware is more flexible, but more complex • Specialized middleware offers less capabilities and is more efficient. • Middleware is usually associated with a robotics architecture.

10. Robotics Architectures/Frameworks • Reviewed robotics architectures with respect to DRDC’s requirements • High level, subjective review • Reviewed in late 2003 to early 2004

11. Robotics Architectures/Frameworks • MARIE and ORCA were immature • CLARAty was unavailable • Only Player, Miro and Carmen were mature and freely available

12. Experiences with Robotics Solutions • Examined and tested Architectures and their underlying Middleware: • Player • CARMEN and, • Miro • Subjective Evaluation of: • Installation Process • Introductory Usage • Capabilities

13. Installation • DRDC researchers installed and configured each candidate architecture • Average Linux users could install Carmen and Player • Miro, dependent upon ACE/TAO was the most difficult to install, and required more Linux skills

14. Introductory Usage • Player was the most user friendly • Miro was significantly more difficult to use • No simulator made it much harder to investigate • Carmen provided little documentation • Forced the user to look at the source

15. Capabilities • Miro offered the most capabilities based upon the strong ACE/TAO middleware toolkits • Carmen, using IPC middleware, had potential • Player had limited capabilities, especially for multi-process implementations

16. Selection • DRDC considered adopting only Player and Miro

17. Implementation Experimented with both before selecting Miro • Adapted Miro to the Raptor UGV

18. Barriers to Adoption • From its experiences DRDC observed the following barriers to adoption: • Skill level of its personnel • Software complexity and learning curve • Level of documentation • Restrictive implementation

19. Personnel Skills • Multi-disciplinary team • Varied educations and skill sets: • Ph.D.s, M.Sc.s, Engineers and Technologists • Novice to in-depth software experience

20. Software Complexity and Learning Curves A simple Player example int main(int argc, char **argv) { parse_args(argc,argv); using namespace PlayerCc; PlayerClient robot(gHostname, gPort); Position2dProxy pp(&robot, gIndex); LaserProxy lp(&robot, gIndex); pp.SetMotorEnable (true); for(;;) robot.Read(); }

21. Software Complexity and Learning Curves A not so simple Miro example int main(int argc, char *argv[]) { // Create a server orb to find the events Miro::Server server(argc, argv); EventChannel_var ec( server.resolveName<EventChannel> ("ExampleEventChannel")); NotifyConsumer pushConsumer(ec.in(), server.namingContextName, delay); server.run(); // Enter CORBA event loop. } NotifyConsumer::NotifyConsumer( EventChannel_ptr _ec, const string& domainName) : StructuredPushConsumer(_ec), { EventTypeSeq added, removed; added.length(1); added[0].domain_name = domainName.c_str(); added[0].type_name = "ExampleEvent"; setSubscriptions(added); }

22. Software Complexity and Learning Curves void NotifyConsumer::push_structured_event( const StructuredEvent& notification ACE_ENV_ARG_DECL_WITH_DEFAULTS) throw(SystemException, Disconnected) { const ExampleIDL *pEvent; if (notification.remainder_of_body >>= pEvent) cout << "Received event" << endl; }

23. Documentation • Robotics software is complex • Documentation plays a crucial role in: • Understanding the software’s philosophy and implementation • Providing examples that illustrate its usage • The user can not be expected to read the source code • Nor is a Doxygen reference sufficient • Experiences: • Player – Good • Miro – Acceptable • Carmen – Poor

24. Restrictive Implementations • Miro allows researchers to craft an appropriate implementation • Using ACE/TAO’s multiple messaging paradigms • Event driven • Or, client/server • By allowing multiple processes to co-operatively work together • Through the network transparent exchange of objects • Conversely, Player’s client /server topology forces a specific implementation

25. Conclusions • DRDC investigated and tested numerous robotics solutions. • Barrier to adoption were identified: • Personnel software skills • Complexity and learning curves • Highlighted the need for good Documentation • Restrictive implementations are a handicap • Work needs to be done: • At the DARPA Grand Challenge only 6 of 14 teams adopted an existing solution (middleware or architecture) • The community needs solutions as “user friendly” as Player, but with the capabilities of Miro. • The community needs a open source solutions that are as simple to use at Microsoft’s Robotics Studio.

26. Conclusions • The community needs “user friendly” solutions