|
Table of Contents
|
Vehicle Systems Technology Track
Project Family: Robotic Vehicle Platform
The mission of this family of projects, within the Vehicle Systems Technology Track, 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 family of projects should use an engineering design process to develop modules and subsystems that can be integrated by subsequent senior design teams. 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 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.
| Academic Year | Platform Integration | Motor Modules | DC Motor Control | Wireless Communications | Sensors and Feedback | Software Systems | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Basic Concept |
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. 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. |
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. Each motor module should be capable of forward and reverse motion, and be able to turn left and right approximately 105 degrees. A low cost idler module should be similar to an powered motor module, except that the motors are not installed. |
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 plaform 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. |
||||||||
| AY2006-07 | |||||||||||
| AY2007-08 | |||||||||||
| AY2008-09 | |||||||||||
| AY2009-10 | |||||||||||
| AY2010-11 | |||||||||||
| AY2011-12 |
This family of projects currently consists of the sub-projects as listed in the table below.
| Related Project | 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 |
| P07204 | RP10 Platform | 2006-1 | 2006-2 | 2006-3 |
| P07205 | RP100 Platform | 2006-1 | 2006-2 | 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 |
Needs Assessment
Voice of the Customer
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.
-
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'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.
-
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 vehicle platform damage.
- C.24 The vehicle should be robust to damage by inexperienced operators.
-
Regulatory Constraints
-
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.
-
People Resource
-
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 teams are 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.
- R.41 The design teams are 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.
-
Amortization Costs
- R.50 The design teams are not expected to recover the investment costs associated with the platform development.
-
Materials Costs
-
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 demonstrable 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.
-
Technology Objectives
- T.1 The 100 Kg robotic platform (payload range from 10 to 100 kg) shall be designed first.
- T.2 The 100 Kg robotic platform (payload range from 10 to 100 kg) shall be built first.
- T.3 The 10 Kg robotic platform (payload range from 1 to 10 kg) shall be designed second.
- T.4 The 10 Kg robotic platform (payload range from 1 to 10 kg) shall be built second.
- T.5 The 1 Kg robotic platform (payload range from 0.1 to 1 kg) shall be designed and built third.
- T.6 The range of the 100 Kg robotic platform shall be the James E. Gleason Building, RIT Bldg #09.
- T.7a 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.7b The range of the 1 Kg robotic platform shall be an 8'8 by 8' table top.
- T.7c The range of the 1,000 Kg robotic platform shall be the RIT Campus.
- T.8 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.9 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.10 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.11 The preferred motion control technology is drive by wire.
- T.12 The preferred energy source is rechargeable DC battery.
- T.13 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.14 As every technology is introduced that technology must be (1) observable by and (2) controllable by the payload client.
- T.15 Each variant of the vehicle must be clearly impressive to any student, parent, engineer, mentor, or individual familiar with the US FIRST robotics competition.
Voice of the Engineer
- V.1 The platforms must be demonstrated functional in the two different configurations shown above.
- V.2 The motor module must be designed in such a way as to be able to operate 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 the rectangular platform.
| Model | Size (m) | Tare Weight (kg) | Payload Capacity (kg) | Speed (m/s) | Turning Radius (m) | Remote Range (m) |
|---|---|---|---|---|---|---|
| R1 | 0.15 x 0.15 x 0.15 | 1 | 1 | 0.90 | 0.15 | 10 |
| R10 | 0.30 x 0.15 x 0.30 | 9 | 10 | 2.25 | 0.30 | 30 |
| R100 | 0.60 x 0.75 x 0.50 | 40 | 100 | 4.5 | 1.00 | 60 |
| R1000 | N/A | N/A | N/A | N/A | N/A | N/A |
- 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 platforms 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 platforms must be easy for a third party to understand, use, and modify.






















