1 / 24

Overview of RP10 Robotics Platform: Development, Design, and Challenges

This presentation outlines the history and development of the RP10 robotics platform, emphasizing its multidisciplinary approach within the KGCOE. It discusses key design aspects, including the integration of hardware and software, challenges with communication protocols, and the iterative methodology employed during the project. The need for thorough requirements elicitation, testing strategies, and the importance of collaborative subsystem development are highlighted. Additionally, the use of Microsoft Robotics Developer Studio (MRDS) and the significance of 3D modeling in simulation are explored.

makoto
Télécharger la présentation

Overview of RP10 Robotics Platform: Development, Design, and Challenges

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. RP10 Robotics Platform Team Cyberdyne Interim Presentation February 17, 2009, 4-5 PM Project Sponsor: Dr. Wayne Walter, RIT KGCOE Faculty Coach: Dr. James Vallino

  2. History of RP10 Platform • KGCOE Multidisciplinary Senior Design • Preceding project: P08201 (20071-3) • 2ND generation platform • Like “next model year” in auto industry • Built by EE, IE, ME students • Up to 4 motor modules • 10 kg payload • PC software for remote control

  3. Pictures of the RP10

  4. Project Synopsis Microsoft Robotics Developer Studio (MRDS) Model RP10 Simulation Platform Control Application Platform API .NET Other bindings . . . Wireless RF or Wired (Serial Cable) Motion commands, diagnostics RP10 Microcontroller (MCU) Motors Batteries Drive Platform Software Encoders Steer

  5. Pictures of the MRDS Visual Programming Language 3-D Visualized Simulation

  6. Process Methodology Choice • Spiral • Cycles with upfront risk-oriented evaluation • Iterative nature • Addresses significant uncertainty frequently • Cycles every 2-3 weeks • Obvious general risks early on • Inappropriate decisions due to inexperience • Hardware incapability against design • Platform instability • Resource unavailability (i.e., tools)

  7. Schedule for 20082 Continued . . .

  8. Schedule – 20082

  9. Metrics • Time tracking (up to week 9) • Hours estimated: 726.65 • Hours actual: 723.75 • Total hours for cycle 2: 284 (39%) • No other metrics tracked • Primarily product-oriented

  10. Cycle 2 (C2) - Risks • Cannot create a comprehensive RP10 simulation in MRDS. • Communication between MCU and PC is unreliable. • Designs for MRDS implementation and platform API are incompatible. • Cannot use encoders to track angular wheel position.

  11. C2 - Requirements Elicitation • Limitations of RP10 platform • P08201 documentation • Experimentation to fill in gaps • Interviews with KGCOE professors • Understand applications of platform • Influence API design • Discussions on simulation detail • Command set from API • Physical characteristics from Simulink

  12. Notable Requirements • Platform • Control individual motors for drive, steer • Determine wheel angular position • Model • Build a 3D model of the RP10

  13. C2 - Design Process • Platform • Split platform into subsystems • API • Communication Protocol • MCU • Divide sub-team across subsystem preferences • Collaborate to resolve interface issues • Model • Defined assets necessary for a simulation • Manifests, services, 3D model, etc. • Divided sub-team by expertise

  14. Architecture - Platform .NET PC User Interface (GUI/CLI) Robot Control Commands (i.e., set speed, go, stop, etc.) Communication Manager Abstracts communication hardware (wireless or wired) Protocol over Serial Cable Responds to commands from PC, acknowledges commands Executable MCU* PWM* signals Motors *Microcontroller Unit, Pulse Width Modulation

  15. Communication Protocol • Packets • Operation code (1 byte) • Data (optional 1 byte) • Acknowledges each byte received • Heartbeats from PC • Automatic robot shutdown if no beat received • Command error checking on PC

  16. Architecture – Model -- MRDS

  17. SolidWorks • Create a 3-D model to import into MRDS • Includes material properties • 2008 vs. 2009 • Collada Export in 2009 • Licensing • Future Plans

  18. Notable Trade-offs • PC vs. MCU functionality • PC: Easier to modify software • MCU: Software closest to hardware • Modeling a wheel vs. entire drive train • Wheel: Simplifies model development • Drive train: More accurate with all gears

  19. Implementation Technologies • Platform • FreeScale MCU with CodeWarrior IDE • Hardware specific registers • C programming • C#.NET with Visual Studio • PC control software • Model • Visual Programming Language (VPL) with MRDS • Drag-drop programming of objects and actions • C#.NET • Interface with low-level MRDS components, API

  20. Test Strategy & Issues • Platform • Manual acceptance tests through PC control • Coverage of all commands in protocol • Physical observation of correctness (i.e., yardstick) • Reliability, performance testing • Model • Simulated part function unit tests • Simulation test course for long duration • Dashboard control in simulated environment • Comparison of part functions between simulation and real robot

  21. C2 - Results • Platform • Designs for API, communication protocol • Requirements document • PC-MCU prototype of protocol • Model • Initial overall platform characteristics • SolidWorks motor module, frame models • Requirements, test strategy documents

  22. Schedule Projections

  23. Lessons • Learn and abide by the methodology • Set specific goals and work to them • Plan activities separate of needed tools • Do not isolate sub-teams

  24. Questions?

More Related