P07205 Project Readiness Package
- Project Name
- RP 100 Drive Platform
- Project Number
- Project Family
- P07200 Modular Robotic Vehicle Platform
- Vehicle Systems Technology
- Start Term
- End Term
- 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
Mission StatementTo 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.
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:
- 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.
- 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.
- 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
- The team will be given five x and y coordinates (in inches) by an instructor.
- 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.
- 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.
|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 email@example.com|
|George Slack||EE||Faculty Consultant, Will provide EE discipline technical support on an intermittant firstname.lastname@example.org|
|Jeff Webb||ME||Teaching Assistantemail@example.com|
|Kate Nordland||ME||Project Readiness Package author, P07898 software firstname.lastname@example.org|
|James Aclub||EE||Electrical Systems Leademail@example.com|
|Jesse Baker||ME||Systems Integration Coordinatorfirstname.lastname@example.org|
|Jeffrey Gill||ME||Mechanical Craftsmanemail@example.com|
|Arnold David Gomez||ME||Lead Engineerfirstname.lastname@example.org|
|James Harris||EE||Software Engineeremail@example.com|
|Benjamin Smith||ME||Mechanical Designerfirstname.lastname@example.org|
|Aman Verma||EE||Electrical Craftsmanemail@example.com|
|Tian Zeng||EE||Electrical Designerfirstname.lastname@example.org|
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|
|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
Detailed Project Description
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:
- Change 100kg path to stop at 10kg location, interchanging some 100kg components with 10kg platform components (e.g. Use 10kg motor module as steering module for 100kg).
- Record wheel rotation to be able to track the movement of the vehicular platform (has been accomplished by previous projects).
- Primary focous should NOT deviate to having an autonomous robotic platform; this will be developed later by a future design team.
Interpretation of Raw Data in Terms of Customer Needs
- The drive platform must be scalable
- The drive platform must be modular(Motor modules must be inter-changeable between platforms of same scale)
- The drive platform must be open architecture (All COTS components must be available from multiple vendors)
- The drive platform must be open source (All drawings, programs, documentation, data, etc. must be open source published in standard formats)
- The drive platform must be manufacturable in lots as small as one and as large as 10.
- The drive platform shall NOT be designed assuming that it is targeted for a commercial product.
- The drive platform design shall be available for use and adoption by other commercially oriented SD teams.
- The drive platform shall provide mounts for the motor modules to 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.
- The results of this platform should increase the reputation and visibility of the RIT SD program and our robotics technology "skill level" on a national basis.
- This robotic platform must be clearly impressive to any student, parent, engineer, mentor, or individual familiar with the FIRST robotics competition.
Voice of the Customer, Project Objective TreeThis objective tree was created using test code from P07898 and pertains solely to P07205
- Design completed by March 2007
- Build completed by May 26 2007
- Fits within given budget of $15,000 for family
- Of the Shelf components
- Interchangable modules
- Better than the baseline kit
- Useable within the KGCOE
- Impressive looking
- Exciting technology for "wooing" prospective students
- Open source documentation
- Clearly well documented
- Should be able to be caught up on in 1 week
- 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.
- 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.
- 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.
- 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.
- Regulatory Constraints
- 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.
- 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.
- 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.
- People Resource
- 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.
- 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.
- R.50 The design team is not expected to recover the investment costs associated with the platform development.
- Materials Costs
- 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.
- 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.
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.
- The design shall comply with all applicable federal, state, and local laws and regulations. The team's design project report should include references to, and compliance with all applicable federal, state, and local laws and regulations.
- The design shall comply with all applicable RIT Policies and Procedures. The team's design project report should include references to, and compliance with all applicable RIT Policies and Procedures.
- Wherever practical, the design should follow industry standard codes and standards (e.g. Restriction of Hazardous Substances (RoHS), FCC regulations, IEEE standards, and relevant safety standards as prescribed by IEC, including IEC60601). The team's design project report should include references to, and compliance with industry codes or standards.
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.
- The total development budget for the Vehicle Systems Technology 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 Coordinator.
- The cost to manufacture subsequent copies of the final design, sub-assembly, or part should decrease with increasing volume.
- The cost to manufacture subsequent copies of the final design, sub-assembly, or part should decrease with decreasing levels of instrumentation, but shall remain capable of being retro-fitted with instrumentation after initial manufacturing.
- The cost to manufacture subsequent copies of the final design, 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.
- The design team is not expected to account for the nominal labor costs of RIT shop personnel as long as their time commitment does not greatly exceed that of other typical SD projects.
- 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 their time commitment does not greatly exceed that of other typical SD projects.
- The design team is not expected to recover the investment costs associated with the platform development.
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.
- Drive Platform Specifications
- The drive platform must be capable of integrating motor modules onto a platform with future features and projects such as data acquisition, data logging, advanced user interface, power and control of peripherals, and autonomous control.
- The drive platform must be designed in such a way as allow for easy modification for future work with active steering.
- The drive platform must be easy for a third party to understand, use, and modify.
- The drive platform must be manufactured in a clean, elegant looking package.
- The drive platform must include storage for the rechargeable DC battery.
Voice of the Engineer
- V.1 The platform must be demonstrated functional in the two different configurations shown below.
- V.2 The drive platform must be designed in such a way as to be able to incorporate motor modules on any shape platform with any number of driven and idler modules.
- V.3 The design enveloped for relevant engineering specifications are tabulated below for each size of rectangular platform.
|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|
- V.4 Deliverables required for each phase include, but are not limited to a fully functional prototype that meets all performance specifications, a complete collection of mechanical drawings, a bill of materials, and all software used.
- V.5 The platform must be capable of integrating future features and projects such as data acquisition, data logging, advanced user interface, power and control of peripherals, and autonomous control.
- V.6 The platform must be easy for a third party to understand, use, and modify.
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
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.
- The top speed of the vehicular platform should be scaled with its size, and should be safe for its operating range and environment.
- The vehicular platform shall have on-board and remote "kill switches".
- Human safety takes precedence over all other design objectives.
- Building and facilities safety takes precedence over robotic vehicle platform damage.
- The vehicle should be robust to damage by inexperienced operators.
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.
- The following tasks should be completed by the end of SD1:
- Fully designed and modeled triangular and recangular
platform configurations. These designs will include:
- Adjustable payload mount design
- Easily interchangeable motor modules from one configuration to the next
- The use of open source documentation
- The use of off the shelf components
- All CAD models and/or drawings for the platform will be placed in the P07200 family repsitory in an industry standard format.
- The following tasks should be completed by the end of SD2:
- Deliver working prototypes of a triangular and rectangular platform configurations incorporating: 4 idler modules and 3 powered motor modules.
- The robotic platform should be able to accomplish the path mentioned in the project overview, navigating through the James Gleason Building, minus stairways
- The Platform will be interchangeable from a triangular configuration to a rectangular configuration.
- The Platform will be capable of carrying a 30kg payload (triangular configuration) and a 100kg payload (rectangular configuration).
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:
- Go over the information on the edge website, from the Design Project Management Robotics Platform Roadmap, and in the Preliminary Information binder.
- 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.
|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.|
|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.|
The link below is a detailed descriptions of work breakdown structure of each team member of the P07204 project.
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.
|Prof. Walter||ME||Faculty Guide/Coordinator/Mentor||Yes|
|Prof. Slack||EE||Technical Consultant||Yes|
|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|
|DC Motor Dyno||EE Electric Machines Lab||Characterization||Unknown|
|Power-supply||EE Department||Used for Testing||Unknown|
The team members will be expected to procure the materials needed for the project, excluding the following:
|Super Droid Robot ATR||Teaching Assistant||10kg payload example||Yes|
|IFI Robotics Kit||Teaching Assistant||100kg payload example||Yes|
Requested ResourcesIn order to be successful on this project, it would be greatly advantageous to have the following items in place.
- SVN access to solid models of associated projects
deliverables in an industry standard format. Desired
solid models include
- A solid model of the P07202 motor module
- Includes motor and transmission elements
- Includes wheel
- Includes mounting hardware
- Includes steering support
- Includes sensors
- A solid model of the P07301/P07302 PC104 boards including any modifications
- A solid model of the battery unit to be used
- A solid model of the dyno interface to the robotic platform
- A solid model of the P07202 motor module
- An engineering change order protocol established for documenting changes between projects
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.