P07205: RP100 Robotic Drive Platform
/public/

P07205 Project Readiness Package

Table of Contents

Administrative Information

Project Name
RP 100 Drive Platform
Project Number
P07205
Project Family
P07200 Modular Robotic Vehicle Platform
Track
Vehicle Systems Technology
Start Term
2006-2
End Term
2006-3
Faculty Guide
Dr. Wayne Walter (ME)
Faculty Consultant
Prof. George Slack (EE)
Primary Customer
Dr. Hensel (ME Dept. Head)
Secondary Customers
Dr. Crassidis (ME), Dr. Hu (CE), Dr. Yang (CE), Dr. Sahin (EE), and Dr. Walter (ME)
Customer contact information
Dr. Edward Hensel, PE
Professor and Head
echeme@rit.edu

Mission Statement

To develop a drive platform for the robotic vehicular platform incorporating modular motors from P07202. The analysis, design, manufacturing, fabrication, test and evaluation will be completely documented to a level of detail that a subsequent team can build upon the work with no more than one week of background research. The robotic vehicular platform family must be within a budget of $15,000.

Project Overview

This student team will develop two modular, fully functional robotic platforms capable of carrying a payload anywhere in the James E. Gleason Building #09 on the RIT campus, with the exception of staircases. The drive platforms should utilize the RP100 Motor Module, the scalable open architecture motor controllers and the DAQ systems where appropriate. One drive platform (Device RP100A) shall be three wheeled, with at least one RP100 motor module, and a payload capacity of at least 25kg. The second drive platform (Device RP100B) shall have at least four wheels, with at least two RP100 motor modules, and a payload capacity of 100kg. By the conclusion of Senior Design II, the team must demonstrate the following:

Test 1:

  1. Remote Control Operation (Tethered to a laptop) of Device RP100A, (carrying a 25 kg payload) from the base of the ramp outside of the ISE Office, through the hallways, up the elevator (by the Xerox Aud) to the third floor.
  2. On the third floor, outside of the EE Sr Design Lab, at least one motor module will detached from Device RP100A and will be attached as a functional motor module to Device RP100B. This change will be accompolished by a team member in under 120 seconds.
  3. Device RP100B shall be operated under remote control (Tethered to a laptop) from the third floor of the James Gleason Building to the second floor via the elevator (by the ME Office). RP100B will be driven to the Gordon Atrium.

Test 2: This test will be conducted on a 20' x 20' open floor

  1. The team will be given five x and y coordinates (in inches) by an instructor.
  2. The values must be inputed into a program already written for device RP100A. After it is received by device RP100A, all connections must be severed. This step must be completed in 120 seconds or less.
  3. Device RP100A must autonomously navigate to each coordinate, in order, stopping for 10 seconds at each.

The team must provide complete documentation of the analysis, design, manufacturing, fabrication, test, assembly, operation and evaluation of this subsystem to a level of detail that a subsequent team can build upon their work with no more than one week of background research.

Staffing Requirements

Staffing
Team Member Discipline Role / Skills email address
Wayne Walter ME Faculty Guide, Will work closely with the team on an on-going basis to facilitate success. wwweme@rit.edu
George Slack EE Faculty Consultant, Will provide EE discipline technical support on an intermittant basis. gbseee@rit.edu
Jeff Webb ME Teaching Assistant jbw3914@rit.edu
Kate Nordland ME Project Readiness Package author, P07898 software contact ken9444@rit.edu
James Aclub EE Electrical Systems Lead jma4815@rit.edu
Jesse Baker ME Systems Integration Coordinator jesse_baker3@hotmail.com
Jeffrey Gill ME Mechanical Craftsman jcg7627@rit.edu
Arnold David Gomez ME Lead Engineer adg2989@rit.edu
James Harris EE Software Engineer jah7000@rit.edu
Benjamin Smith ME Mechanical Designer bds7756@rit.edu
Aman Verma EE Electrical Craftsman avx9757@rit.edu
Tian Zeng EE Electrical Designer tmz9427@rit.edu

Project Manager/Mechanical Support - Responsible for guiding his or her team members to achieve the goals set forth in the mission statement above; the Project Manager will need to delegate work effectively, and will also have a key role in design approval by being able to evaluate the input from all of his or her teammates, and help the team make critical decisions. This position is responsible for managing finances, setting up meetings, ordering materials, and editing the final report presented at the end of each Senior Design section. This student will also give mechanical support where needed.

Chief Engineer - Responsible for overall technical design. Should be proficient in Pro-Engineer or Solid Works. Maintains the 3-D modeling of the design.

Mechanical Systems Engineer - The Mechanical Systems Engineer should have a strong background in mechanical engineering design, and should be able to collaborate well and interact with students from other fields, specifically electrical engineering teammates. Also, will be responsible for failure analysis. It is recommended that this student be proficient in ANSYS and MatLab.

Additional Mechanical Support - This mechanical engineering student will provide solid modeling support to the chief engineer. Responsible for making sure solid models not related to interfacing with outside design projects are completed accurately and on time.

Power Electronics Engineer - This student is responsible for all electrical design decisions and designs that are associated with powering the motor modules and all parts of the robotic platform.

Communications Engineer - This student is responsible for all design decisions and designs that are associated with the communication between the PC104 central controller, motor controllers, and sensors within the platform, as well as the communication with an outside PC.

Software Engineer - This student is responsible for creating and implamenting the platform motion algorithms, as well as any necessary coding. This will include the coordination of all inputs and outputs.

Systems Integration Coordinator - This student is responsible for checking design decisions against the future plan of the Robotics Platform Track as a whole. They need to ensure that their team project is going in the right direction in terms of scalability, modularity, and feasibility. They will work to make the gap between mechanical and electrical design seamless, and ensure that there is no confusion or conflict with the mechanical and electrical design of the system.

Continuation, Platform, or Building Block Project Information

The mission of the Vehicle Systems Technology Track of projects is to develop a land-based, scalable, modular open architecture, open source, full instrumented robotic/remote controlled vehicular platform for use in a variety of education, research & development, and outreach applications within and beyond the RIT KGCOE. The collection of projects should use an engineering design process to develop modules and subsystems that can be integrated by subsequent senior design teams. This project, P07200, serves as the foundation or starting point for a series of senior design projects.

The mission of each student team contributing to this track is to develop or enhance a particular subsystem for a robotic vehicular platform, and provide complete documentation of the analysis, design, manufacturing, fabrication, test, and evaluation of each subsystem to a level of detail that a subsequent team can build upon their work with no more than one week of background research.

This roadmap will be initiated during the Fall Quarter, 2006-1, with three closely related projects. Additionally, these three projects have significant overlap with projects from the Aerospace Systems and Technology Track (P07100), and the Systems and Controls Track (P07300).

This is a project within the Vehicle Systems Technology Track, to develop a Modular, Scalable, Open Architecure Robotic Vehicle Platform. A critical element of the track is to develop a platform to mount the associated motor modules, motor controller, and data aquisition system on, as well as the payload determined by the end user.

A number of other projects are intimately related to this project, as summarized in the list below.

Related Project Title Start Term End Term
P07200 Vehicle Systems Technology Track 2006-1 On-going
P07201 Motor Module - Robotic Platform 10 kg (RP10) 2006-1 2006-3
P07202 Motor Module - Robotic Platform 100 kg (RP100) 2006-1 2006-2
P07203 Dynamometry 2006-1 2006-2
P07204 RP10 Drive Platform 2006-2 2006-3
P07205 RP100 Drive Platform 2006-2 2006-3
P07301 Data Aquisition (D.A.Q) 2006-1 2006-2
P07302 Motor Controller Subsystem 2006-1 2006-2
P07303 Systems and Controls: Wireless Communications 2007-1 TBD

Principle Sponsor or Sponsoring Organization

Support for this project is generously provided by the Gleason Foundation.

Support for this project is generously provided by the Gleason Foundation.

This project is supported by a gift from the Gleason Foundation to the Mechanical Engineering Department at RIT.

Detailed Project Description

Customer Needs

Interactions with Customers

First Sponsor Interview
Interviewers: K. Nordland
Faculty Guide: Dr. Walters
Teaching Assistant: J. Webb
Date 16 September 2006, Room 2230

Kate: Thanks for meeting with me. As I indicated in my email, I'm preparing the Project Readiness Package for the 100 Kg drive platform senior design group to kick off in winter. Since you're very involved in the current robotic vehicular platform projects, I have several questions for you. To start with, can you tell me about the Robotic Vehicular Platform family of projects?

Jeff: Currently there are 5 senior design projects under this family, the 10 kg motor module, the 100 kg motor module, the dyno, the daq and the motor controller.

Kate: I was aware of the two motor module projects, but I didn't know about the other three. What are those project numbers?

Dr. Walter: P07203 is the Dynomometer, P07301 is the Data Aquisition, and P07302 is the motor controller, which may also serve as the steering controller.

Kate: I understand you've taken on more students than was originally estimated. How has that impacted the scope of the motor module projects?

Jeff: The 10 kg motor module group is expanding into steering control. The 100 kg motor module group is expanding into the sensors on the motor. The plan is that both of these will be able to swap for implementation on the other project. So the steering design that the 10 kg team design should be able to be implemented on the 100kg motor module and vice versa.

Kate: So how do the other groups come into this project?

Jeff: The dyno will be run by the daq to test the motor modules that are run by the motor controller. The dyno should be able to characterize motors, motor transmissions, motor modules as well as a chassis. It should be finished before the FIRST competition at the Field House over spring break.

Kate: I understand that there is a baseline robot that is being built. Can you tell me about those kits what's being done with them?

Jeff: There is an IFI kit that was ordered and built as a baseline for the 100kg motor module. It's going to be tested on an existing dyno to develop a full characterization. That's the D level grade for the 100 kg motor module team. The rest of the project is to scale it to size and improve on the baseline model.

Kate: So when the motor team is done, what will they be delivering to the drive platform team?

Jeff: The package will include the wheel, yoke, motor and transmission.

Kate: What do you see as the scope of the drive platform project team?

Dr. Walter: The platform will need to include a mounting for the microcontroller, the battery, the modular motors, the payload, steering connections, possibly brake connections. It should be scalable, using only OTS components. The project also needs to be completely documented.

Kate: The projects that will be using this robotic platform, do you see them simply using it as a mobile platform, or will they be gathering information from the drive system of the robot?

Dr. Walter: There's a possibilty of both scenarios. There needs to be the ability connect to the robot controller and get information back from the robot. The connections should be easily accessible and simple to connect.
Jeff: You might want to have an industrial engineer on the project to design a clear, easy to use interface to the robot controller.

Kate: Good idea. The motor mounts are to be modular. What's meant by that?

Jeff: The drive platform should have 6 locations available that can be used for placing motors. Any module that isn't being driven will have an idler module in it's place. The motors should be able to be plugged into the motor controller quickly and the platform should function.

Kate: I've read the term "drive by wire". Does that mean tethered?

Dr. Walter: No, drive by wire means that the motor module will include the motor, the transmission and a motor controller. The vehicle controller will use a wire to send the power and instructions to the module. Each wheel will be independent. No axels, or other transmission of power.

Kate:Since there's so many teams working on this project, that seems like a potential trouble spot. How are the current teams dealing with this?

Jeff: They have an executive board that meets to discuss where each of the projects stands. All the of the groups meet on Fridays for updates. The executive board which is the team leader from each group will make the interface decisions for the overlap between groups.

Kate:So the way I see it, the real challenge of this project won't simply be building the platform, but in dealing with the team communications and compatibility, as well as providing the complete top level documentation.

Jeff: Yeah. That's definitely been one of the biggest hurdles so far.

Kate: Would it be possible for me to start sitting in on the executive board meetings? They seem like a great venue to get information on what will be provided to the drive platform team.

Jeff: Sure. They meet on Fridays in the Xerox Auditorium. There's also going to be the DRP that would be a good way to get information on the family projects.

Kate: Great. You have really helped clear up a lot of questions that I had about the project. I'm sure I'll run into more questions as the development of the PRP progresses. In the mean time, I'll plan on attending the Friday meetings for the projects and if I have any other questions, I will get back in touch with you. Thank you so much for your time.

Dr. Walter: See you Friday.
First Customer Interview
Interviewers: K. Nordland, N. Boyer
Customer: Dr. Hensel
Date 29 September 2006, Room 3119

This interview took place throughout a regular meeting regarding Project Readiness Package development. Many customer needs were identified, although it did not fit the flow of a typical interview. During the meeting the following needs were identified.

The mounting design for the 10kg platform and the 100kg platform should be compatible. The design should be done fully in SI units. A T-slot mounting platform, similar to a mill bed, would be an acceptable mounting platform if done to current standards. A fixture plate could be made to interact with the T-slot mounting style but includes dowel pin holes for more accurate alignment. Preferably the fixture plate would be part of the tare weight, meaning the payload would be an addition 100 kg, but that's not critical. The required task to complete at the end of Senior Design 2 would be to have 1 motor module transported between the two configuations. Utilizing more motor modules between the configuations, or also swapping the payload between them would be a higher level of performance. Another desirable would be to have the motor controller portable between configurations OR between sizes. The payload is simply above the drive level. No side or bottom mount areas are necessary. An estimated platform cost would be approximately $20; this is assuming that interchangablity of the motor modules and microcontolers allows for a simple switch of platform framework.

Suggestions given by Dr. Hensel:

Interpretation of Raw Data in Terms of Customer Needs

Voice of the Customer, Project Objective Tree

This objective tree was created using test code from P07898 and pertains solely to P07205
  1. Constraint
    • Safe
  2. Resources
    • Design completed by March 2007
    • Build completed by May 26 2007
  3. Economic
    • Affordable
      • Fits within given budget of $15,000 for family
  4. Scope
    • Of the Shelf components
    • scalable
    • Interchangable modules
    • Better than the baseline kit
    • Useable within the KGCOE
    • "Cool"
      • Impressive looking
      • Exciting technology for "wooing" prospective students
    • Documentation
      • Open source documentation
      • Clearly well documented
      • Should be able to be caught up on in 1 week
  5. Technical
    • Mounts
      • microcontroller mount
      • battery mount
      • modular motor mounts
      • up to 6 motor "slots"
      • payload mount
      • sensor mounts
      • Mount location for antenna
    • Design Constraints
      • Supports required payload
      • Size constraint
        • Can fit through doorways
      • Tare weight constraint
      • Turning radius constraint
      • Remote distance constraint
    • Project compatibility
      • Uses motors developed by 7202
      • Can be mounted on Dyno (P07203) for testing
      • Uses motor control developed by P07302
      • Provides connections for data aquisition by P07301
      • Adabtable for other SD projects needing a robotic platform

Voice of the Customer, Track Objective Tree

The primary customer, Dr. Edward Hensel, representing the mechanical engineering department of RIT, has expressed his objectives for the design project. These objectives should be addressed across a series of projects related to this track. Some individual projects within the track may focus on various areas of these objectives, but all student teams are encouraged to keep the "big picture" in mind, so that their individual project contributions can be more readily integrated with the larger system view.

  1. Constraint Objectives
    • Regulatory Constraints
      • C.1 The design shall comply with all applicable federal, state, and local laws and regulations. Measure of Effectiveness: Every team shall identify at least one federal, state, or local law or regulation that may have an impact on the system design. The team shall demonstrate compliance with said regulations. Particular attention shall be paid to OSHA requirements, and safety codes and standards related to rotating equipment.
      • C.2 The design shall comply with all applicable RIT Policies and Procedures. Measure of Effectiveness: The team shall offer their design for review by the RIT Campus Safety office, and shall rigorously follow RIT procedures associated with purchasing and safety.
      • C.3 Wherever practical, the design should follow industry standard codes and standards. Safety codes shall be treated as design requirements. Industry standards should be used wherever practical. Measure of Effectiveness: The team shall identify at least one mechanical and at least one electrical standard complied with during the design process.
    • Academic Constraints
      • C.10 Every SD1 project should result in a technical report, including a set of design drawings and bill of materials supported by engineering analysis. Measure of Effectiveness: 80% of all SD1 evaluation responses by all review panels should be at a score of "acceptable" or higher.
      • C.11 Every SD2 project should result in a physical engineering model, supported by experimental test and evaluation data. Measure of Effectiveness: 80% of all SD2 evaluation responses by all review panels should be at a score of "acceptable" or higher.
    • Safety Constraints
      • C.20 The top speed of the vehicular platform should be scaled with its size, and should be safe for its operating range (environment).
      • C.21 The vehicular platform shall have on-board and remote "kill switches".
      • C.22 Human safety takes precedence over all other design objectives.
      • C.23 Building and facilities safety takes precedence over robotic vehicular platform damage.
      • C.24 The vehicle should be robust to damage by inexperienced operators.
  2. Resource Objectives
    • People Resource
      • R.0 The minimum acceptable team size is 3 students.
      • R.1 The maximum acceptable team size is 8 students.
      • R.2 The ideal team size is 6 students.
      • R.3 Every design team shall be comprised of students from at least 2 KGCOE departments.
      • R.4 Wherever possible, there should be at least two students from each participating department.
    • Equipment Resource
      • R.10 The project team must have access to required equipment, tools, computers, software, and space to work.
      • R.11 The team members should fabricate most custom components on campus, and the design should consider in-house manufacturing resources.
    • Time Resource
      • R.20 Each student team member should be expected to work a minimum of 8 and a maximum of 16 hours per week on the project. Each student should ideally spend an average of 12 hours per week on the project. The scope of the project has been designed with these limits in mind.
  3. Economic Objectives
    • Materials Costs
      • R.30 The total development budget for the roadmap / track is not anticipated to exceed $15,000 during AY06-07 and 07-08 for first article prototypes of each project. The distribution of this amount between projects in the roadmap is left to the discretion of the DPM team.
      • R.31 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should decrease with increasing volume.
      • R.33 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should decrease with decreasing levels of instrumentation, but shall remain capable of being retro-fitted with instrumentation after initial manufacturing.
      • R.34 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should be borne by the team, faculty member, research project, company, or department desiring to use the item for their research and development work.
    • Labor Costs
      • R.40 The design team is not expected to account for the nominal labor costs of RIT shop personnel as long as the time commitment does not greatly exceed that of other typical SD projects.
      • R.41 The design team is not expected to account for the nominal labor costs of TA's, Faculty, or other staff assigned to assist and guide then team, as long as the time commitment does not greatly exceed that of other typical SD projects.
    • Amortization Costs
      • R.50 The design team is not expected to recover the investment costs associated with the platform development.
  4. Scope Objectives
    • S.1 The robotic platform shall be scalable (1 kg, 10 kg, 100kg, and 1000kg payload variants of the same design)
    • S.2 The robotic platform shall be modular (Modules must be inter-changeable between platforms of same scale)
    • S.3 The robotic platform shall be open architecture (All COTS components must be available from multiple vendors)
    • S.4 The robotic platform shall be open source (All drawings, programs, documentation, data, etc. must be open source published in standard formats)
    • S.5 The robotic platform shall be manufacturable in lots as small as one and as large as 10.
    • S.6 The robotic platform shall NOT be designed assuming that it is targeted for a commercial product.
    • S.7 The robotic platform design shall be available for use and adoption by other commercially oriented SD teams.
    • S.8 Initial targeted payloads (clients) include: (1) the Crassidis MINS client (2) the Yang Networking client
    • S.9 The 100 kg payload vehicular platform must be demonstable at the Summer 2006 sessions of College & Careers, and high school students desiring to do so must be able to operate the vehicle under remote control.
  5. Technology Objectives
    • T.1 The 10 Kg and 100 kg robotic platform motor modules shall be designed and built first.
    • T.2 The 1 and 1,000 Kg robotic platform motor modules shall be designed and built second.
    • T.3 The range of the 100 Kg robotic platform shall be the James E. Gleason Building, RIT Bldg #09.
    • T.4 The range of the 10 Kg robotic platform shall be the floor of a single room in the James E. Gleason Building, RIT Bldg #09.
    • T.5 The range of the 1 Kg robotic platform shall be an 8'8 by 8' table top.
    • T.6 The range of the 1,000 Kg robotic platform shall be the RIT Campus.
    • T.7 Technologies, software, modules, algorithms, and other developments should be made available to and accessible by the Underwater vehicle platform team and the airborne vehicle platform teams, and vice-versa.
    • T.8 The results of this platform development roadmap should increase the reputation and visibility of the RIT SD program and our robotics technology "skill level" on a national basis. Measure of Effectiveness: By June 2008, at least five student-authored conference papers shall be submitted for publication at technical conferences (outside of the RIT senior design conference). Measure of Effectiveness: By June 2008, at least one student-authored journal paper shall be submitted for publication.
    • T.9 The modules of the robotic platform shall be re-configurable into many different configurations. For example, it should be EASY and LOW COST to take expensive drive components for individual wheel drives and assemble them into 3-wheel, 4-wheel, and 6-wheel configurations, with the number of driven wheels ranging from 1 to 6.
    • T.10 The preferred motion control technology is drive by wire.
    • T.11 The preferred energy source is rechargeable DC battery.
    • T.12 Technology priorities: (1) Two Wheel drive, skid steer (2) Two wheel drive, turn steer (3) Position and heading data logging (4) Autonomous control by the payload client (5) Passive Suspension (6) DFMA (7) Active suspension
    • T.13 As every technology is introduced that technology must be (1) observable by and (2) controllable by the payload client.
    • T.14 Each variant of the vehicle must be clearly impressive to any student, parent, engineer, mentor, or individual familiar with the FIRST robotics competition.

Customer Deliverables

Design and build a triangular and a rectangular drive platform incorporating the motor modules, motor controller and battery provided and including a platform top with mounting points for securing a payload. Provide complete documentation of the design, manufacture, assembly and operation.

Customer and Sponsor Involvement

The team will be expected to carry out the vast majority of their interactions with the Team Guide (Dr. Walter), and the teaching assistant (Jeff Webb). Dr. Hensel (The sponsor and customer) will be available for a series of meetings during the course of the project. Dr. Hensel will meet with a group of teams during the beginning of SD1 to lay out common goals, objectives, and philosophies for the sequence of projects being sponsored by the Gleason Foundation gift to the ME Department. It is anticipated that Dr. Hensel will meet with the team (or multiple related teams) for 2 hour meetings approximately 4 times during senior design 1, and twice during senior design 2. Dr. Hensel will participate with team communications electronically, through the web site as well. Kate Nordland will be available for up to 2 hrs a week for help with regard to the P07898 software.

Regulatory Requirements

Project Budget and Special Procurement Processes

There is a pre-defined limit of $600 for this project. The team in must demonstrate that their expenditures are in-line to satisfy both the requirements of the individual project, as well as to set the stage towards completion of the overall objectives of the track.

Each team will be required to keep track of all expenses incurred with their project, and to communicate with members of other teams in the track, to insure that the overall track budget as well as the individual project budgets are being followed.

Purchases for this track will be run through the mechanical engineering procurement system. Dave Hathaway (Operations Manager) for the ME department will be point of contact for most purchases associate with this project and this track. It is recommended that each team appoint one person to act as the purchasing agent for the team, and that all interactions between the team and Dave go through the single purchasing agent. The team is responsible for providing all receipts, copies of invoices, shipping documents, and proper use of tax exempt forms, etc.

Intellectual Property Considerations

All work to be completed by students in this track is expected to be released to the public domain. Students, Faculty, Staff, and other participants in the project will be expected to release rights to their designs, documents, drawings, etc., to the public domain, so that others may freely build upon the results and findings without constraint.

Students, Faculty, and Staff associated with the project are encouraged to publish findings, data, and results openly.

Engineering Specifications

Drive Platform Specifications

Voice of the Engineer

Figure 1: Prototype Configuration Requirements

Figure 1: Prototype Configuration Requirements

Table 1: Tradeoff Assessment
Model Size (m) Tare Weight (kg) Payload Capacity (kg) Speed (m/s) Turning Radius (m) Remote Range (m)
R100 0.60 x 0.75 x 0.50 40 100 4.5 1.00 60
Useful Web Resources

You may find it helpful to review these web resources to get comfortable with robotic platforms.

Seekur All weather Robot A robotic base that carries up to a 70 kg payload with omni direction drive. - Base price of just under $60,000.

T-slot tables Prefabricated t-slot tables.

Segway RMP The makers of the segway now offer a robotic mobility platform.

Initial Concepts to Consider
Quick mock up in ProE

Quick mock up in ProE

The top mounting plate should not get in the way of the "guts" of the robot. A mount surface that was detachable or pivoting would be advantageous. Also the mount surface should not be "unique". Using a standard mounting type, such as the t-slot shown below should be considered. Another option, especially if the top mounting plate was detachable, would be a real simple frame to locate the mounting holes, that a user could build their own customized mount plate if necessary.

In the initial sketch on the right, the cylinders are the motor mount areas, the block in the back is the battery, and the open spot in the middle would be the mount location for the PC104 boards. The first week of SD1 should be spent gathering the models of these designs and pulling them together into a rough layout to obtain a better idea of the space constraints.

Safety Constraints

Detailed Course Deliverables

Note that this level describes an absolute level of expectation for the design itself, and for the hardware. However, the student team must also meet all requirements related to analysis, documentation, presentations, web sites, and posters, etc. that are implicit to all projects.

See Senior Design I Course Deliverables for detail and Design I Grading for a specific breakdown.

The following tasks should be completed by the end of SD1:
The following tasks should be completed by the end of SD2:

Three-Week SDI Schedule

Preliminary Work Breakdown

This project will closely follow the three week project workshop schedule presented in SD1. See the Course Calender for Details.

In addition, the following tasks should be completed ASAP:

  1. Go over the information on the edge website, from the Design Project Management Robotics Platform Roadmap, and in the Preliminary Information binder.
  2. Discuss progress made by previous Vehicle Systems Technology Track teams.

The following roles are not necessarily to be followed by the team. It is merely to justify the number of students from each discipline. The student team is expected to develop their own work breakdown structure, consistent with the general work outline presented in the workshop series at the beginning of SD1. However, the customer requests a level of detail NO GREATER than weekly tasks to be completed by each student team member for the benefit of the other team members. The customer DOES NOT request any level of detail finer than one-week intervals, but will assist the team members if they wish to develop a finer level of detail to support their own efforts.

This section has not been updated with the change in personel. It should be modified by the team leader at the beginning of week 1.

EXPECTED DELIVERABLES FROM WORK BREAKDOWN
Student Week 1 Week 2 Week 3
ME 1 - Project Manager

Schedule and run the first meeting. A sample agenda is provided here. Meet with fall quarter teams project manager to establish a baseline of what's been done. Review customer needs statement from above. Conduct followup to verify the needs analysis. Assign work to team members. Determine meeting times for the remainder of the quarter. Set up the P07205 wiki page and begin populating with team information.

Utilize P07898 software to enter in needs determined. Use group consensus to organize the needs into objective trees or affinity diagrams. Apply a pairwise comparison to establish a ranking of the importance of the needs. Determine the engineering functions necessary to meet the needs of the customer. Organize into a function tree. Add the objective tree, pairwise comparison and function tree to the P07205 page. Prepare for week 3 concept development sessions. Lead team concept development sessions. Use an assortment of brainstorming, brainball, and group drawing. Use the function tree to drive concept development in P07898 software. Use pareto voting to determine the top 4 feasible design options. Assign team members to run with designs. Before break, reconnect for design options review. Determine additional work to be done over break.
ME 2 - Chief Engineer

Establish standards to use for the solid modeling with in the team. Determine where, and in what form to store files. Lead initial modeling effort to document the path to be traversed in the final test run. Setup a design effort page on the P07205 wiki page. Talk to chief engineers from related project teams to determine interfaces to the drive platform.

Set up change order protocol for modifying interfaces with other teams. Build a solid model library of potential components to aid in quick assembly of concept models. Participate in needs assessment. Participate in concept development. Begin assembling components for modeling concepts.
ME 3 - Dyno interface

Prepare an informal presentation that will allow the rest of the group to gain background knowledge of P07203, what must be considered for the dyno while designing our project, and how to get more information if needed in the future. Summarize report on P07205 webpage using wiki format. Aid the chief engineer in measuring the path to travel and building the 3d model.

Participate in needs assessment. Verify that the dyno interface is being incorporated into the needs assessment. Get the 3-D model of the dyno design imported into Pro/E. Participate in concept development. Work on further developing assigned concepts. Prepare concept for presentation to team before break.
ME 4 - Mechanical Motor interface

Prepare an informal presentation that will allow the rest of the group to gain background knowledge of P07202, what is being delivered with the motor module, and how to get more information if needed in the future. Summarize report on P07205 webpage using wiki format. Obtain the 3D models of the motor module and import into Pro/E.

Participate in the needs assessment. Verify that the motor interface is being incorporated into the needs assessment. Get the 3D models of the PC104 boards from P07301 and P07302 imported into Pro/E. Participate in concept development. Work on further developing assigned concepts. Prepare concept for presentation to team before break.
ME 5 - Payload interface

Prepare an informal presentation that will allow the rest of the group to gain background knowledge of the anticipated payloads to be accomodated, and standard methods of securing a payload. Summarize report on P07205 webpage using Wiki format. Aid the chief engineer in measuring the path to travel and building the 3d model.

Participate in the needs assessment. Verify that the payload interface is being incorporated into the needs assessment. Begin modeling 3D models of standard payload securing methods. Participate in concept development. Work on further developing assigned concepts. Prepare concept for presentation to team before break.
EE 1 - Electrical motor interface

Prepare an informal presentation that will allow the rest of the group to gain background knowledge of P07202, what must be considered electronically for the motor module while designing our project, and how to get more information if needed in the future. Summarize report on P07205 webpage using Wiki format.

Participate in the needs assessment. Verify that the motor interface is being incorporated into the needs assessment. Get electrical design from the motor modules documented. Participate in concept development. Work on further developing assigned concepts. Prepare concept for presentation to team before break.
EE 2 - Electrical microcontroller / DAQ interface Prepare an informal presentation that will allow the rest of the group to gain background knowledge of P07301 and P07302, what must be considered while designing our project, and how to get more information if needed in the future. Summarize report on P07205 webpage using Wiki format. Participate in the needs assessment. Verify that the PC104 boards interface is being incorporated into the needs assessment. Get electrical design from the PC104s documented. Participate in concept development. Work on further developing assigned concepts. Prepare concept for presentation to team before break.

The link below is a detailed descriptions of work breakdown structure of each team member of the P07204 project.

Detailed Preliminary Work Breakdown

Grading and Assessment Scheme

Grading of students in this project will be fully consistent with grading policies established for the SD1 and SD2 courses. The following level describes an absolute level of expectation for the design itself, and for the hardware. However, the student team must also meet all requirements related to analysis, documentation, presentations, web sites, and posters, etc. that are implicit to all projects.

Level D:
The student team will build a functioning triangular robot to carry a 30 kg payload through the halls on the first floor of the James Gleason building. The robot will be operated by a team member via a tethered controller. The overall appearance of the robotic platform is capable of impressing perspective students.
Level C:
The student team will deliver all elements of Level D PLUS: The student team will build a functioning rectangular robot to carry a 100 kg payload through the halls on the third floor of the James Gleason building. The project design will be documented.
Level B:
The student team will deliver all elements of Level D and C PLUS: The drive platforms will be capable of changing floors via the elevators. One motor module will be interchanged from the triangular platform to the rectangular platform within 120 seconds.
Level A:
The student team will deliver all elements of Level D, C, and B PLUS: All three motor modules from the triangular platform are changed over into the rectangular platform and the fully documented task described above has been completed. The design, build, assembly and operation has been fully documented and made available to the public.

Required Resources

Faculty
Item Source Description Available
Prof. Walter ME Faculty Guide/Coordinator/Mentor Yes
Prof. Hensel ME Customer Yes
Prof. Slack EE Technical Consultant Yes
Environment
Item Source Description Available
Robotics Lab ME 09-2230 Work Space/Storage Yes
Sr Design Lab EE 09-3xxx Work Space Yes
ME Shop ME 09-2360 Parts Fabrication Yes
Equipment
Item Source Description Available
DC Motor Dyno EE Electric Machines Lab Characterization Unknown
Power-supply EE Department Used for Testing Unknown
Desktop PC Throughout Programming Yes

The team members will be expected to procure the materials needed for the project, excluding the following:

Materials
Item Source Description Available
Super Droid Robot ATR Teaching Assistant 10kg payload example Yes
IFI Robotics Kit Teaching Assistant 100kg payload example Yes

Requested Resources

In order to be successful on this project, it would be greatly advantageous to have the following items in place.

A mutual request is made for alpha testing of the P07898 web based interface for clarifying the fuzzy front end of the design process. P07898 is the thesis project for Kate Nordland and is being developed to help multidisciplinary design teams deal with identifying the customer needs, translating the needs into concepts and evaluating their feasibility. In order to evaluate the effectiveness of the software, P07204 and P07205 are being asked to utilize the software and provide feedback. While the hope is that this software will be an asset in the early stages of the design process, it is understood that learning a new software and dealing with possible bugs can be frustrating at times. Kate Nordland will be available on Fridays and upon request through out the quarter to explain how the software works and deal with any issues as they arise.

Students on this team will be asked to periodically provide feedback as to how they felt the software impacted their design process. Their participation in this evaluation is very helpful and greatly appreciated.

Possible Areas of Concern

It is acknowledged that one of the largest areas for concern in this family of projects is the interconnected nature of the teams. There is a large dependancy on other people to pull through for your team to be successful. Prompt responses to questions for information are critical. Decisions with regards to the project interfaces need to be made quickly and not to be waiting for someone else to make the call. Consideration must be made for the P07300 family of projects which are not being made solely for use on this robotic platform. While the requirements for an A on the project have been laid out, there is significant room to go above and beyond this scope. In order for the project to reach the highest level of impressiveness, the team will need the buy-in from all of the team members, as well as team members from additional teams.