Table of Contents
RP1 Robotic Vehicle Platform Project Family
Customer's Mission Statement
The mission of the RP1 family of projects is to develop a land-based, modular, open architecture, open source, extensible, fully 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 RP1 family should provide a vehicle platform to support a variety of payload of nominally 1 kg in mass, and the ability to traverse terrain typical of interior buildings at RIT, exclusive of staircases and other vertical obstacles. Additionally, modular components of the RP1 family should be readily used by faculty and students as sophisticated components for their own applications designs.
The RP1 family of projects should incorporate lessons learned from prior work on the RP10 and RP100 families of projects. The RP1 family of projects should use an engineering design process to develop modules and subsystems that can be integrated by subsequent senior design teams. This roadmap builds upon prior work that senior design students have completed on 100 kg and 10 kg payload variants of the family.
The mission of each student team contributing to this project family 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.
The RP1 family is planned to evolve over multiple generations of the product release, with an annual product release date of nominally 1 May. Preliminary Product development budgets will be allocated on 1 September for the next development year, and finalized on 1 December for the development year. Each development year will nominally follow the academic year schedule. The majority of expenditures are anticipated to take place during the winter and spring quarter each year. The fall quarter will generally be focused on design, and testing outcomes and performance from prior year hardware.
- The Alpha generation product release date is Saturday, 2 May 2009. The alpha generation will be demonstrated at the RIT Innovation and Creativity Festival, ImagineRIT.
- The Beta generation product release date is tentatively scheduled for Saturday, 1 May 2010.
- The Gamma generation product release date is tentatively scheduled for 1 May 2011.
- The Delta generation product release date is tentatively scheduled for 1 May 2012.
- The Epsilon generation product release date is tentatively scheduled for 1 May 2013.
- The Zeta generation product release date is tentatively scheduled for 1 May 2014.
Voice of the Customer
The RP1 family of projects should build upon and use the resources purchased for and developed by past senior design teams working on the RP10 and RP100 families, as indicated below.
|Historical Foundation Projects||Title||DPM Term||SD1 Start Term||SD2 End Term|
|P07201||RP10 Motor Module||2005-3||2006-1||2006-3|
|P07202||RP100 Motor Module||2005-3||2006-1||2006-3|
|P08201||RP 10 Robotic Platform 2nd Generation||2006-3||2007-1||2007-3|
|P08205||RP 1 Motor Module First Generation Wireless Communications||2007-1||2007-2||2007-3|
|P08208||RP 1 Motor Module First Generation Drivetrain||2007-1||2007-2||2007-3|
Customer's Objective Tree
Primary Objective: The mission of the RP1 family of projects is to develop a land-based, modular, open architecture, open source, extensible, fully 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 primary objective will be accomplished subject to numerous additional objectives, as identified in the listing below. These objectives should be addressed across a series of projects related to this project family. 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's design project report should include references to, and compliance with all applicable federal, state, and local laws and regulations.
- C.2 The design shall comply with all applicable RIT Policies and Procedures. Measure of Effectiveness: Every team's design project report should include references to, and compliance with all applicable RIT Policies and Procedures.
- C.3 Wherever practical, the design should follow industry standard codes and standards. Measure of Effectiveness: Every team's design project report should include references to, and compliance with at least one industry code or standard.
- 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. The design and testing results shall be published in the annual proceedings of the Multi-disciplinary design conference in the KGCOE at RIT. Measure of Effectiveness: 80% of all SD2 evaluation responses by all review panels should be at a score of "acceptable" or higher.
- C.12 Every SD2 project should conduct a formal customer interview/review to establish the level of customer satisfaction with the project outcomes. Measure of Effectiveness: 100% of the customers engaged in the MSD program should return for additional projects.
- 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 vehicle platform damage.
- C.24 The vehicle should be robust to damage by inexperienced operators.
- C.30 The RP1 family is planned to evolve over multiple generations of the product release, with an annual product release date of nominally 1 May.
- 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.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.
- People Resource
- R.31 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should decrease with increasing volume.
- 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 teams are expected to account for the nominal labor costs of RIT shop personnel using a hypothetical billing rate of M$D50 per hour. This include the cost of shop machine tool usage.
- R.41 The design teams are expected to account for the nominal labor costs of TA's, Faculty, or other staff assigned to assist and guide then team, using a hypothetical billing rate of M$D100 per hour.
- R.42 The design teams are expected to account for the nominal labor costs of student engineering design team members using a hypothetical billing rate of M$D75 per hour.
- R.50 The design teams are 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 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
- T.1 The RP1 is a robotic platform exhibiting a payload range from 0.1 to 1 kg.
- T.2 The range of the 1 Kg robotic platform shall be the James E. Gleason Building, RIT Bldg #09.
- T.3 The preferred motion control technology is drive by wire.
- T.4 The preferred energy source is rechargeable DC battery.
- T.5 This roadmap will be updated annually by DPM students, with a benchmarking study, to articulate the general state of the art with similar products and technologies under development at enterprises other than RIT.
Voice of the Engineer
The customer, who is an engineer, has defined that this roadmap will be developed using a modular design approach, and that each module must be a useful product by itself, in addition to being useful as an integrated package of modules. The basic idea for the evolution of the modules are illustrated in the figure below.
This is a graphical image of the RP1 roadmap, showing historical contributions from the RP10 and RP100 families, and a future plan for the RP1 family.
Engineer's Function TreeThe engineer has created a function tree for the design as follows.
Primary Function: Design, Build, Test, and Deliver a land-based, modular, open architecture, open source, extensible, fully 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 primary function will be accomplished by meeting the various subfunctions, as identified in the listing below.
- Each robotic platform will have one or more powered motor modules, one or more idler modules, and a single system controller.
- The robotic platform should be easily reconfigurable to a wide range of user applications. Users may choose to mount a combination of powered motor modules and idler motor modules in a variety of ways, to meet the needs of their particular project. The platforms themselves are expected to be much more variable than the other components of the system.
|P07204 - RP10 Platform||P07205 - RP100 Platform|
- The motor module shall be capable of forward motion at 100% of rated speed for the selected motor.
- The motor module shall be capable of reverse motion at 75% of rated speed for the selected motor.
- The drive motor shall be from the XYZ family of motors, with variable gearboxes installed depending upon the application needs.
- The steering motor shall be from the XYZ family of motors, with variable gearboxes installed depending upon the application needs.
- The Beta Generation motor module shall be capable of turning left up to 105 degrees.
- The Beta Generation motor module shall be capable of turning right up to 105 degrees.
- The motor module design concept should be scalable across four orders of magnitude (payload capacity), and should have a standardized mounting interface, power connection, and sensor connection at each scale level.
- Effort should be made to re-use materials across scales -- for example, the drive motor for a large scale motor module may become the steering motor for the smaller scale motor module, etc. The motor modules themselves, should be largely mechanical devices, with electric motors and sensors attached. The motor modules should generally not be intelligent.
- A low cost idler module should be similar to an powered motor module, except that the motors are not installed.
- Motion Function
- The Beta Generation motor module shall be capable of encoding drive shaft position within an accuracy of 5 degrees.
- The Gamma Generation motor module shall be capable of encoding steering angle position within an accuracy of 0.5 degrees.
Maintenance and Repair Functions
- The wheel of the motor module must be easily replaced by one person using no more than two hand tools, in less than 3 minutes.
- Users may employ the modules developed under this family of projects in a variety of ways not yet anticipated. A good design will prove robust to future applications.
- DC Motor Control
- Wireless Communications
- Sensors and Feedback
- Each robotic platform (developed by the user), must have one platform controller installed on-board.
- The platform controller consists of a micro-processor, and four standard interfaces. The platform controller may connect to an extensible number of motor controllers, sensors, communications links, and payload interfaces.
- The payload interface is the single (wired) means of communication between the platform controller, and the user's payload.
- In some configurations, the platform controller may be a slave to the master controller on the user's payload.
- In other configurations, the platform controller may be independent of the payload. In other applications, the payload computer (if any) may be a slave to the platform controller.
- The physical connector between the payload and the payload interface may be different for different scales (1, 10, 100, 1000 kg variants), but the software interface for the 1000 kg variant must be a superset of the software interface for the 100 kg variant, etc.
- The motor-module interface subsystem consists of (wired) PWM digital signals sent to a plurality of DC motor controllers AND (wired) encoder sensor data inputs for feedback from motor module encoders.
- The physical connector between the payload and the payload interface may be different for different scales (1, 10, 100, 1000 kg variants), but the digital signals must be identical across the variants.
- The sensors and feedback interface subsystem consists of (wired) connections to a host of analog and digital sensors that may be added to the platform itself. Generally, this interface is not intended for user/payload sensors. For example, is the platform evolves as an autonomously navigating system with ultrasonic sensors on board, then those sensors would be interfaced through this subsystem. If the platform is a dumb platform, and the user payload is doing the autonomous navigation, then the user payload may have its own sensors, and simply send commands to the platform controller through the payload interface.
- The physical connector between the sensors may be different for different scales (1, 10, 100, 1000 kg variants), and different sensors, but the intent should be to standardize the connectors over time.
- The communication interface subsystem consists of a wired connection to a host computer.
- The host computer may be used to drive the system via tether or through an intermediate wireless communications link.
Each year, the DPM and MSD students are to update the 'state of the art' technology roadmap as part of their benchmarking activities. As students prepare the out-year projections they are expected to determine what types of technology (both open source and proprietary) are likely to be available and may impact not only subsystems but the entire architecture. Student teams are expected to conduct benchmarking and external observation so that they understand not only what's available but how to go about getting information and synthesizing it. As information comes available about work done by others, include links in the table below that (a) link to the original work, and (b) link to your competitive analysis of that work.
Roadmap Interface Specifications
|Functional Subsystem||Motor Modules||DC Motor Control||Wireless Communications||Sensors and Feedback||Software System|
|Platform||Platform to Motor Module||Platform to DC Motor Control||Platform to Wireless Communications||Platform to Sensors and Feedback||Platform to Software System|
|Motor Module||XXXX||Motor Module to DC Motor Control||Motor Module to Wireless Communications||Motor Module to Sensors and Feedback||Motor Module to Software System|
|DC Motor Control||XXXX||XXXX||DC Motor Control to Wireless Communications||DC Motor Control to Sensors and Feedback||DC Motor Control to Software System|
|Wireless Comms||XXXX||XXXX||XXXX||Wireless Communications to Sensors and Feedback||Wireless Communications to Software System|
|Sensors & Feedback||XXXX||XXXX||XXXX||XXXX||Sensors and Feedback to Software System|
Functions and Means Morphological Chart
|Functional Subsystem||Means Alpha||Means Beta||Means Gamma||Means Delta||Means Epsilon||Means Zeta|
|Platform||Basic Triangular Platform||Basic Rectangular Platform||Semi-Truck Platform||Snake / Train Platform with Single Engine||Snake / Train Platform with Multiple Engines||First Year Student Platform Design Competition|
|Motor Module||Direct Drive Forward and Reverse Motion||Direct Drive Left and Right Steering||Cost Reduction, Mass Production, Reliability Increase||Rudimentary Suspension System||Active Suspension System||Cost Reduction, Mass Production, Reliability Increase|
|DC Motor Control||Open Loop Speed Control||Open Loop Position Control||Feedback Speed Control||Feedback Position Control||Regenerative Braking||Cost Reduction, Mass Production, Reliability Increase|
|Wireless Comms||Crossbow XCVR technology||Cost Reduction, Mass Production, Reliability Increase||SPI command interface||RIT Open Source Wireless Command & Control||CAN Command interface||Cost Reduction, Mass Production, Reliability Increase|
|Sensors & Feedback||Encoder data recording and dead reckoning||Encoder feedback control||Rudimentary Obstacle Avoidance||Autonomous Maze navigation||Communication to and from peers||Collaborative behavior|
|Software System||Basic text command line interface, minimal instruction set||GUI interface, with expanded instruction set||PIC Family Microprocessor||FPGA Family microprocessor||Linux Host interface on platform or base station||Autonomous Navigation and Systems of Robots|
Index to Related Projects on the Roadmap
The RP1 family of projects currently consists of the sub-projects as listed in the table below, and builds upon prior foundation projects from the RP10 and RP100 families as indicated below.
|Related Project||Title||DPM Term||SD1 Start Term||SD2 End Term|