430 likes | 686 Vues
Robotics Module 2 System Design. EGG-275 Mike Hoganson 303-594-0098. Objectives for Today. Project Report Out – By Team Discuss the your Robot Design Challenge Exercise Robot Design Processes Logistics for the Workshop Tomorrow Make Sure Our Arduinos are Functioning. EGG-275
E N D
RoboticsModule 2System Design EGG-275 Mike Hoganson 303-594-0098
Objectives for Today • Project Report Out – By Team • Discuss the your Robot Design Challenge Exercise • Robot Design Processes • Logistics for the Workshop Tomorrow • Make Sure Our Arduinos are Functioning
EGG-275 Module 2 - Section 1 Team Report
Report outs • Registration of Teams? • Team Names? • New Teams? • Problems and Challenges?
EGG-275 Milestones • Skills Building – January 31 • Preliminary Design Review – February 13 • Critical Design Review – March 6 • Preliminary Testing – March 20 • The Challenge – April 4 • Post Test Reviews - April 10 • Final Demos – May 1 • Final Presentations May 8
EGG-275 Module 2 - Section 2 Robot System Design Processes
Simple Block Diagram of Systems Sensing Processor Rules (Algorithms) Navigation Pathing Vehicle Structure Steering Drive/Transmission Power Battery
How Do We Move From Ideas to Hardware? Designs Concepts & Models ? Hardware
A Design Process Bridges Concepts to Designs and Hardware Designs Concepts & Models Design Process Hardware
What is a Process? • A systematic series of actionsdirected to some end This means: • It has a start, or beginning • It has an ending, or result • It is action – oriented • That is, something is produced or changed • It has direction • It is systematic
Our Design Process End Start Direction Actions (Measurable)
Design Process Steps (1/2) • Always starts with REQUIREMENTS • WHAT do we NEED to do? What PROBLEM are we trying to SOLVE? • Then, we SPECIFY to SOLUTION at a SYSTEM Level • Given the PROBLEM, and WHAT we NEED to do, HOW will we SOLVE the PROBLEM? • Next, We break the HOW into pieces, or SUBSYSTEMS • The SUBSYSTEMS work together as a SYSTEM to SOLVE the PROBLEM
Design Process Steps (2/2) • With the SUBSYTEMS SPECIFIED and DESIGNED, We then begin to INTEGRATE them • We broke the PROBLEM down to its smallest parts, and then BUILD it back up. • We TEST the SUBSYTEMS as we INTEGRATE them • This allows us to make small changes as we go • Once the SUBSTEMS are fully integrated into the SYSTEM, we can TEST and CALIBRATE the fully designed SYSTEM
Why Follow a Process? • It helps you manage the problem of design complexity • It helps coordinates the actions of many to achieve something • It is predictable in that each action can be broken down • Since it is predictable, it can be budgeted and managed
EGG-275 Module 2 - Section 3 REQUIREMENTSDEFINITION
Requirements Analysis • There are many types of requirements • http://en.wikipedia.org/wiki/Requirements_analysis • There are many ways to describe them • For our purposes, we will discuss only two types • These are Specified and Derived
Specified Requirements • Outlined and defined in a document • Measurable – maybe pass/fail or it may be measured on a scale • If your robot DOES NOT do these things, it does not do the job • Usually in control of the CUSTOMER
Derived Requirements • Also Measureable • Usually imposed by the engineering team interpreting the SPECIFIED requirements • Generally fills in the blanks of the customer specification • Can have more flexibility here – these are usually in control of the engineering team
Where do derived requirements come from? Derived Requirements Just about Anywhere…
Managing Requirements • New derived requirements (ideas) can come from anywhere, at anytime • They may be complementary to the existing requirements… • An idea to add a particular widget that makes the system perform better • Or they may conflict. • There is a particular widget that doesn’t function, and a new widget with a different technology should be used • Implementing requirements requires time and money • Be comprehensive at the start… • The team and program manager have to priortitize which requirements can be accommodated later or…
What is a PDR? • The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. It will show that the correct design options have been selected, interfaces have been identified, and verification methods have been described.[7] • Ensure that all system requirements have been allocated, the requirements are complete, and the flowdown is adequate to verify system performance • Show that the proposed design is expected to meet the functional and performance requirements • Show sufficient maturity in the proposed design approach to proceed to final design • Show that the design is verifiable and that the risks have been identified, characterized, and mitigated where appropriate
What is a CDR? • The CDR demonstrates that the maturity of the design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test. CDR determines that the technical effort is on track to complete the flight and ground system development and mission operations, meeting mission performance requirements within the identified cost and schedule constraints. • Ensure that the "build-to" baseline contains detailed hardware and software specifications that can meet functional and performance requirements • Ensure that the design has been satisfactorily audited by production, verification, operations, and other specialty engineering organizations • Ensure that the production processes and controls are sufficient to proceed to the fabrication stage • Establish that planned Quality Assurance (QA) activities will establish perceptive verification and screening processes for producing a quality product • Verify that the final design fulfills the specifications established at PDR
EGG 275 Module 2 – Section 4 System Level Requirements
Specified Requirements • Location • Maximum Distance Traveled • Number of Courses • Orientation of Courses • Environmental Sensitivity • Safety • Primary Beaconing System • Secondary Beaconing System • Configuration • Mass • Cost
Derived Requirements • In order to achieve the SPECIFIED REQUIREMENTS, the Robot must be able to do: • ???
EGG 275 Module 2 – Section 5 Subsystem System Level Requirements
Subsystem Specification • In order to achieve the overall specified and derived system requirements, our robot needs: • What types of subsystems? • How big (or small) should they be? • What performance parameters should they have?
Class Exercise • Given the robots system and design specifications, lets develop the basic outline of requirements • At this stage, KEEP IT SIMPLE! • Creative thoughts first, critical thoughts later
EGG 275 Module 2 – Section 6 The Workshop
General Instructions • Follow the email links from Brian Sanders for the map • Time of the workshop is 8:15…Plan to arrive by 8:00! • Coffee and Bagels for Breakfast, Pizza for Lunch • Wrap up at 4:30
EGG-275 Module 2 - Section 8 Arduino Checkout
Computer setup and Kit Checkout • See McComb Robot Bonanza Page 25 and on… • Confirm the kit contents
EGG-275 Module 2 - Section 9 Assignments for Next Week
For Next time… • Team Assignment - Program management • Update requirements and plans • Prepare for Report out
For Next Time… • Individual Design Assignment: • Get the skills at the workshop
For Next Time… • Reading • Construction Robot Bases – Chapter 7, 8, and 9 • Arduino Programming – Chapter 1 - 4