Senior Design Project Data Sheet

Project Description

Project Background: • 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 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.

Problem Statement: This student team will develop two modular, fully functional robotic platforms capable of carrying a 10 kg payload anywhere in the Robotics Lab, room #9-2230 in Building #09 on the RIT campus. The drive platforms should utilize the RP10 Motor Module, the scalable open architecture motor controllers and the DAQ systems where appropriate. (Refer to PRP for platform configurations). Each platform will be required to accomplish two tests; one requiring the robot to have remote controlled movement and the second requires the robot to move autonomously though coordinate input and PC interfacing.

Objectives/Scope: 1. Robotic platform must be scalable between

the P07204 and P07205 projects (Also shown to be scalable as low as 1 kg and as high as 1000kg).

2. The Platform must be user friendly and robust.

3. The appearance of the platform must be impressive to high school and undergraduate students.

4. The motor modules must be easily interchangeable.

5. The platform must be easily maneuverable and stable

Deliverables: • Several different initial designs for each

configuration (Triangular and Rectangular) by end of Jan 06.

• Complete Platform designs by end of SD1 • Complete working robots by end of SD2

Expected Project Benefits: • Our project will be used as a starting point

for future senior design teams, students and faculty.

• The robot will also contribute to RIT’s reputation at future US FIRST competitions.

• Will provide an initial basic robot kit for future research projects.

• Will attract potential RIT students to the KGCOE.

Core Team Members: • Nathan Boyer Brandon Howell • Brad Whitlock Anastasia Lorenz • Chris Chavoutie Daniel Wong • Joe Krisher Geoff Heitzenrater

Strategy & Approach

Assumptions & Constraints: 1. Our team will assume that the other related

senior design teams will complete and provide working components by the dates expected.

2. Tare weight, payload weight, turning radius and testing constraints will all impact the project.

Issues & Risks: • There is a risk associated with the

P07201 team finishing their project in parallel with spring quarter. Delivery of a working prototype at a reasonable date is crucial.

• Poor Communication between all of the related teams is an issue that can cause scalability and interchangeability issues.

• The budget of $600 is a concern; especially if components must be purchased shall a related senior design not accomplish their goal.

• The large motor module size and weight is an issue that will effect our tare weight and dimensions of the robotic platform.

Project # Project Name Project Track Project Family

P07204 10 kg Robotic Platform Vehicle Systems P07200 Robotic Platform Start Term Team Guide Project Sponsor Doc. Revision

2006-2 Dr. Walter ME Department B

Senior Design Project Roles Responsibilities Matrix

Name Project Area of Responsibility Functional Area of Responsibility Hardware Area of Responsibility Role e-mail Phone Number

Nathan Boyer Project Manager

Responsible for guiding his or her team members to achieve the goals set forth in the mission statement. Will 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 student will also give mechanical support where needed.

System Integration/Motor and payload mount support Lead Ndb9535 (716) 574 0851

Brad Whitlock Chief Electrical Engineer

Responsible for overall Electrical integration. Should have excellent electrical background to ensure the electrical systems of the robot are established. All software that will be needed for this project will lead the development of the software Electrical integration Lead Bdw1960 (585) 576 8816

Chris Chavoutie Systems Integration Coordinator

This student is responsible for checking design decisions against the future plan of the Robotics Platform Track as a whole. Responsible for ensuring that the 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. Electrical support as appropriate is also expected. Inter-Team communication

Lead/ Support Crc4761 (585) 797-8015

Joe Krisher 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. Mechanical systems integration Support Jjk7687 (315) 378-8698

Geoff Heitzenrater Chief Mechanical Engineer

Responsible for leading overall technical design. Should be proficient in Pro-Engineer or Solid Works. Maintains the 3-D modeling of the design. Motor Module Lead Gsh4150 (716) 622-7172

Daniel Wong Communications Engineer

This student is responsible for all design analysis, simulation, prototyping and benchtesting that is 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. PC104 and motor conrollers Support Daw8121 (347) 804-6057

Anastasia Lorenz 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.

Payload, Battery, Sensor Mounts and enclosure (Distinct and attractive appearance) Support Aml8774 (716) 997-6608

Brandon Howell Power Electronics Engineer

This student is responsible for all electrical design analysis, simulation, prototyping and benchtesting that is associated with powering the motor modules and all parts of the robotic platform. Power System Lead Bmh9641 (585) 451-0555

1

Robotic Platform 10 Kg (RP10)

P07204 - Concept Development Review (Pre-read)

Team Member Discipline Role Email Address

Wayne Walter ME Guide wwweme@rit.edu

Jeff Webb ME Consultant jbw3914@rit.edu

George Slack EE Consultant gbseee@rit.edu

Brandon Howell EE Member bmh9641@rit.edu

Chris Chavoutie EE Member crc4761@rit.edu

Brad Whitlock EE Member bdw1960@rit.edu

Daniel Wong EE Member daw8121@rit.edu

Nathan Boyer ME Project Manager ndb9535@rit.edu

Geoff Heitzenrater ME Member gsh4150@rit.edu

Anastasia Lorenz ME Member aml8774@rit.edu

Joe Krisher ME Member jjk7687@rit.edu

2

Table of Contents Section Page Introduction 3

Customer Needs 4

Specifications 6 Mechanical

• Triangular Chassis 8 • Rectangular Chassis 12 • Payload Mount 16 • Safety/Robust Concepts 19

Electrical

• Communication 22 • OC Protection 29 • Ambient Light Sensor 34 • User Interface (Microcontroller vs. Direct SBC) 36 • Coordinate Storage 39 • Remote kill switch concept comparison 42 • Software 46 • Back plane power connection concepts 49

3

Introduction This vehicular platform is part of the Vehicle Systems Technology Track of projects with the goal of developing 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 figure below shows a high level of the inputs and outputs that will be involved with the project, including the outcome of some of the current senior design projects.

Figure A

The particular mission of this student team is to develop a fully functional, scalable vehicular platform for use with the 10Kg motor module team, motor control team, and the DAQ team. The team is to develop a rectangular platform to hold a payload of 10Kg, and a triangular platform to hold a payload of 2.5Kg. The figure below shows a detailed sub function flow diagram of how the team will approach the project.

Figure B:

4

Customer Needs The establishment and clarification of customer needs is a crucial part of the concept development process. These needs were outlined in the P07204 - Project Readiness Package. The needs were developed further by the team after meeting with the customer, assigning a hierarchical ranking to each specific need. The customer needs were then translated from the voice of the customer to an engineering voice stating what the team will attempt to achieve in order to satisfy each of customer needs. List of Customer Needs N1.0) Safety Requirements: N1.1) must capable of being shutoff at anytime by the operator and/or bystander. N1.2) must comply with federal, state, and local laws and regulations and RIT policies and procedures. N1.3) platform will shutdown automatically incase of electronics fault. N1.4) platform design must consider the protection of users and bystanders. N1.5) platform design must consider the protection of its surrounding environment. N1.6) must comply with all OSHA regulations. N2.0) Customer Constraints: N2.1) must be capable of being lifted and transported by a single person. N2.2) rectangular configuration must carry a 10kg payload, and triangular configuration must carry a 2.5kg payload. N2.3) must be able to navigate tight turns. N2.4) must be able to fit through a standard sized doorway. N3.0) Cost: N3.1) the designing, testing and prototyping of both robotic platforms must be completed within a $600 budget. N4.0) Compatibility: N4.1) must be capable of integrating both the driven and idler motor modules developed by senior design group P07201. N4.2) must be capable of being mounted on the dynamometry lab infrastructure developed by the senior design group P07203 N4.3) must be capable of integrating the motor controller developed by senior design group P07302. N4.4) must provide appropriate connections for the DAQ developed by senior design group P07301. N4.5) must be adaptable for future senior design projects.

5

N5.0) Electrical Systems: N5.1) must have method of communication between motor module, platform and sensors (if applicable). N5.2) must be capable of interfacing to a PC for coordinate input. N5.3) must use tethered/wireless remote or PC controlled to navigate a range of 30 meters. N5.4) all electronics must be able to be installed and reinstalled quickly. N5.5) the robotic platform must be powered by and easily removable battery, with a runtime of one hour. N6.0) Platform Flexibility: N6.1) the platform must use off the shelf components. N6.2) the platform must be scalable from 10kg to 100kg, with future expectations of having the scalability range from 1kg to 1000kg. N6.3) the platform must allow for quick and easy interchangeability of motor modules from one platform configuration to the next. N6.4) must be useable within the KGCOE. N6.5) the platform appearance must be clean and impressive. N6.6) the robotic platform must use exciting technology to attract perspective students to the KGCOE. N6.7) the robotic platform must be clearly impressive to any student, parent, engineer, mentor, or individual familiar with the US FIRST robotics competition. N7.0) Robustness: N7.1) design of platform is robust enough for the inexperienced user. N7.2) the robot must have the technology and durability to be used for 5+ years. N8.0) Testing Requirements: N8.1) must be capable of navigating through the robotics lab (room #9-2230). N8.2) motor modules must be capable of being changed quickly. N8.3) capable of receiving coordinate input from a PC. N8.4) must have short coordinate acquisition time. N8.5) must be capable of navigating. N9.0) Testing Requirements: N9.1) all drawing must comply with engineering standards. N9.2) all documentation must be open source. N9.3) all dimensions must be in SI units. N10.0) Testing Requirements: N10.1) must have a low center of gravity N10.2) must be able to corner well N10.3) must have adequate velocity and acceleration N10.4) fits through standard doorway

6

Specifications After establishing defined customer needs, it is necessary to translate the needs into statements and values that the design team agrees to establish a design that will satisfy all of the needs the customer has expressed. The specifications developed for the 10 kg robotic platform are expressed below in figure C. The goal of the team is to satisfy the majority of these specifications, understanding that some tradeoff might be necessary due to constraints such as money, space and time.

Figure C:

7

Mechanical

The mechanical concept development was divided up into four main sub functions; triangular chassis, rectangular chassis, payload mount and safety/robust features. Each sub function was developed individually, and then evaluated using a Pugh analysis to determine the best concept for each. The best concepts of each sub function will then be revised to incorporate the design of related sub functions. For example, once the a chassis design and a payload mount design is established both designs will be revised to integrate the two into a single concept that can be manufactured and assembly for bench testing. Mechanical information is as follows: 1.) Triangular Chassis 2.) Rectangular Chassis 3.) Payload Mount 4.) Safety/Robust Features

8

1) Triangular Chassis Configuration: Overview The requirements for the three-wheeled platform are similar to the four-wheeled platform except that the three-wheeled platform will have only one drive wheel along with two idler wheels. Also, the payload requirements are decreased from at least 10kg to at least 2.5kg. Therefore, the chassis design for this configuration will be smaller in overall size compared to the rectangular configuration, and the wheels will be arranged in a triangular configuration to provide stability. There are three different design concepts proposed for this wheel configuration. All three concepts are similar in shape and all three are able to meet or exceed the payload requirement. Concept 1 - Billet Chassis The first is the Billet Chassis. Made from a billet of material, it will be machined to shape and contoured to minimize weight while retaining structural integrity. The payload mounting surface will be machined into the center of the piece, and mounts for the electronics will be drilled on the underside.

Figure M1.0

PROS • The major advantage of this method is the overall appearance of the robot when

finished. It would be clean and polished with no unsightly seams or joints. CONS

•••• A billet of material large enough to meet the required dimensions of the robot would be extremely expensive relative to the other options. A single piece would require over $150. This would leave absolutely no room for error in the manufacturing process.

•••• The weight of this chassis would be larger than the other two as well, unless extra machining steps were taken to make it lighter.

•••• The manufacturing process for this concept would be very complicated. The part would have to be programmed into a CNC machine or a skilled machinist would have to do the milling. An unskilled machinist would be unsuitable for this process simply because of the cost of a mistake. This machining process would also waste a lot of material. Therefore the machining process is not optimal for the user base.

9

•••• With the entire chassis made of one solid piece, a user would not be able to modify the robot’s footprint at all without making a new print, possibly a new CNC program, and machining the whole part over again at great cost.

Concept 2 - Bolted Chassis The second concept is the Bolted Chassis. (Fig. B) With this design, the chassis will be constructed of smaller bar-stock pieces and bolted together. The payload mounting surface will be bolted on top of this chassis and the electronics will mount underneath.

Figure M1.1

PROS

• The bolted chassis could be made of bars of material, which would greatly reduce the cost of the raw materials.

• The weight would be easy to control because the structure of the chassis would be only enough material to carry the payload surface, compared to the Billet Chassis concept which would require extra machining steps to remove the weight.

• Because the Bolted Chassis is made from smaller bars of material, it wouldn’t require complicated machining processes to make. Since high-precision is not necessary, it could more easily be completed by the target user group.

• This design is extremely adaptable because of the low cost to manufacture parts of the chassis. A user could unbolt some parts and attach new ones to change the footprint of the robot.

CONS

• The appearance of the Bolted Chassis will require special attention to make sure that the chassis looks clean and aesthetically pleasing. Extra machining processes may be necessary to provide the desired look.

Concept 3 - Welded Chassis The final concept is the Welded Frame Chassis. (Fig. C) This chassis is made of tubing that is welded together. This is similar to the Bolted Chassis in construction with welds instead of bolts. The payload mounting surface and electronics will still bolt on to maintain flexibility.

10

Figure M1.2

PROS • The welded chassis could be made of multipurpose steel tubing, which would be

much cheaper than the Billet Chassis and comparable to the Bolted Chassis. • The weight would be easy to control because the structure of the chassis would be

only enough material to carry the payload surface, compared to the Billet Chassis concept which would require extra machining steps to remove the weight.

• This concept has the potential to be more attractive than the Bolted Chassis depending on how well the welding is done. It will require post machining to make it look as attractive as possible.

• This is a more adaptable concept than the Billet Chassis because a user could easily make a new robot to different dimensions. However, it would be difficult to modify an existing robot because of the fixed weld points. A user would have to cut the welds and then re-weld the modified parts.

CONS

• This concept requires the basic machining skills that the Bolted Chassis requires, but because it requires welding this concept is not as accessible to the target user group. It will also require the user to build a welding jig.

Selection Stage

Figure M1.3

11

Breakdown of selection criteria Cost of Materials – The robot should be constructed of inexpensive materials to minimize the cost to reproduce. Weight – The robot should be made of materials to ensure that it is lightweight enough to function on its one drive wheel, as well as be transported by one person. Appearance – The robot should be aesthetically appealing to any observer regardless of their technical knowledge or experience. Ease of Manufacture- The robot should be able to be reproduced in quantities as few as one and as many as ten. This requires machining processes that are not excessively complicated or time consuming. Adaptability – This criterion describes the ability of a user to adjust the dimensions of the robot to better suit the user’s project requirements.

Conclusion The ideal design concept is the Bolted Chassis. It is very cost effective, lightweight, and requires the least effort to manufacture or adapt. Further design effort should be focused on making it as attractive as possible.

12

2) Rectangular Chassis Configuration: Overview The requirements for the four-wheeled platform are similar to the three-wheeled platform except that the four-wheeled platform will have two drive wheels along with two idler wheels. The payload requirements are 10kg, whereas there is only 2.5kg for the triangular platform. Therefore, the chassis design for this configuration will be larger and more reinforced compared to the triangular configuration. There are three different design concepts proposed for this wheel configuration. All three concepts are relatively similar in shape and overall size. All three are able to meet or exceed the payload requirement. The selection criteria to be used to select the ideal concept design directly address the key project requirements:

Concept 1 - Open-Deck Chassis with Covered Electronics Bay The Billet Chassis will be machined to shape and contoured to minimize weight while retaining structural integrity. The payload mounting surface will be integrated or attached to the top of the open architecture platform. The mounts for the electronics and the battery will be stacked atop each other and placed under a protective shelf in the rear of the chassis.

PROS

• A very simple design with minimal machining • Cost effective • Very open architecture for mounting payload • Provides protection for electronics and battery • Parts are easily interchangeable

CONS • May require welding, bolting, or riveting of the shelf • No real ‘cool’ factor in the design

Concept 2 - Open-Deck Chassis with Hinged/Sunken Electronics Bay The second concept is the reinforced billet chassis with a center bay in the middle of the rig which houses the electronics and the battery. This leaves room for an almost un-obstructed open deck for payloads and payload constraints. The Electronics are protected and lower the center of gravity of the entire chassis.

13

Figure M2.2

PROS:

• A very simple design with minimal machining • Low center of gravity for the chassis • Cost effective machinability • Very open architecture for mounting payload • Provides protection for electronics and battery • Parts are easily interchangeable

• Provides a cooler look than Design #1 • Can easily be designed in conjunction with the triangular platform

CONS: • May require welding, bolting, or riveting of the belly • May need reinforcements for supporting a heavy payload

Concept 3 - Truck Theme Chassis The final concept is the Pickup truck theme chassis. This chassis is can be constructed out of billet material and/or built upon a sub-frame in order to mimic the looks and functionality of a truck. The frame would be welded together and the billet machined in order reach the simplified final design. This design has a great “cool” factor and is scalable. The electronics, battery, and the motor mounts could all be in the cab of the truck. The payload would sit and be secured inside the bed of the truck.

14

Figure M2.3

Pros:

• Very open architecture for mounting payload • Provides protection for electronics and battery • Provides a really cool themed look

• Can easily be designed in conjunction with the triangular platform • Does not need reinforcements for supporting a heavy payload

Cons: • Not cost effective • Intricate design with many parts

• May require welding, bolting, or riveting of the belly • Complicated parts to assemble • Parts may not be easily interchangeable

• Not easily to designed in conjunction with the triangular platform

Breakdown of selection criteria Cost of Materials – The robot should be constructed of inexpensive materials to minimize the cost to reproduce. Weight – The robot should be made of materials to ensure that it is lightweight enough to function on its two drive wheels, as well as be transported by one person. Appearance – The robot should be aesthetically appealing to any observer regardless of their technical knowledge or experience.

15

Ease of Manufacture- The robot should be able to be reproduced in quantities as few as one and as many as ten. This requires machining processes that are not excessively complicated or time consuming. Adaptability – this criterion describes the ability of a user to adjust the dimensions of the robot to better suit the user’s project requirements.

Selection Stage

Figure M2.3:

Material Selection The material used for constructing the chassis should possess characteristics that suit the budget and performance needs of the robotics platform. These characteristics are:

1. Cost– The material should be as inexpensive as possible

2. Weight – The material should be as lightweight as possible

3. Appearance – The material should be as attractive as possible, requiring a minimum of extra machining processes. This material should also be corrosion resistant.

4. Machinability – The material should be as easy to machine as possible.

5. Strength – The material should be able to meet or exceed the structural requirements of the project.

16

There are three materials under consideration for the chassis of this vehicle. The first is 1018 Multipurpose Steel. It possesses the highest strength of the three materials. However, it also weighs more, costs more and is not as machinable. Steel can be made attractive; however it is prone to rusting. This makes steel an unfavorable choice. Aluminum is the second option for the chassis. Aluminum is nearly as strong as steel, slightly cheaper, lower weight, and more machinable. It also is corrosion resistant and can be polished or anodized to improve the appearance. Aluminum would be a good choice for this application. Delrin is a third option. Delrin is the most expensive of the three, the lightest weight, and the most machinable. It also comes in a variety of colors and would be attractive. However the strength of Delrin is significantly lower than either of the other two materials and may not be a good choice for the chassis of the vehicle. Delrin should be considered for other applications on the robot. Selection Stage

Figure M2.4:

17

3) Payload Mount: Concept 1 - Fixed Position Adjustable Grippers The fixed position adjustable clamps design entails a pegboard-like matrix of holes that the grippers will slide into. The grippers will be secured by either screwing into tapped holes in the board or by having a nut screw onto the bottom of tapped threads that will pass through the holes. This design is more of a digital design, as objects that do not quite fit between two pre-drilled holes will not be held as securely. This can be rectified by using a gripping material covering the surface of the mounting plate.

Figure M3.0:

Concept 2 - Sliding Adjustable Grippers The sliding adjustable grippers slide on t-slots that are positioned radially every forty-five degrees. This optimized gripping payloads of multiple sizes. A set screw in the back of the grippers will hold them in place. This design is more analog, which allowing for a greater variation between payload sizes. This design can also be improved by using a non-slip surface for the top of the mounting plate.

Figure M3.1:

18

Selection Criteria Adjustability - The payload can be anything weighing up to ten kilograms. The adjustability of the payload mounting is key to the adaptability of the robotic platform for future projects. Cost - The cost of the robotic platform should be minimal to allow future research projects at RIT to easily recreate the platform for their own use. The payload mount is an important part of the platform, but should be as low cost as possible. Manufacturing Time - In order for the platform to be accessible for future RIT initiatives, the time for manufacture should be as minimal as possible so as to not detract from the main project that the group will be working on. Ease of Use - The payload must be easily mounted to the platform for the robotic platform to meet its goal of being useful to future RIT projects. If the user cannot mount their required payload to the robotic platform, they cannot use the robotic platform. Aesthetics - A large part of this project is the aesthetics of the robot. The purpose of this robot is to not only be useful to future RIT research teams, but to also impress possible RIT students and anyone involved in the FIRST Robotics Competition. The look of the payload mount should not detract from the sleekness of the robotic platform, and if possible, it should add to the aesthetically pleasing design. Security of Payload - The robotic platform may be required to hold a sensitive payload while in operation. Therefore, the security of the payload must be considered. If the payload can shift about during operation, tests and research that are being conducted with the robotic platform will be compromised, which is not the desired result. Concept Screening

Figure M3.2

19

Concept Scoring Matrix

Figure M3.3

Based on the concept scoring matrix, the sliding adjustable clamps will be developed further. They offer the most adjustability, the highest aesthetic value, and keep the payload more secure than the fixed position adjustable clamps. Concept Considerations The shape of the slot for the sliding grippers concept is currently shown as a t-slot, however, this shape will be analyzed along with a few others to determine the best shape for the slot. Currently, a t-slot, dovetail, and circular slot will be considered and stress calculations will be performed to understand which shape slot will be the best for the payload mount. Concept Development: Material Reduction The slotted plate design seems to be the best suited for future development. However, it will cost a lot for a plate of material so large. The next step in the design of the payload mount is material reduction.

20

4) Safety/Robust Features: Overview The primary concern when generating concepts is the safety of the people around the robot, the preservation of the environment the robot is in and the protection of the robot itself. Certain mechanical safety features must be considered to ensure a fail-safe design. Preventative characteristics such as bumpers would also be considered throughout the concept development phase.

Safety Concepts

1) On-Board Kill Switch (Bumper switch)

Figure M4.0

Reference: http://www.vexlabs.com/vex-robotics-bumper-switch-kit.shtml PROS

• Large, “Hard to miss” button (that can be hit quickly) that can be connected to the OC protection discussed in the electrical section of this.

• Design can also be used as a bumper kill switch, stopping the robot when the bumper is depressed.

CONS

• Size of the button itself may hinder the appearance of the robot

2) On Remote Kill Switch This concept is discussed in detail in the electrical decomposition (Section 6).

Robust Concepts

1) Bumpers Type A Type B

Figure 4.1

21

The type of bumper and the material chosen will depend on the chassis design and expected contact points. Bumper material considerations for the 10kg robotic platform will predominately depend on the cost of the material. However, the 100kg platform will have to take careful consideration for the inertial impact of the larger mass. Reference: http://www.bruceplastics.com/pages/feet-bumpers.html

2) Protective Casing (electrical components/battery) Material 1 – Clear Lexan Polycarbonate Sheeting PROS

• Fairly inexpensive • Easy to manufacture • Prospective students can see the electrical components inside clearly

CONS

• A fan will be required to circulate the air inside the electrical component envelope Material 2 – Sheet Metal PROS

• Fairly inexpensive • Easy to manufacture

CONS

• Cannot see inside at all • Overall appeal of the package would not be impressive

Material 3– Wire Meshing PROS

• Fairly inexpensive • Prospective students can see the electrical components inside (somewhat) • Would not require a circulatory fan

CONS

• Harder to manufacture, it would require some welding • Overall appeal of the package would be less impressive

Conclusion Clear lexan would be the most attractive envelope for the curious student that would like to understand the electrical architecture of the robot.

21

ELECTRICAL The subsystem decomposition of our design concepts will be presented as follows in the subsequent pages of this documentation:

1) Communication 2) OC Protection 3) Ambient Light Sensor 4) User Interface (Microcontroller vs. Direct SBC) 5) Coordinate Storage 6) Remote kill switch 7) Software 8) Back Plane Power Connection

22

1) Communication Concept Comparison Overview

There are several ways in which the user can control the robot. After narrowing down the concepts from the screening stage, we’ve decided that the feasible options are controlling the robot with a tethered remote control, wireless remote control, wireless laptop control via a transceiver, or tethered laptop control via a serial cable.

There are several ways in which the user can control the robot. After narrowing

down the concepts from the screening stage, we’ve decided that the feasible options are controlling the robot with a tethered remote control, wireless remote control, wireless laptop control via a transceiver, or tethered laptop control via a serial cable (Shown below in Figure).

Figure E1.0

Screening Stage From this table, we decided to combine concepts D and E due to the face that both concepts will require a tethered PC. Voice control can be eliminated due to cost, difficulty, and overall feasibility. The concepts which will be considered are controlling the robot with a tethered remote, wireless remote, transceiver, and a tethered laptop.

23

Figure E1.1

Selection Stage

From the table it is easy to see that using a PC to control the robot is the best option followed by controlling the robot with a tethered remote. Going wireless would add more complication and cost overall. We decided to weight the cost and difficulty of integration more than the other criteria’s due to our limited budget and time.

Figure E1.2

Breakdown of selection criteria Range - This consists of limitations of range in which the robot can be controlled. Obviously, going with the wireless options will allow for more range. Controlling the robot with a tether will require the user to walk around with the robot. Cost - This consists of total cost of each option. Assuming a laptop is available; controlling the robot with a tethered laptop is the cheapest option. Off the shelf remote

24

controls, wired or wireless, are relatively similar in price. Having to buy a transceiver would be the most costly option. Difficulty of Integration - This consists of time required to design and debug each option. All options require some programming to translate signals from the user to the motor controller but the wireless options will definitely be harder to integrate due to interference. The tethered PC control would be the easiest option due to the fact it contains the least amount of variables needed to be designed and debugged. Safety - This includes how safe each option is. Clearly, the wireless options are safer. Walking around with a tether is slightly more dangerous due to the fact that someone could potentially trip over the tether. Scalability - This refers to how scalable each option is. This isn’t a real concern for out team but when it comes to controlling a robot which can carry 100kg or 100kg, the wireless options would be more feasible. Ease of Use - This refers to how easy the user will be able to control the robot. All 4 options should ideally be easy to use. The only difference between using wired/wireless remote and using a PC (transceiver or tethered) would be the limited functionality of the remotes. Using a laptop to control the robot would allow for more functions to be programmed. Durability - This refers to how durable each option would be physically and electronically. Physically a remote (wired or wireless) would be more durable than a PC. Electronically, the wireless options are subject to more interference than a tethered control. Cool Factor - This refers to how impressive the overall system will be to the user. Clearly, wireless control would have a higher cool factor than a tethered robot. Accuracy - This refers to how accurate the user can control the robot. Controlling the robot via a wireless connection is subject to more interference which would lead to less accuracy. Portability - This refers to how portable each option is. Using the remotes would clearly be more portable than carrying around a laptop. Ease of Manufacture - This includes all prototyping and construction of a final system. This also includes the programmable ease and overall design difficulty. Programmable ease refers to the ease with which someone can implement the needed functionality with respect to the programming needs.

25

Possible Options and Pricings Transceiver Option:

Parallax 433 MHz RF Transceiver Package Price: $109.95

. Figure E1.3

DESCRIPTION: The Parallax RF modules provide a very easy and low-cost method of sending data between microcontrollers from 500 ft+ line-of-sight. This transceiver package comes with two receivers and two transmitters, everything you need for bi-directional communication! This device can be connected to a PC serial port using a MAX232 line driver. The circuit isn't supported by Parallax, but it's possible to make this connection with a few dollars of parts. SPECIFICATIONS:

PCB Size: 0.9"x1.9" (without antenna)

Overall Size: 0.9"x3.6" (with antenna)

Power: 5V +/-10%

Current: ~10 mA normal operation ~3 mA during power down.

Data Rate: 12,000 - 19.2 K baud (controller dependent)

Frequency: 433.92 Mhz (UHF)

Transmission 500 ft+, based on environment conditions.

Weight .4 lb

Figure E1.4

26

REFERENCE: http://www.parallax.com/detail.asp?product_id=28180 Possible Remotes:

•••• 4-TH 4-Channel FM Radio Price: $89.99

Figure E1.5

SPECIFICATIONS:

Transmitter: 4-channel Operating Frequency: 72MHz Modulation Type: FM narrow band Output Power: less than 0.75W Receiver: 7-channel Current Drain: 180mA Features 4-channel narrow-band transmitter 7-channel, dual conversion, narrow-band 72MHz FM receiver 9.6V 600mAh transmitter NiCd 4.8V 600mAh receiver NiCd 110V AC NiCd wall charger

REFERENCE: http://www.towerhobbies.com/products/towj41.html

•••• FUTABA 2 ER 2 Channel System Price: $44.99

Figure E1.6

27

Ideal for eager new car, boat and plane fans, and the 2ER’s stylish case features front-mounted fine trims for easier access and shorter sticks that allow modelers with smaller hands a full range of motion. Servo reversing, fine trims also included. In addition, the 2ER is available with two S3003 precision standard servos for all-around car, boat and aircraft use. The 2ER requires 12 “AA” cells (8 w/BEC use). Available on 27,72 & 75MHz. 1-year warranty.

2ER SYSTEM SPECIFICS:

Bioengineered transmitter includes contoured sides and a flattened strip on the backplate to increase grip strength

• Sticks are just 3/4” high, allowing small-handed modelers a full range of movement

• All controls and lights are placed within a 5” wide by 2” high area for easy viewing

• Battery Door on front panel speeds battery change

REFERENCE: http://www.towerhobbies.com/products/futaba/futj46.html Pro’s and Cons

Figure E1.7

28

Conclusion We’ve narrowed the choices down to either using a tethered remote or a laptop with a tether. This is partially due to the fact that there will be a wireless design team in the future. We will try our best to make it as easy as possible to be able to transition to wireless in the future if desired. We’ve also decided to go with the tethered route because it would be easier to design and implement overall and it would be cheaper than its wireless counterparts. Ideally we would like to get a tethered remote onto the robot but regardless of that fact, we will have the tethered PC to control the robot.

29

2) OC Protection Method: Overview Safe operation of the robotic platform, as outlined in the project readiness packet, is of paramount concern to the customer. From an electrical standpoint, a system is considered safe at the topmost level when it has a built-in method to deal with electrical faults. In this case, an electrical fault can be described as an electrical failure which causes a sudden and dangerous amount of current draw. This condition is known as an over current (OC) fault, and if left unchecked can cause extreme heating leading to fire and possible electric shock. Several methods are available to monitor the current draw from the main batteries, and in the case of an OC fault, shut the system down. These methods are presented in Pugh Chart form in Table 1.1.

Screening Stage

Figure E2.0

Following Pugh Chart guidelines, a reference design was chosen to which all other designs were rated. A basic Fuse was chosen as the reference design because they are readily available, simple to implement, and meet the minimum requirements for safety. Selection Stage Using the results from the initial screening process, the Fuse protection method was eliminated. It was decided that the Circuit Breaker, Hot Plug Controller, and Micro Controller methods all offered at least the same amount of protection as the Fuse, but had additional features which made them more attractive. Using these results, another Pugh Chart was created, as shown in Table 1.2.

30

Figure E2.1

In the second Pugh Chart, each selection criteria was given a weight and each method a weighted score. From table 1.2, it was decided that the Circuit Breaker and Hot Plug Controller method were concepts worth developing into prototype form. Break Down of Selection Criteria Ease of Use - This consists of how easy it is for the end user to identify and deal with an OC Fault condition. Labor/Material Cost - These subcategories deal with the cost of developing each method in terms of raw material cost and engineering time. Ease of Manufacture - This subcategory deals with how difficult the finished product will be to build. Material cost, construction time, and construction complexity are all considered. Scalable - This subcategory takes into account how scalable (both up and down) each design method is. To be considered scalable, a design method must be able to be scaled up or down with a minimal (preferably no) design changes. Safety - This subcategory deals with how the resulting design meets the over current protection requirement, as well as any other safety features the resulting design adds to the platform. Durability/ Accuracy - This subcategory deals with how durable/ accurate the resulting design will be. A design is considered accurate if it stops an OC fault at its defined current level. Durability can play a role in how accurate the resulting design is. Cool Factor - This subcategory deals with how much of a cool factor is added to the robot by implementing the chosen design.

31

Concept 1 - Circuit Breaker

Figure E2.2

PROS • Implementation cost – breaker can be bought pre-made. • Complexity – stand alone mechanical device with few moving parts. • Multi-use – breaker can be reset after fault. • Cost – low cost in terms of both material and labor.

CONS

• Not customizable – trip point is not customizable. • Not fully automated - breaker must be manually reset after a fault. • False trips – breaker may be tripped when motor(s) first start. • Accuracy

Concept 2 – Hot Plug Controller

Figure E2.3

PROS

• Fully customizable – trip point can be set through the use of a resistor. • Fully automated – no need to reset after a fault. • Multi use – controller will reset itself after fault. • PGood indicator – LED indicator can be setup to signal proper operation.

32

• Kill switch – Enable pin can be used as a kill switch. • High Reliability - controller has two levels of protection which limits false trips.

CONS

• Complexity – controller will require a PCB and proper layout. • Labor intensive – PCB board, bench testing, component selection.

Proposed Controllers

• Intersil Hot Plug Controller (ISL6115):

Figure E2.4

• Maxim Hot Plug Controller (MAX5924):

Figure E2.5

33

• Linear Technology Hot Plug Controller (LTC1422):

Figure E2.6

Estimated BOM based on Intersil circuit:

Figure E2.7

Conclusion Using the results of the Pugh Chart, the Pros/Cons, and the block diagram, it was determined that the Hot Plug Controller method would best meet the safety needs of the project readiness packet and therefore was chosen as the over current protection method.

34

3) Ambient Light Sensor

Overview One of the main design requirements in the project readiness packet was the need for the robotic platform to exhibit a “cool” factor. While the project readiness packet does not explicitly state what is meant by cool factor, from direct conversations with the customer, the platform must appeal to high school students while at the same time showcasing RIT’s engineering abilities. To help meet this goal, it was proposed that an ambient light senor be added to the platform. This sensor would then control LEDs placed on the platform, causing the robot to glow in low light levels. Table 1.1 examines the cost vs. benefits of implementing such a solution. Selection Stage

Figure E3.0

Concept 1 – Ambient Light Sensor

Figure E3.1

PROS • Cool factor – LEDs on platform will light automatically, depending on ambient

light conditions. CONS

• Added Complexity – will need small PCB layout. Current light sensor requires 5Vin (can be provided with simple LDO).

35

Proposed Light Sensor

Figure E3.2

Estimated BOM

Figure E3.3

:

Conclusion From the Pugh Chart and Pro/Cons comparison, it was decided that the addition of an ambient light sensor would be worth the cost and engineering time needed to implement it.

36

4) User Interface (Microcontroller vs. Direct SBC) Overview The reception of user input from the world into the system can be done in two ways as identified above. The principle difference is the method used to decode the user inputs and translate them into signals that can be interpreted and stored by the system. The system in this case can be though of as the single board computer provided by the motor control team. This piece of hardware has the highest level of performance in providing general computing functionality to the robot and so it is used as the central control system for the platform. All navigational and control algorithms will be handled to some extent by the single board computer. What follows is the determination of what level of integration the SBC will have in the interfacing to the external world (user).

Figure E4.0

Selection Stage

Figure E4.1

From the table, it is easy to add a microprocessor to the system to interpret external data would add complication to the data stream. Therefore, we have decided to integrate the needs into the SBC. This will eliminate most hardware prototyping for the interface and as a result, almost the entire interface scheme can be software defined which has the

37

added benefits of scalability and supportability. This comes with the cost of increased software development and may eventually limit the communications scheme. Break Down of Selection Criteria Hardware Connections - This consists of all electrical connections that would be needed in order to support this concept. This microcontroller not only needs supporting hardware such a RS-232 level translator and power conditioning but also needs a way to interface itself to the PC104 bus. If there were many more inputs from the world (not including sensors) it may be worth it to use a microcontroller to interface to the system but with only two inputs, simple hardware can be used in conjunction with software daemons running on the SBC (Linux kernel) to achieve the needed functionality. Development Needed - This includes all prototyping and construction of a final system. Again, the microcontroller solution requires vastly more resources here. The micro would add another level of difficulty in the software realm as well as the hardware requirements. It would be easy to get bogged down here with the microcontroller solution. Programmable Ease - This refers to the ease with which someone can implement the needed functionality with respect to the programming needs. The micro adds another entire development environment for the developer to become acquainted with as well as the need of learning the architecture of the microcontroller which can be daunting compared to developing in a Linux environment. Overall Design Difficulty - This is a sort of catch-all for all other design concerns. It includes things like hardware procurement, cost and system reliability. Again, since the micro solution requires more parts, it is the loser here. Ordering parts is more difficult than developing with hardware already on campus (the motor control team has a SBC). Also, since the micro solution has more parts, the system will be less reliable as well as more difficult to assemble. Expandability Ease - This refers to how easy it will be to integrate different user input schemes. The microcontroller has an advantage here since it could feasibly devote 100% to the task of receiving user input while the SBC will always have other things to do. Also, non digital communication methods will probably need hardware interfacing to the PC104 bus. Concept 1 - Microcontroller interface PROS

• Lowers workload of the SBC • May be easier to connect peripherals to the system with a translation scheme

rather than connecting directly to the PC104 bus CONS

• Increased design and testing workload

38

• Increased cost to implement (PCB + Parts) • Increased system complexity • Decreased system reliability • No increase to cool factor

Concept 2 – Only use SBC PROS

• Simpler to write software for only one platform • Less parts • Less cost • Less development time (hopefully)

CONS

• SBC will have to have another program to manage communications which will increase demands on the SBC processor and operating system resources

Estimated BOM

Figure E4.2

Conclusion We will be using the SBC to implement every function on the robot that it can conceivably do successfully. It is worth difficulty here to avoid the difficulties of including dedicated hardware. This also benefits the customer since they will never need to worry about changing software in a microcontroller and can focus on higher level research.

39

5) Coordinate Storage Overview Below are the requirements for coordinate input to the RP10A.

Test 2: This test will be conducted on a 10' x 10' tiled open floor (e.g. the floor in 09-2230).

1. The team will be given five x and y coordinates (in inches) by an instructor. 2. The values must be inputted into a program already written for device RP10A.

After it is received by device RP10A, all connections must be severed. This step must be completed in 120 seconds or less.

3. Device RP10A must autonomously navigate to each coordinate, in order, stopping for 10 seconds at each.

Figure E5.0

To meet these needs, the platform will need software to receive the data and store it until the completion of the test. Next, the Pugh chart showing the ratings of criteria needed to meet this requirement.

40

Selection Stage

Figure E5.1

Break Down of Selection Criteria Cost - The criteria rates to cost to implement the concept. RAM receives a rating of 3 since there is RAM onboard and therefore will not have a cost advantage/disadvantage. The flash option may have a slight cost over RAM depending on the specific implementation which is difficult to analyze at this point since the specific SBC is not known. Development Needed - This refers to the amount of development that will be needed to arrive at a successful implementation of the concept. The RAM solution will be very easy to implement since there is no added software complexity to implement. Everything that comes into the system will be in RAM at one point or another. The flash concept will require special I/O handling code to store the information on the specific flash implementation. Most likely this will be file I/O operations but again, since the SBC is unknown, it is tough to say with certainty. Programmable Ease - This ties in with development but focuses on maintainability or how easy it is for someone to modify later in time. The RAM received a rating of three since it will neither help nor hinder a developer in the future. Flash gets a two because the mechanisms for storing the data will already be in place and the developer may only need to modify a few lines of code to change storage media. Customer Ease of Use - This is an important consideration, however since this aspect of the platform should be transparent to the user, both receive a three. Robustness - This is the reliability of the storage method with flash having a distinct advantage over RAM since the RAM contents will be lost upon power loss. However, there is no requirement for the data retention and therefore this criterion receives little weight. Concept 1 - Flash PROS

• Coordinate storage will be safe in the event of power loss

41

• Software “hooks” will be in place should anther storage scheme be desired in the future; easy upgrade path

CONS

• Possibly increased cost if user wants to store data off SBC • Increased software development time required • Increased software complexity

Concept 2 - RAM PROS

• Simple, data will already be in ram when received from PC • Cheap • No extra development time required • Minimal code to write to support this concept

CONS

• Data lost if power fails

Cost of External Flash (tigerdirect.com) Implementation Capacity (MB) Cost

USB Flash 128 6.99 Secure Flash 128 7.99

Compact Flash 256 11.99 Figure E5.2

*It is assumed that the SBC has the ability to communicate with at least one of these technologies, but the specifics of the SBC are unknown at this time. Conclusion We have decided to continue with the RAM concept for the storage of coordinates unless we decide that we need the robustness of the flash storage. The actual implementation will probably be along the lines of the following: A simple guidance program will be started on the RP10A which will wait for the reception of coordinates from an upstream PC. Once received the RP10A will disconnect from the PC and wait until a signal is met for the robot to begin its test.

42

6) Remote kill Switch Concept Comparison Overview Safe operation of the robotic platform is of paramount concern. In the event that an operator or bystander needs to terminate the robot in a timely fashion, there must be a remote kill switch. Below is the concept selection for the kill switch. We examined four different configurations as well as combination of concepts before arriving with the best solution. The solution we have found to be the best fit is a kill switch tethered to a remote. The remote is the user interface to the robot. The kill switch will be connected via wires to the remote which is connected with wires to the robot. During the autonomous test, the remotes functionality will be disabled but the kill switch will still be functional. We considered keeping the kill switch on the remote but then bystanders will have poor access. We also considered wireless solutions but consider them less reliable and hence less effective. Concepts Explained On Remote - Kill switch is located on the remote control which is wired to the robot. Stand Alone T. - Kill switch is a box that is wired to the robot, not connected to the remote. Stand Alone W. - Kill switch is a box that triggers a system on the robot via a wireless link. Voice Activated - The robot will be equipped with a voice recognition system that is triggered by screams of imminent doom. T. Hybrid - Best solution, there are two remote kill switches. One on the remote and one tethered to the remote; perhaps the tethered switch is controlled by an OSHA representative. W. Hybrid - Stand alone wireless kill switch as well as a kill switch on the wireless remote.

43

Selection Stage

Figure E6.0

Break Down of Selection Criteria Development Time - This is the time it will take the design team to develop the concept including all testing and prototyping. Reliability - This is how much the concept can be counted on to carry out its task. This is an important criterion since safety is a paramount concern. Wow Factor - This criterion rates the ability of the concept to impress a bystander. Safety - This criterion rates how well the concept contributes to the overall safeness of the platform. Range - This criterion rates how far the concept would be able to effectively control the robot from. Effectiveness - This criterion rates how well the concept implements the safety requirement set out in the needs document. Selection Stage

Figure E6.1

44

Concept A - On Remote PROS

• Not much development needed • Cost effective • Very safe • Reliable

CONS

• Only operator can stop robot • Restricted range by the tether

Concept B - Stand Alone Tethered PROS

• Can be operated by bystander or dedicated personnel • Very Safe • Very Effective

CONS

• More development time than concept A • Higher cost than concept A

Concept C - Stand Alone Wireless PROS

• Wow factor because wireless is cooler than wired • Good level of safety • Best range

CONS

• Long development time due to the complexities of wireless communications • Lowest reliability due to the complexities of wireless communications • Highest cost

Concept AB - Tethered Hybrid PROS

• Most safe concept because it provides two ways to kill robot operation • Most effective method because tethered connection allows most resilient

connection to robot CONS

• Longer development time since there is a need to develop both a kill switch on the remote controller and a standalone kill switch box

45

Concept AD - Wireless Hybrid PROS

• Best wow factor • Highly effective because stand alone kill switch acts as back-up to controller kill

switch • Excellent range

CONS

• Longest development time since we would need to design two separate wireless communication links

46

7) Software A. User Interface Software Concept Selection Overview Here are the concepts for the software selection. There are two realms to consider the software for. One is the software that will be used on the PC which the user uses to input coordinate data to the platform. The other is the software that is running on the platform that will receive the coordinate data and control the robot as it moves to the coordinates. Screening Stage

Figure E7.0

Selection Stage

Figure E7.1

Conclusion For the software that the user will use to input coordinate data and that runs on the PC, LabView is the clear winner. LabView is a premier software package that is extremely

47

fast to develop and easily maintainable. It is very easy to create elegant and highly functional graphical user interfaces using LabView. Visual Basic is a popular graphical programming language but out group does not have much experience with this platform and therefore it scores worse than LabView. B. Platform Software Concept Selection Screening Stage

Figure E7.2

Breakdown of Selection Criteria Cost- This consists of total cost of the software package of each option. Time requirement- This consists of the programming time required to get each option to work Ease of Implementation- This is the difficulty in arriving at a software solution Maintainability-This is how easy it will be to someone to modify the code at a later date Team Experience-This rates the amount of experience on the team Debug-This rates the quality of the debugging features available for the language Number of Features-This rates how many tasks can be supported within the language Resource Requirements- This consists of how much memory will be required to run each option. Portability- This consists of how easy the program will be able to be interchanged between different operating systems.

48

Wow Factor- This refers to how impressive the user interface will be to the user. Selection Stage

Figure E7.3

Conclusion The software that runs the platform will have three main functions. It will receive user input from a PC that will contain coordinate data, receive user input from a remote controller and it will need to be able to guide the robot by issuing the correct commands to the motor control software. It initially look like the best solution will be to use a shell language like BASH to call small functions and programs written in C/C++. This presents many interesting problems but it we think that the overall system will be easier to build in this manner. Not the least of the reasons is the shells ability to pipe data which is critical to platform control. It is a involving process to do this in a compiled language. Therefore, someone with the most basic C/C++ experience can write a simple program that will be called and controlled from the script. Data flow can be handled by the shell rather than inter-process communication which presents its own difficulties. One screaming shortcoming of a shell language such as BASH is that there is no floating point math integration. This weakness actually highlights its strength. BASH can call an external program (such as ‘bc’) and take that output and pipe it to where it is needed. Complex mathematical computation can be accomplished with a shell in this manner.

49

8.) Back Plane Power Connection Concepts Overview The Lynx 586 SBC and daughter boards will be placed inside a mechanical box. There must be power provided to these boards inside the box. The solution to provide power should be user friendly, and robust. After looking at several different solutions, the most feasible and best solutions would be an ATX connector, a PCB connector, or a Military Spec. connector. These solutions can be seen in Table 1.1. Screening Stage

Figure E8.0

Selection Stage Following the Pugh Chart guidelines, a reference design was chosen to which all other designs were rated. The ATX connector was chosen as the reference design because it will be needed in both other concepts, and is also readily available , simple to implement, and cheap.

Figure E8.1

50

In the second Pugh Chart, each selection criteria was given a weight and each method a weighted score. It was decided that the PCB connector and Military Spec connector are worth looking farther into for prototyping. Break Down of Selection Criteria Cost- This subcategory deals with the cost of developing and/or purchasing each solution. Development Needed- This subcategory deals with the time of development that it would take to integrate the solution into the power backplane. Customer Ease of Use- This consists of how easy it is for the end user to disconnect and reconnect the electronics of the robot to the platform, in a timely manner. Robustness- This subcategory deals with how well the backplane holds up after several uses. The user should be able to connect and disconnect several hundred times without effective wear on the connector. Off the Shelf- This subcategory deals with the availability of the parts, and the least amount of custom work that needs to be done to create the solution. Concept 1 – ATX Connector

Figure E8.2

PROS • Implementation cost- can be bought pre-made • Cost- low cost around $5 • Form Factor- plugs right into Lynx 586 SBC and daughter boards on 8-pin side

CONS

• Not robust – plastic connector not meant to disconnect and reconnect several times

• Not easy to use- difficult plastic locking to disengage with fingers

51

Concept 2 – PCB Connector

Figure E8.3

PROS

• Fully customizable- Can use any surface mount connector, and can also incorporate any other custom circuitry onto the PCB

• Robust- Connectors are more heavy duty, mounting holes to screw into back of box.

• Ease of Use- No locking or unlocking CONS

• Cost- PCB material, connectors, screws, ATX cable all included in cost • Development – Must design PCB layout • Off the shelf- PCB would be custom designed

Concept 3 – Military Spec Connector

Figure E8.4

52

PROS • Robust- These are military grade connectors used in all the armed forces • Off the shelf- Already built

CONS

• Development- Adaptor cable needs to be made to connect to 4-pin ATX connector

Conclusion The PCB and Military Spec both seem to be the best solutions so far. Both provide a robust, user friendly solution for providing power to the electronics. Both of these solutions however will also use the ATX 4 pin to 8 pin connector. Further research must be performed to find the optimal solution.

APPENDIX A - Design Change Protocol

When a design change (DC) that affects both platform teams has been decided on the following protocol should be followed.

• First the engineer who wants a change discusses the change with their appropriate lead. (i.e. a mechanical change is discussed with the mechanical lead, likewise with electrical.)

• The Design Change Request (DCR) form is completed and then signed off by the engineer lead who then passes the DCR and appropriate DC drawings to the systems engineer.

• The system engineer will meet with the other team’s system engineer to discuss the DC.

• The second system engineer will take the DCR to their engineer lead to make sure that the other teams DC does not create any new problems with either team, and then the second engineer lead will sign off on the DCR.

• The system engineers will meet a second time to discuss the DC one more time, and report both teams responses and if any changes need to be made. Both systems engineers will sign off and the design change can then be implemented. The systems engineer will then go back to the original engineer and give the go ahead to upload the design change into the repository, to make sure the most up to date design is accessible.

APPENDIX B- Design Change Request Form 7204 10Kg Platform 7205 100Kg Platform Date:____________

Design Change Request Design Change: Reason for Change: Authorization System Engineer 7204:__________________________________________ System Engineer 7205:__________________________________________ Engineer Lead 7204:__________________________________________ Engineer Lead 7205:__________________________________________

Benchmarking References: US First homepage http://www.usfirst.org/ 10 kg Wifi Robot http://www.therobotstore.com/s.nl/it.A/id.293/.f

P3-DX http://www.activrobots.com/ROBOTS/p2dx.html

People Bot http://www.activrobots.com/ROBOTS/peoplebot.html

amigo http://www.activrobots.com/ROBOTS/amigobot.html

P3-AT http://www.activrobots.com/ROBOTS/p2at.html

Pack Bot Technical Robot http://www.defense-update.com/products/p/pacbot.htm

APPENDIX C - Project Schedule

APPENDIX D - Benchmarking Comparison Spreadsheet

APPENDIX E – PRP Wiki Code If a particular aspect of a section is not applicable for a given project, it is only necessary to indicate that by entering N/A (not applicable). This document describes and serves as a template for preparation of a Project Readiness Package. The objective of the Project Readiness Package is to document: * Customer needs and expectations * Project deliverables (including time frame) * Budget * Personnel / organizations affiliated with the project It will serve as the primary source of information for students necessary during Phase 0 (Planning) to develop a SD I plan and schedule including specific deliverables and due dates. The Project Readiness Package will also support Faculty evaluation of project suitability in terms of depth, scope, and student / faculty resources by discipline. == Administrative Information == ; Project Name : RP 10 Drive Platform ; Project Number : [[P07204:public/Home|P07204]] ; Project Family : [[P07200:public/Home|P07200 Modular Robotic Vehicle Platform]] ; Track : Vehicle Systems Technology ; Start Term : 2006-2 ; End Term : 2006-3 ; Faculty Guide : Dr. Wayne Walter (ME) ; Faculty Consultant : Prof. George Slack (EE) : Graduate Teaching Assistant : Jeff Webb (ME) ; Primary Customer : Dr. Hensel (ME Dept. Head) ; Secondary Customers : Dr. Crassidis (ME), Dr. Hu (CE), Dr. Yang (CE), Dr. Sahin (EE), and Dr. Walter (ME) ; Customer contact information : Dr. Edward Hensel, PE :Professor and Head :echeme@rit.edu === Mission Statement === To develop a drive platform for the robotic vehicular platform incorporating modular motors from P07201. The analysis, design, manufacturing, fabrication, test and evaluation will be completely documented to a level of detail that a subsequent team can build upon the work with no more than one week of background research. The robotic vehicular platform family must be within a budget of $15,000.

=== Project Overview === <!-- 1 Paragraph that provides a general description of the project in terms of background, motivation(s), customer(s), and overall objective(s) --> This student team will develop two modular, fully functional robotic platforms capable of carrying a payload anywhere in the robotics lab, room #9-2230 in Building #09 on the RIT campus. The drive platforms should utilize the RP10 Motor Module, the scalable open architecture motor controllers and the DAQ systems where appropriate. One drive platform (Device RP10A) shall be three wheeled, with at least one RP10 motor module, and a payload capacity of at least 2.5kg. The second drive platform (Device RP10B) shall have at least four wheels, with at least two RP10 motor modules, and a payload capacity of 10kg. By the conclusion of Senior Design II, the team must demonstrate the following: '''Test 1:''' ''This test will be conducted in the Robotics Lab - room 09-2230.'' # Remote Control Operation (Tethered or Wireless) of Device RP10A, (carrying a 2.5 kg payload) from the doorway entrance to the lab from the main hallway, through the desks to the front of the room by the instructors work station. # At the instructors work station, at least one motor module will detached from Device RP10A and will be attached as a functional motor module to Device RP10B (This task will be accomplished by a team member in 120 seconds or less). # Device RP10B shall be operated under remote control (Tethered or Wireless) from the front work station to the doorway entrance to the lab from the main hallway. '''Test 2:''' ''This test will be conducted on a 10' x 10' tiled open floor (e.g. the floor in 09-2230).'' # 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 RP10A. After it is received by device RP10A, all connections must be severed. This step must be completed in 120 seconds or less. # Device RP10A must autonomously navigate to each coordinate, in order, stopping for 10 seconds at each. The team must provide complete documentation of the analysis, design, manufacturing, fabrication, test, assembly, operation and evaluation of this subsystem to a level of detail that a subsequent team can build upon their work with no more than one week of background research. === Staffing Requirements === {| class="wikitable" |+ '''Staffing''' |- !Team Member !! Discipline !! Role / Skills !! email address |-

||Wayne Walter|| ME || Faculty Guide, Will work closely with the team on an on-going basis to facilitate success. || [mailto:wwweme@rit.edu wwweme@rit.edu] |- ||George Slack|| EE || Faculty Consultant, Will provide EE discipline technical support on an intermittant basis. || [mailto:gbseee@rit.edu gbseee@rit.edu] |- ||Jeff Webb || ME || Teaching Assistant || [mailto:jbw3914@rit.edu jbw3914@rit.edu] |- ||Kate Nordland || ME || P07898 software contact || [mailto:ken9444@rit.edu ken9444@rit.edu] |- ||Brandon Howell || EE || Power Electronics Engineer ||[mailto:Bmh9641@rit.edu Bmh9641@rit.edu] |- ||Daniel Wong || EE || Communications Engineer || [mailto:Daw8121@rit.edu Daw8121@rit.edu] |- ||Brad Whitlock || EE || Chief Electrical Engineer || [mailto:Bdw1960@rit.edu Bdw1960@rit.edu] |- ||Chris Chavoutie || EE || Systems Integration Coordinator || [mailto:Crc4761@rit.edu Crc4761@rit.edu] |- ||Joe Krisher || ME || Mechanical Systems Engineer || [mailto:Jjk7687@rit.edu Jjk7687@rit.edu] |- ||Geoff Heitzenrater || ME || Chief Mechanical Engineer || [mailto:gsh4150@rit.edu gsh4150@rit.edu] |- ||Anastasia Lorenz || ME || Additional Mechanical Support || [mailto:Aml8774@rit.edu Aml8774@rit.edu] |- ||Nathan Boyer || ME || Project Management || [mailto:ndb9535@rit.edu ndb9535@rit.edu] |} Project Manager - 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 === <!-- Include prior project number and title and to what extent previous results are being incorporated --> 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. 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 an infra-structure to support the dnyamometry needs of the vehicles under development. In addition, this project should provide the foundation for the dynamometry needs of the ME department at RIT, and in particular the automotive option of the ME program. 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:public/Home|P07200]] || Vehicle Systems Technology Track || 2006-1 || On-going |- ||[[P07201:public/Home|P07201]] || Motor Module - Robotic Platform 10 kg (RP10) || 2006-1 || 2006-3 |- ||[[P07202:public/Home|P07202]] || Motor Module - Robotic Platform 100 kg (RP100) || 2006-1 ||2006-2 |- ||[[P07203:public/Home|P07203]] || Dynamometry || 2006-1 || 2006-2 |- ||[[P07204:public/Home|P07204]] || RP10 Drive Platform || 2006-2 ||2006-3 |- ||[[P07205:public/Home|P07205]] || RP100 Drive Platform || 2006-2 ||2006-3 |-

||[[P07301:public/Home|P07301]] || Systems and Controls: Sensors || 2006-1 || TBD |- ||[[P07302:public/Home|P07302]] || Systems and Controls: Actuators || 2006-1 || TBD |- ||[[P07303:public/Home|P07303]] || Systems and Controls: Wireless Communications || 2006-1 || TBD |} === Principle Sponsor or Sponsoring Organization === [[Image:gleason.jpg|frame|right|200px|Support for this project is generously provided by the Gleason Foundation.]] This project is supported by a gift from the Gleason Foundation to the mechanical engineering department at RIT. == Detailed Project Description == ; Overview of related Projects as of Beginning of Winter Quarter === Customer Needs === ; 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. Ideally the motor modules should be easily interchangable to change all modules from one platform configuration to the other within the given time constraint. 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 ==== <!--# Express the need in terms of what the product has to do, not in terms of how the product might do it. # Express the need as specifically as the raw data. # Use positive phrasing # Express the needs as attributes of the product --> * 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 US FIRST robotics competition. ====Voice of the Customer, Project Objective Tree==== This objective tree was created using test code from P07898 and pertains solely to P07204 # Constraint #* Safe # Resources #* Design completed by March 2007 #* Build completed by May 26 2007 # Economic #* Affordable #** Fits within given budget of $15,000 for family # Scope

#* Of the Shelf components #* scalable #* Interchangable modules #* Better than the baseline kit #* Useable within the KGCOE #* "Cool" #** Impressive looking #** Exciting technology for "wooing" prospective students #* Documentation #** Open source documentation #** Clearly well documented #** Should be able to be caught up on in 1 week # Technical #* Mounts #** microcontroller mount #** battery mount #** modular motor mounts #** up to 6 motor "slots" #** payload mount #** sensor mounts #** Mount location for antenna #* Design Constraints #** Supports required payload #** Size constraint #*** Can fit through doorways #** Tare weight constraint #** Turning radius constraint #** Remote distance constraint #* Project compatibility #** Uses motors developed by 7201 #** 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 The link below is the Needs Assesment developed by the P07204 team members during the begining of SD1. ;[[P07204NeedsAssessment|NeedsAssessment]] ====Voice of the Customer, 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. # '''Constraint Objectives''' #* '''Regulatory Constraints''' #** C.1 The design shall comply with all applicable federal, state, and local laws and regulations. '''Measure of Effectiveness:''' Every team shall identify at least one federal, state, or local law or regulation that may have an impact on the system design. The team shall demonstrate compliance with said regulations. Particular attention shall be paid to OSHA requirements, and safety codes and standards related to rotating equipment. ##* C.2 The design shall comply with all applicable RIT Policies and Procedures. '''Measure of Effectiveness:''' The team shall offer their design for review by the RIT Campus Safety office, and shall rigorously follow RIT procedures associated with purchasing and safety. ##* C.3 Wherever practical, the design should follow industry standard codes and standards. Safety codes shall be treated as design requirements. Industry standards should be used wherever practical. '''Measure of Effectiveness:''' The team shall identify at least one mechanical and at least one electrical standard complied with during the design process. #* '''Academic Constraints''' #** C.10 Every SD1 project should result in a technical report, including a set of design drawings and bill of materials supported by engineering analysis. '''Measure of Effectiveness:''' 80% of all SD1 evaluation responses by all review panels should be at a score of "acceptable" or higher. #** C.11 Every SD2 project should result in a physical engineering model, supported by experimental test and evaluation data. '''Measure of Effectiveness:''' 80% of all SD2 evaluation responses by all review panels should be at a score of "acceptable" or higher. #* '''Safety Constraints''' #** C.20 The top speed of the vehicular platform should be scaled with its size, and should be safe for its operating range (environment). #** C.21 The vehicular platform shall have on-board and remote "kill switches". #** C.22 Human safety takes precedence over all other design objectives. #** C.23 Building and facilities safety takes precedence over robotic vehicle platform damage. #** C.24 The vehicle should be robust to damage by inexperienced operators. # '''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 team members should fabricate most custom components on campus, and the design should consider in-house manufacturing resources. #** R.11 The team members should fabricate most custom components on campus, and the design should consider in-house manufacturing resources. #* '''Time Resource''' #** R.20 Each student team member should be expected to work a minimum of 8 and a maximum of 16 hours per week on the project. Each student should ideally spend an average of 12 hours per week on the project. The scope of the project has been designed with these limits in mind. # '''Economic Objectives''' #* '''Materials Costs''' #** R.30 The total development budget for the roadmap / track is not anticipated to exceed $15,000 during AY06-07 and 07-08 for first article prototypes of each project. The distribution of this amount between projects in the roadmap is left to the discretion of the DPM team. #** R.31 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should decrease with increasing volume. #** R.33 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should decrease with decreasing levels of instrumentation, but shall remain capable of being retro-fitted with instrumentation after initial manufacturing. #** R.34 The cost to manufacture subsequent copies of a designed vehicle, sub-assembly, or part should be borne by the team, faculty member, research project, company, or department desiring to use the item for their research and development work. #* '''Labor Costs''' #** R.40 The design team is not expected to account for the nominal labor costs of RIT shop personnel as long as the time commitment does not greatly exceed that of other typical SD projects. #** R.41 The design team is not expected to account for the nominal labor costs of TA's, Faculty, or other staff assigned to assist and guide then team, as long as the time commitment does not greatly exceed that of other typical SD projects. #* '''Amortization Costs''' #** R.50 The design team is not expected to recover the investment costs associated with the platform development. # '''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 team. #** S.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. #** S.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. #** S.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. #** S.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. # '''Technology Objectives''' #** T.1 The 10 Kg and 100 kg robotic platform motor modules shall be designed and built first. #** T.2 The 1 and 1,000 Kg robotic platform motor modules shall be designed and built second. #** T.3 The range of the 100 Kg robotic platform shall be the James E. Gleason Building, RIT Bldg #09. #** T.4 The range of the 10 Kg robotic platform shall be the floor of a single room in the James E. Gleason Building, RIT Bldg #09. #** T.5 The range of the 1 Kg robotic platform shall be an 8'8 by 8' table top. #** T.6 The range of the 1,000 Kg robotic platform shall be the RIT Campus. #** T.7 Technologies, software, modules, algorithms, and other developments should be made available to and accessible by the Underwater vehicle platform team and the airborne vehicle platform teams, and vice-versa. #** T.8 The results of this platform development roadmap should increase the reputation and visibility of the RIT SD program and our robotics technology "skill level" on a national basis. '''Measure of Effectiveness:''' By June 2008, at least five student-authored conference papers shall be submitted for publication at technical conferences (outside of the RIT senior design conference). '''Measure of Effectiveness:''' By June 2008, at least one student-authored journal paper shall be submitted for publication. #** T.9 The modules of the robotic platform shall be re-configurable into many different configurations. For example, it should be EASY and LOW COST to take expensive drive

components for individual wheel drives and assemble them into 3-wheel, 4-wheel, and 6-wheel configurations, with the number of driven wheels ranging from 1 to 6. #** T.10 The preferred motion control technology is drive by wire. #** T.11 The preferred energy source is rechargeable DC battery. #** T.12 Technology priorities: (1) Two Wheel drive, skid steer (2) Two wheel drive, turn steer (3) Position and heading data logging (4) Autonomous control by the payload client (5) Passive Suspension (6) DFMA (7) Active suspension #** T.13 As every technology is introduced that technology must be (1) observable by and (2) controllable by the payload client. #** T.14 Each variant of the vehicle must be clearly impressive to any student, parent, engineer, mentor, or individual familiar with the ''FIRST'' robotics competition. ====Voice of the Engineer, Function Tree==== * V.1 The platform must be demonstrated functional in the two different configurations shown below. [[Image:configurations.jpg|frame|700px|Figure 1: Prototype Configuration Requirements]] * 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. {| class="wikitable" |+ Table 1: Tradeoff Assessment ! Model !! Size (m) !! Tare Weight (kg) !! Payload Capacity (kg)!! Speed (m/s)!! Turning Radius (m)!! Remote Range (m) |- ! R10 | 0.30 x 0.15 x 0.30 || 9 || 10 || 2.25 || 0.30 || 30 |} * 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. ====Background Information Provided by the Customer ==== ===== Useful Web Resources ===== You may find it helpful to review these web resources to get comfortable with the robotic platform.

To be completed ===== Initial Concepts to Consider ===== To be completed === Customer Deliverables === <!-- Customer requested milestones, progress reports, and expected product --> Design and build a drive platform incorporating the motor modules, motor controller and battery provided and including a platform top with mounting points for securing a payload. See the "Detailed Course Deliverables" section for more specifics. === Customer and Sponsor Involvement === <!-- Describe role of customer and sponsor in the project, planned participation in design and project reviews, etc. --> 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. === Regulatory Requirements === <!-- i.e. UL, IEEE, FDA, FCC, RIT --> * 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 === <!-- Provide all budget details and processes associated with expenditures -->

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 === <!-- Describe any IP concerns or limitations associated with the project --> All work to be completed by students in this track is expected to be released to the public domain. Students, Faculty, Staff, and other participants in the project will be expected to release rights to their designs, documents, drawings, etc., to the public domain, so that others may freely build upon the results and findings without constraint.

Students, Faculty, and Staff associated with the project are encouraged to publish findings, data, and results openly. === Engineering Specifications === <!-- Describe any known engineering specifications not specified by the customer --> ;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. === Safety 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 == <!-- From the Course Deliverables document, extract general and discipline specific deliverables that are appropriate to the project. This should provide clear guidance to the students on what is expected. --> Note that this level describes an absolute level of expectation for the design itself, and for the hardware. However, the student team must also meet all requirements related to analysis, documentation, presentations, web sites, and posters, etc. that are implicit to all projects. See [https://edge.rit.edu/content/Senior%20Design%20I/public/Course%20Deliverables| Senior Design I Course Deliverables] for detail. ;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 robotics lab. * The Platform will be interchangeable from a triangular configuration to a rectangular configuration. * The Platform will be capable of carrying a 2.5kg payload (triangular configuration) and a 10kg payload (rectangular configuration). == Preliminary Work Breakdown == <!-- Describe the anticipated distribution of general tasks to be accomplished by project participants based on perceived skill set requirements. This should justify the requested skills and number of students from each discipline --> <!-- List expected activities in the first three weeks. Highlight any project specific activities that may not be part of the generic course syllabus (e.g. customer visits). --> This project will closely follow the three week project workshop schedule presented in SD1. See the [https://edge.rit.edu/content/Senior%20Design%20I/public/Course%20Calendar| 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.''''' {| class="wikitable" |+ EXPECTED DELIVERABLES FROM WORK BREAKDOWN ! Student !! Week 1 !! Week 2 !! Week 3

|- || ME 1 - Project Manager || 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 - || * Prepare an informal presentation that will allow the rest of the group to gain background knowledge of this project, 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 P07204 webpage using wiki format. || * Sketch or model in Pro/E the concepts generated to share with the rest of the group. || * Summarize the feasibilities of each concept on P07204 webpage using Wiki format. |- || ME 3 - || * 3-D Model to scale of entire robotics lab using Pro/E. * Summarize dimensions gathered in a table on P07204 webpage using wiki format || * Sketch or model in Pro/E the concepts generated to share with the rest of the group || * Summarize the feasibilities of each concept on P07204 webpage using Wiki format |- || ME 4 - || * 3-D Model to scale of entire robotics lab using Pro/E.

* Summarize dimensions gathered in a table on P07204 webpage using wiki format || * 3-D Model to scale of P07301 and P07302 projects using Pro/E. || * Yet to be determined |- || ME 5 - || * Prepare an informal presentation that will allow the rest of the group to gain background knowledge of this project, what must be considered mechanically for the motor module while designing our project, and how to get more information if needed in the future. * Summarize report on P07204 webpage using Wiki format. || * Sketch or model in Pro/E the concepts generated to share with the rest of the group. || * Summarize the feasibilities of each concept on P07204 webpage using Wiki format |- || EE 1 - || * Prepare an informal presentation that will allow the rest of the group to gain background knowledge of this project, 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 P07204 webpage using Wiki format. || * Sketch or model in Pro/E the concepts generated to share with the rest of the group. || * Summarize the feasibilities of each concept on P07204 webpage using Wiki format. |- || EE 2 - Electrical / Mechanical integration || * Prepare an informal presentation that will allow the rest of the group to gain background knowledge of this project, what must be considered while designing our project, and how to get more information if needed in the future. * Summarize report on P07204 webpage using Wiki format. * Present all dimensional data to ME 3 for modeling during week 2. || * Sketch or model in Pro/E the concepts generated to share with the rest of the group. || * Summarize the feasibilities of each concept on P07204 webpage using Wiki format |}

Click on link below to see detailed descriptions of work breakdown structure of each team member. ;[[P07204workbreakdown|Detailed Preliminary Work Breakdown]] == Grading and Assessment Scheme == <!-- Describe how the grading rubric relates to expectations and deliverables. The impact of project enhancements and improvements from baseline should be clearly articulated. --> 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 triangular robotic platform that successfully carries a 2.5kg payload from the front to the back of the robotics lab (Room #9-2230). The robotic platform is operated by remote control. ;Level C: :The student team will deliver all elements of Level D PLUS: The team builds a second platform in rectangular configuration capable of carrying a 10kg platform from the back of the robotics lab to the front. ;Level B: :The student team will deliver all elements of Level D and C PLUS: One motor module will be interchanged from the triangular platform to the rectangular platform within 120 seconds. The overall appearance of the robotic platform is capable of impressing perspective students. ;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 at the front of the robotics lab within 120 seconds. == Three-Week SDI Schedule == <!-- List expected activities in the first three weeks. Highlight any project specific activities that may not be part of the generic course syllabus (e.g. customer visits). --> This project will closely follow the three week project workshop schedule presented in SD1. See the [https://edge.rit.edu/content/Senior%20Design%20I/public/Course%20Calendar| 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. # Build the kit provided by the Teaching Assistant. # Test and fully characterize the equipment in the kit. # Compare the results with the other Vehicle Systems Technology Track teams. == Required Resources == <!-- Describe resources necessary to support successful Development, Implementation and Utilization of the project. This would include specific faculty expertise for consulting, required laboratory space and equipment, outside services, customer facilities, etc. Indicate if required resources are available. --> {| class="wikitable" |+ Faculty ! Item !! Source !! Description !! Available |- || Prof. Walter || ME || Faculty Guide/Coordinator/Mentor || Yes |- || Prof. Hensel || ME || Customer || Yes |- || Prof. Slack || EE || Technical Consultant || Yes |} {| class="wikitable" |+ Environment ! Item !! Source !! Description !! Available |- || Robotics Lab || ME 09-2230 || Work Space/Storage || Yes |- || Sr Design Lab || EE 09-3xxx || Work Space || Yes |- || ME Shop || ME 09-2360 || Parts Fabrication || Yes |} {| class="wikitable" |+ Equipment ! Item !! Source !! Description !! Available |- || DC Motor Dyno || EE Electric Machines Lab || Characterization || Unknown |- || Power-supply || EE Department || Used for Testing ||Unknown |- || Desktop PC || Throughout || Programming || Yes

|} The team members will be expected to procure the materials needed for the project, excluding the following: {| class="wikitable" |+ Materials ! Item !! Source !! Description !! Available |- || Super Droid Robot ATR || Teaching Assistant || 10kg payload example ||Yes |- || IFI Robotics Kit || Teaching Assistant || 100kg payload example ||Yes |} ==Requested Resources== In order to be successful on this project, it would be greatly advantageous to have the following items in place. * 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 * 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.

==Possible Areas of Concern== It is acknowledged that one of the largest areas for concern in this family of projects is the interconnected nature of the teams. There is a large dependancy on other people to pull through for your team to be successful. Prompt responses to questions for information are critical. Decisions with regards to the project interfaces need to be made quickly and not to be waiting for someone else to make the call. Consideration must be made for the P07300 family of projects which are not being made solely for use on this robotic platform. While the requirements for an A on the project have been laid out, there is significant room to go above and beyond this scope. In order for the project to reach the highest level of impressiveness, the team will need the buy-in from all of the team members, as well as team members from additional teams. Another concern is that the team members for P07201 might not be on campus (on coop) during the winter quarter making communication more difficult. Setting up means of communication and the understanding of the need to get information from these team members at the end of Fall Quarter 2006 will help reduce problems that might occur with this issue. Also P07201 will not have a completed 10kg motor until Spring 2006 in parallel with the due date of the 10kg robotic platform. It is ESSENTIAL that the two teams work closely together so both projects are successful. A backup would be to find alternative motors incase there is a miscommunication.'''