1. CS 425 December 17, 2008 Shaun Martin Brian Pritchett Team ACME Final Presentation

2. Agenda Project Definition Project Plan High Level Design Prototype Demonstration

3. Project Definition

4. Team Introduction Clients Dr. Jerry Weinberg, Computer Science Dr. Ryan Krauss, Mechanical Engineering Dr. George Engel, Electrical Engineering

5. Team Introduction Shaun Martin Planning Manager Customer Interface Manager Process Manager Quality Manager Documentation Lead Brian Pritchett Design Manager Implementation Manager Testing Manager Support Manager Lead Web Design

6. Team Introduction Mechanical Engineering Team Lukas Pirok Kevin Doss Kaci Backs Lance Labonte Electrical Engineering Team Greg Eddings Jason Tennyson

7. Problem Definition Develop an autonomous golf cart to compete in the DARPA Mini Grand Challenge. Navigate pathway on college campus Small and inexpensive short-range vehicles Maximum speed: 5 mph Develop an autonomous vehicle to be used for Human Robot Interaction (HRI) research. Possible User Interface

8. The Challenge Robot will travel a 7 to 8 foot path with 6 checkpoints. The robot must stop within 2 feet on an obstacle. The final checkpoint is on an unpaved path that the robot must navigate. The total distance of travel will be no longer than 0.5 miles. There will be no markers, lines, or beacons to indicate the path.

9. The Challenge A robot that stops for more than 60 seconds when not waiting for an obstacle to be removed will be considered “brain dead.” No human contact with the robot is allowed. Robots will also be judged on how it interacts with the crowd.

10. Contest Rules 1.) Must be powered by batteries (no combustibles). 2.) May be constructed from anything that does not interfere with rule 1. 3.) Must stay between 1 and 5 mph. 4.) Must be able to transport 1 gallon of water. 5.) Must have a clearly labeled stop button or switch. 6.) Should be in the 25-75 lb range.

11. Contest Rules 7.) Max size is 216 feet cubed (6 x 6 x 6). 8.) No communication between the robot and an outside device is allowed, except for GPS. 9.) Communication between devices that are part of the robot is allowed. 10.) The robot must be a single entity. 11.) Robots are ground robots. No aerial robots are allowed.

12. Current Design - Overview GPS (2) -waypoint navigation -intelligent redundancy Camera(s) -path finding -trajectory planning -obstacle avoidance Sonars (4) -obstacle avoidance -trajectory planning -I 2 C bus DC Motor -steering position control -gear reduction for torque -I 2 C bus Linear Actuator -braking position control -I 2 C bus Quadrature Encoders (2) -velocity control -steering position control -I 2 C bus

13. Who are the Users? Team ACME Professors & students pursuing research in HRI Bystanders during demonstrations

14. Software Requirements Must be able to run on Windows machine Desired programming language is C++ OpenCV for Image Processing Use APIs developed by ECE team

15. System Functionality Interface with GPS units for navigation Laser for obstacle avoidance Multi-threaded application Image Processing User Interface for HRI research

16. Requirements Analysis Interviews with Dr. Weinberg What needs to be done this year? Phone conferences with Ross Mead What sections of code need to be improved? Review of existing code

17. Project Plan

18. Software Process - Scrum

19. Pre-Game Phase Two sub-phases: Planning High level design / Architecture Deliverables: Product backlog Coding / Documentation Standards Design Documents

20. Development Phase Implements iterative cycles called “Sprints” Sprints consist of: Sprint planning meeting Detailed design Implementation Testing Review

21. Post-Game Phase Final phase of Scrum Sub-phases: System testing Final Release Deliverables: Final Documentation Working Product

22. Roles Scrum Master / Product Owner Project manager Interacts with customer Maintains product backlog Scrum Team Primary concerns: sprints Customer Synonymous with client Management Dr. Blythe and Dr. Fujinoki

23. Software Engineering Methods Version Control Subversion Review Required with Scrum Ranges from informal “desk checks” to inspection reviews Dependent on importance of current sprint

24. Software Tools TortoiseSVN Free version control system that integrates within the Windows shell Microsoft Project Project management software to assist teams in assigning tasks, managing resources, and assigning workloads Microsoft Visual Studio 2008 Primary IDE used for development OpenCV Open-source cross-platform computer vision library

25. Testing Plan Unit Testing Individual modules will be tested by developer during sprint Integration Testing Completed sprint product tested with current working product System Testing Fully developed system tested during post-game phase Final testing session prior to final release

26. Estimation Method Wideband Delphi Estimation Requires that a work breakdown structure be implemented prior to using this estimation method Work breakdown structure for our project will be the product backlog list Kickoff meeting which correlates to our sprint planning meetings. Specific tasks are selected Make individual estimations Worst case, best case, average case are logged. Estimate is the average

27. Project Timeline TaskDurationStartFinish Orange Cone Interaction12 days12/1/200812/15/2008 Sprint Planning Meeting1 day12/1/2008 Detailed Design3 days12/2/200812/4/2008 Implementation5 days12/5/200812/11/2008 Unit Testing2 days12/12/200812/14/2008 Sprint Review Meeting1 day12/15/2008 Sprint Completed0 days12/15/2008 Integration Testing4 days12/16/200812/19/2008 Obstacle Avoidance12 days1/12/20091/26/2009 Sprint Planning Meeting1 day1/12/2009 Detailed Design3 days1/13/20091/15/2009 Implementation5 days1/16/20091/22/2009 Unit Testing2 days1/23/20091/25/2009 Sprint Review Meeting1 day1/26/2009 Sprint Completed0 days1/26/2009 Integration Testing4 days1/27/20091/30/2009 Velocity Control12 days2/2/20092/16/2009 Sprint Planning Meeting1 day2/2/2009 Detailed Design3 days2/3/20092/5/2009 Implementation5 days2/6/20092/12/2009 Unit Testing2 days2/13/20092/15/2009 Sprint Review Meeting1 day2/16/2009 Sprint Completed0 days2/16/2009 Integration Testing4 days2/17/20092/20/2009

28. Project Timeline Emergency Shutoff12 days2/23/20093/9/2009 Sprint Planning Meeting1 day2/23/2009 Detailed Design3 days2/24/20092/26/2009 Implementation5 days2/27/20093/5/2009 Unit Testing2 days3/6/20093/8/2009 Sprint Review Meeting1 day3/9/2009 Sprint Completed0 days3/9/2009 Integration Testing4 days3/10/20093/13/2009 Crowd Interaction System12 days3/16/20093/30/2009 Sprint Planning Meeting1 day3/16/2009 Detailed Design3 days3/17/20093/19/2009 Implementation5 days3/20/20093/26/2009 Unit Testing2 days3/27/20093/29/2009 Sprint Review Meeting1 day3/30/2009 Sprint Completed0 days3/30/2009 Integration Testing4 days3/31/20094/3/2009 Remote Drive System12 days4/6/20094/20/2009 Sprint Planning Meeting1 day4/6/2009 Detailed Design3 days4/7/20094/9/2009 Implementation5 days4/10/20094/16/2009 Unit Testing2 days4/17/20094/19/2009 Sprint Review Meeting1 day4/20/2009 Sprint Completed0 days4/20/2009 Integration Testing4 days4/21/20094/24/2009 System Testing17 days4/6/20094/27/2009

29. Project Timeline – Sample Sprint

30. Risk Analysis RiskLikelihoodCostPlan Temporary loss of team member 10%7 days-redistribute roles New contest rules20%3 days -revisit high level design -add new rules to product backlog list Delays due to other teams70%7 days -consult client -work on tasks that are independent of other team -consult upper management -conduct team meeting Interface with existing system 80%7 days -study existing code prior to integration -consult last year’s team Sensor failure25%3 days -debug code -check electrical system -consult ECE team Steering failure25%3 days-consult ME team Hardware failure15%2 days-consult teams -redesign if legacy hardware is needed

31. Coding and Documentation Name and author(s) at top of each file. A brief description Required files will be listed. Above each function prototype, a brief description of the function will be included. Above each function definition, a more detailed description of the function will be included. Inputs, outputs, and return types will be listed, including a brief description of how they will be used.

32. Coding Example // // ostream& <<(out, th) // Last modified: 14Feb2008 // // Outputs the parameterized thread to the parameterized output file stream. // // Returns: the output file stream // Parameters: // out in/out the output files stream // th in/out the thread to output // ostream& operator <<(ostream &out, const Thread_t &th) { out << th.getName() << " [" << th.getID() << "]"; return out; } // <<(ostream &, const Thread_t &)

33. Conflict Resolution Procedure The group member with the issue will present their problem to the other team member. The two will attempt to come to an agreement. If no agreement can be made, the group will approach upper management for a resolution.

34. Ethical Considerations We will do our best to produce solid code that completes the project that is agreed upon between us and our client. We will not take credit for code written by previous teams. We will not take credit for code or work done by teams we are working with.

35. High Level Design

36. PEAS Description PEAS – Performance, Environment, Actuators, Sensors Used to determine what type of agent will be used, robot control system, and robot architecture Agent TypePerformance Measure EnvironmentActuatorsSensors Autonomous Golf Cart Safe, successful navigation to desired waypoint following competition standards Campus pathways, students, other traffic, various obstacles Steering, accelerator, brakes, display Camera, Sonar, Outdoor laser, GPS, motor sensors, keyboard

37. Task Environment Partially observable Sensors do not provide complete state of environment Stochastic Hard to keep track of all unobserved aspects Next state cannot be determined based on current state Dynamic Environment is constantly changing Continuous Environment is constantly changing over time Multi-agent Sequential Previous actions can impact current actions

38. Goal-based Agent

39. High Level Design Robot Control Behavior-based Control System Robot exhibits many “behaviors” Allows for modularity and iterative development Robot Architecture Subsumption Architecture reactive robot architecture heavily associated with behavior-based robotics Emulates concurrency

40. Finite State Machine Model

41. Subsumption Architecture Model

42. Current Product Backlog TaskPriority Orange Cone Interaction1 Obstacle Avoidance2 Velocity Control3 Emergency Shutoff System4 Flag System (demonstration or competition) 5 Crowd Interaction6 Remote Drive7 Improved User Interface8

43. Current Product Backlog TaskPriority Orange Cone Interaction1 Obstacle Avoidance2 Velocity Control3 Emergency Shutoff System4 Flag System (demonstration or competition) 5 Crowd Interaction6 Remote Drive7 Improved User Interface8

44. Prototype Demonstration

45. Questions?