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) –2 ND 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 Motors Encoders Batteries Microcontroller (MCU) Platform Software RP10 Steer Drive Wireless RF or Wired (Serial Cable) Platform Model Platform API.NETOther bindings... Control Application Microsoft Robotics Developer Studio (MRDS) RP10 Simulation Motion commands, diagnostics

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 WeeksTasks 1-3Understanding the context, initial project plan 4-6Research and configuration P08201 artifacts (source code, etc.) Microcontroller details Tools (MRDS, Simulink, SolidWorks) Continued...

8. Schedule – 20082 WeeksTasks 7-9 (Cycle 2) Platform – Base requirements – Design at multiple levels (PC, MCU) – Prototypes Model – Part modeling with SolidWorks – Kinematic modeling with Simulink – Reverse engineering of MRDS sample

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

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 10-11 (Cycle 3) Department deliverables Platform – Low-fidelity prototypes of control interface – Complete designs for implementation Model – Services for battery, brick – Approach for MRDS-API integration – Next versions of SolidWorks, Simulink models Plans for start of next quarter – Platform implementation – Motor services

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?