1 / 26

Barriers to Adopting Robotic Solutions

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. Overview. Background DRDC Requirements Candidate Solutions

garima
Télécharger la présentation

Barriers to Adopting Robotic Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related