P07200: Robotic Vehicle Platform Family of Projects
/public/

Home

Table of Contents

Vehicle Systems Technology Track

Project Family: Robotic Platform

Support for this family of projects is generously provided by the Gleason Foundation.

Support for this family of projects is generously provided by the Gleason Foundation.

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.

This is a graphical image of the roadmap.

This is a graphical image of the roadmap.

Robotic Platform Roadmap, Academic Years 2006-07 and 2007-08
Academic Year Platform Integration Motor Modules DC Motor Control Wireless Communications Sensors and Feedback Software Systems
Baseline Concept Proposed in Spring 2006

Each robotic platform will have one or more powered motor modules, one or more idler modules, and a single system controller.

Rectangular Configuration for a User's Platform

Rectangular Configuration for a User's Platform

Components assembled into each platform.

Components assembled into each platform.

Triangular Configuration for a User's Platform

Triangular Configuration for a User's Platform

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.

Semi-Truck Style Configuration for a User's Platform

Semi-Truck Style Configuration for a User's Platform

Snake-like Configuration for a User's Platform

Snake-like Configuration for a User's Platform

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.

The motor module design should be scalable and modular.

The motor module design should be scalable and modular.

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.

Platform controller.

Platform controller.

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
First Generation RP10 Electronic Motor Controls and Sensor Interface used for RP10 Motor Module.

First Generation RP10 Electronic Motor Controls and Sensor Interface used for RP10 Motor Module.

P07204 - RP10 Platform

First Generation RP100A triangular platform.

First Generation RP100A triangular platform.

First Generation RP100B rectangular platform.

First Generation RP100B rectangular platform.

P07205 - RP100 Platform

Photograph of the First Generation RP10 Motor Module.

Photograph of the First Generation RP10 Motor Module.

P07201 - RP10 Motor Module

CAD Model of the First Generation RP100 Motor Module.

CAD Model of the First Generation RP100 Motor Module.

RP100 Motor Module in Benchtop Testing.

RP100 Motor Module in Benchtop Testing.

P07202 - RP100 Motor Module

First Generation RP10 Electronic Motor Controls and Sensor Interface used for RP10 Motor Module.

First Generation RP10 Electronic Motor Controls and Sensor Interface used for RP10 Motor Module.

P07204 - RP10 Platform

Digital Encoders used on the drive and steering motors.

Digital Encoders used on the drive and steering motors.

P07202 - Digital Encoders

First Generation RP10 Software Systems.

First Generation RP10 Software Systems.

P07204 - RP10 Platform

AY2007-08
Second Generation RP10 Robotic Platform, showing two motor modules, two idlers, integrated electronics system, battery storage, and flexible payload platform

Second Generation RP10 Robotic Platform, showing two motor modules, two idlers, integrated electronics system, battery storage, and flexible payload platform

P08201 - RP10 Platform 2

CAD model of First Generation RP1 Motor Module Drivetrain.

CAD model of First Generation RP1 Motor Module Drivetrain.

P08208 - RP1 Motor Module Drivetrain

Second Generation RP10 Electronics Control Board, showing student designed and fabricated power distribution, H-bridge motor control, PWM Logic board, and battery monitor boards.

Second Generation RP10 Electronics Control Board, showing student designed and fabricated power distribution, H-bridge motor control, PWM Logic board, and battery monitor boards.

P08201 - RP10 Platform 2

First Generation RP1 Motor Module Wireless Communications.

First Generation RP1 Motor Module Wireless Communications.

P08205 - RP1 Motor Module Wireless

This family of projects currently consists of the sub-projects as listed in the table below.

P07200 Family of Projects
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.

  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'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.
  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.
  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 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.
  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 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.
  5. 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

Table 1: Tradeoff Assessment
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