CS 425December 17, 2008

Shaun MartinBrian Pritchett

Team ACME Final Presentation

AgendaProject DefinitionProject PlanHigh Level DesignPrototype Demonstration

Project Definition

Team IntroductionClients

Dr. Jerry Weinberg, Computer ScienceDr. Ryan Krauss, Mechanical EngineeringDr. George Engel, Electrical Engineering

Team IntroductionShaun Martin

Planning ManagerCustomer Interface

ManagerProcess ManagerQuality ManagerDocumentation

Lead

Brian PritchettDesign ManagerImplementation

ManagerTesting ManagerSupport ManagerLead Web Design

Team IntroductionMechanical Engineering Team

Lukas PirokKevin DossKaci BacksLance Labonte

Electrical Engineering TeamGreg EddingsJason Tennyson

Problem DefinitionDevelop an autonomous golf cart to

compete in the DARPA Mini Grand Challenge.Navigate pathway on college campusSmall and inexpensive short-range vehiclesMaximum speed: 5 mph

Develop an autonomous vehicle to be used for Human Robot Interaction (HRI) research.Possible User Interface

The ChallengeRobot 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.

The ChallengeA 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.

Contest Rules1.) 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.

Contest Rules7.) 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.

Current Design - Overview

GPSGPS (2) (2)-waypoint navigationwaypoint navigation-intelligent redundancyintelligent redundancy

Camera(s)Camera(s)-path findingpath finding-trajectory planningtrajectory planning-obstacle avoidanceobstacle avoidance

SonarsSonars (4) (4)-obstacle avoidanceobstacle avoidance-trajectory planningtrajectory planning-II22C busC bus

DC MotorDC Motor-steering position controlsteering position control-gear reduction for torquegear reduction for torque-II22C busC bus

Linear ActuatorLinear Actuator-braking position controlbraking position control-II22C busC bus

Quadrature EncodersQuadrature Encoders (2) (2)-velocity controlvelocity control-steering position controlsteering position control-II22C busC bus

Who are the Users?Team ACMEProfessors & students pursuing research in

HRIBystanders during demonstrations

Software RequirementsMust be able to run on Windows machineDesired programming language is C++OpenCV for Image ProcessingUse APIs developed by ECE team

System FunctionalityInterface with GPS units for navigationLaser for obstacle avoidanceMulti-threaded applicationImage ProcessingUser Interface for HRI research

Requirements AnalysisInterviews 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

Project Plan

Software Process - Scrum

Pre-Game PhaseTwo sub-phases:

PlanningHigh level design /

ArchitectureDeliverables:

Product backlogCoding /

Documentation Standards

Design Documents

Development PhaseImplements iterative cycles called “Sprints”Sprints consist of:

Sprint planning meetingDetailed designImplementationTestingReview

Post-Game PhaseFinal phase of ScrumSub-phases:

System testingFinal Release

Deliverables:Final DocumentationWorking Product

RolesScrum Master / Product Owner

Project managerInteracts with customerMaintains product backlog

Scrum TeamPrimary concerns: sprints

CustomerSynonymous with client

ManagementDr. Blythe and Dr. Fujinoki

Software Engineering MethodsVersion Control

SubversionReview

Required with ScrumRanges from informal “desk checks” to

inspection reviewsDependent on importance of current sprint

Software ToolsTortoiseSVN

Free version control system that integrates within the Windows shell

Microsoft ProjectProject management software to assist teams in

assigning tasks, managing resources, and assigning workloads

Microsoft Visual Studio 2008Primary IDE used for development

OpenCVOpen-source cross-platform computer vision

library

Testing PlanUnit Testing

Individual modules will be tested by developer during sprint

Integration TestingCompleted sprint product tested with current

working productSystem Testing

Fully developed system tested during post-game phase

Final testing session prior to final release

Estimation MethodWideband 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 selectedMake individual estimations

Worst case, best case, average case are logged. Estimate is the average

Project TimelineTask Duration Start FinishOrange Cone Interaction 12 days 12/1/2008 12/15/2008 Sprint Planning Meeting 1 day 12/1/2008 12/1/2008 Detailed Design 3 days 12/2/2008 12/4/2008 Implementation 5 days 12/5/2008 12/11/2008 Unit Testing 2 days 12/12/2008 12/14/2008 Sprint Review Meeting 1 day 12/15/2008 12/15/2008Sprint Completed 0 days 12/15/2008 12/15/2008Integration Testing 4 days 12/16/2008 12/19/2008Obstacle Avoidance 12 days 1/12/2009 1/26/2009 Sprint Planning Meeting 1 day 1/12/2009 1/12/2009 Detailed Design 3 days 1/13/2009 1/15/2009 Implementation 5 days 1/16/2009 1/22/2009 Unit Testing 2 days 1/23/2009 1/25/2009 Sprint Review Meeting 1 day 1/26/2009 1/26/2009Sprint Completed 0 days 1/26/2009 1/26/2009Integration Testing 4 days 1/27/2009 1/30/2009Velocity Control 12 days 2/2/2009 2/16/2009 Sprint Planning Meeting 1 day 2/2/2009 2/2/2009 Detailed Design 3 days 2/3/2009 2/5/2009 Implementation 5 days 2/6/2009 2/12/2009 Unit Testing 2 days 2/13/2009 2/15/2009 Sprint Review Meeting 1 day 2/16/2009 2/16/2009Sprint Completed 0 days 2/16/2009 2/16/2009Integration Testing 4 days 2/17/2009 2/20/2009

Project TimelineEmergency Shutoff 12 days 2/23/2009 3/9/2009 Sprint Planning Meeting 1 day 2/23/2009 2/23/2009 Detailed Design 3 days 2/24/2009 2/26/2009 Implementation 5 days 2/27/2009 3/5/2009 Unit Testing 2 days 3/6/2009 3/8/2009 Sprint Review Meeting 1 day 3/9/2009 3/9/2009Sprint Completed 0 days 3/9/2009 3/9/2009Integration Testing 4 days 3/10/2009 3/13/2009Crowd Interaction System 12 days 3/16/2009 3/30/2009 Sprint Planning Meeting 1 day 3/16/2009 3/16/2009 Detailed Design 3 days 3/17/2009 3/19/2009 Implementation 5 days 3/20/2009 3/26/2009 Unit Testing 2 days 3/27/2009 3/29/2009 Sprint Review Meeting 1 day 3/30/2009 3/30/2009Sprint Completed 0 days 3/30/2009 3/30/2009Integration Testing 4 days 3/31/2009 4/3/2009Remote Drive System 12 days 4/6/2009 4/20/2009 Sprint Planning Meeting 1 day 4/6/2009 4/6/2009 Detailed Design 3 days 4/7/2009 4/9/2009 Implementation 5 days 4/10/2009 4/16/2009 Unit Testing 2 days 4/17/2009 4/19/2009 Sprint Review Meeting 1 day 4/20/2009 4/20/2009Sprint Completed 0 days 4/20/2009 4/20/2009Integration Testing 4 days 4/21/2009 4/24/2009System Testing 17 days 4/6/2009 4/27/2009

Project Timeline – Sample Sprint

Risk AnalysisRisk Likelihood Cost Plan

Temporary loss of team member

10% 7 days -redistribute roles

New contest rules 20% 3 days -revisit high level design-add new rules to product backlog list

Delays due to other teams 70% 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 failure 25% 3 days -debug code-check electrical system-consult ECE team

Steering failure 25% 3 days -consult ME team

Hardware failure 15% 2 days -consult teams-redesign if legacy hardware is needed

Coding and DocumentationName and

author(s) at top of each file.

A brief descriptionRequired 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.

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 &)

Conflict Resolution ProcedureThe 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.

Ethical ConsiderationsWe 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.

High Level Design

PEAS DescriptionPEAS – Performance, Environment,

Actuators, SensorsUsed to determine what type of agent will

be used, robot control system, and robot architectureAgent

TypePerformance Measure

Environment

Actuators

Sensors

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

Task EnvironmentPartially observable

Sensors do not provide complete state of environment

StochasticHard to keep track

of all unobserved aspects

Next state cannot be determined based on current state

DynamicEnvironment is

constantly changingContinuous

Environment is constantly changing over time

Multi-agentSequential

Previous actions can impact current actions

Goal-based Agent

High Level DesignRobot Control

Behavior-based Control SystemRobot exhibits many “behaviors”Allows for modularity and iterative development

Robot ArchitectureSubsumption Architecture

reactive robot architecture heavily associated with behavior-based robotics

Emulates concurrency

Finite State Machine Model

Subsumption Architecture Model

Current Product BacklogTask Priority

Orange Cone Interaction 1

Obstacle Avoidance 2

Velocity Control 3

Emergency Shutoff System 4

Flag System (demonstration or competition)

5

Crowd Interaction 6

Remote Drive 7

Improved User Interface 8

Current Product BacklogTask Priority

Orange Cone Interaction 1

Obstacle Avoidance 2

Velocity Control 3

Emergency Shutoff System 4

Flag System (demonstration or competition)

5

Crowd Interaction 6

Remote Drive 7

Improved User Interface 8

Prototype Demonstration

Questions?