Proceedings of IMECE 2008ASME 2008 International Mechanical Engineering Congress and Exposition

November 1-6, 2008, Boston, USA

IMECE2008-66128

FAMILY-BASED PROJECT APPROACH TO MULTIDISCIPLINARY SENIOR DESIGN

Dr. Wayne Walter ∗

Department of Mechanical EngineeringRochester Institute of Technology

Rochester, New York 14623Email: wwweme@rit.edu

Dr. Edward HenselDepartment of Mechanical Engineering

Rochester Institute of TechnologyRochester, New York 14623

Email: echeme@rit.edu

ABSTRACTDuring academic year 2006-07, a family of four closely

related multi-disciplinary senior design projects was initiated.Each project team consisted of eight undergraduate students.The family of projects has continued during the academic year2007-08, with three additional design projects comprised of 19students. The intent of the family of design projects is two-fold.The first objective is to introduce students to the concept of de-signing a product within the context of a family of closely relatedproducts, similar to the approach that a corporation may use inits strategic approach to the marketplace. The second objectiveis to provide an open-source, open-architecture, modular, andscalable robotic vehicle platform usable by a wide range of re-searchers within the Kate Gleason College of Engineering look-ing for a vehicle to position cameras, sensors in networks, andfor other data-gathering tasks. Students were given the chal-lenge to design and manufacture a platform based on a singledesign, scalable across four payload orders of magnitude from1kg to 1,000kg. The10kg and100kg variants were studied inAY2006-07, and the1kg variant was introduced in AY2007-08.The largest,1,000kg, planned for the future, will be about thesize of a Honda Civic, so safety and fail-safe engineering is im-portant. Each project in the family is expected to build on thetechnology used and lessons learned from prior and concurrentprojects, much like the ”next model year” in the auto industry,and information sharing requirements among concurrent engi-neering teams. Hardware, software, and design methods arereused whenever possible, and students are expected to developtheir subsystem in the context of an evolutionary platform design.

∗Address all correspondence to this author.

In this manner, the end-product from one design group becomesthe starting point for another team. Responsibilities overlap soteams must work cooperatively, which mimics the industrial en-vironment. Starting times on various projects may be staggered,and students must deal with documentation sharing issues, andpreservation of design intent across multiple-project teams andacademic terms. The paper will discuss the current status of theprogram, the lessons learned to-date, and future plans for theprogram.

NOMENCLATURERP1 1kgnominal payload capacity robotic platform.RP10 10kgnominal payload capacity robotic platform.RP100 100kgnominal payload capacity robotic platform.RP1000 1,000kgnominal payload capacity robotic platform.MM Motor Module – independently controlled servo-motor

driven wheel.MSD Multi-disciplinary senior design course I, II sequence.DPM Design Project Management course.

Multi-Disciplinary Senior DesignRochester Institute of Technology (RIT) operates a multi-

disciplinary senior design (MSD) program involving fifth yearcapstone design students from mechanical engineering (ME), in-dustrial engineering (IE), electrical engineering (EE), and com-puter engineering (CE). On occasion, students outside of theKate Gleason College of Engineering (KGCOE) also participatein the MSD program. The MSD program involves over 400 en-

1 Copyright c© 2008 by ASME

gineering students annually, working on more than forty designprojects each academic year. Each MSD design team typicallyconsists of at least five and no more than eight students. Projectsare designed to insure the students from at least two disciplinesare represented on each team, or to insure that single-disciplineteams have distinct interface requirements to another team orproject. Every team has a faculty guide, drawn from the par-ticipating departments. Each team also has a customer, which inmost cases is a representative from a private company or projectsponsor. Each department has identified one faculty member toserve as a discipline consultant to all of the students across teams,and one faculty member to provide overall logistics managementacross departments.

The faculty guide’s role is to serve as a “guide on the side,”working with each MSD team to achieve a successful designproject. In most cases, the faculty guide is working with a de-sign team that is directly related to the individual’s area of pro-fessional development. The discipline consultants play the roleof a technical consultant, and are available to help their studentswith a particular problem. For example, if an EE student is ona team guided by an ME professor, and managed by an IE stu-dent, then the EE discipline consultant is available to help withtechnical questions in that field.

Projects are defined by dual degree students (progressingconcurrently towards their Bachelor’s and Master’s degree) inconsultation with faculty guides and customers during a coursetitled “Design Project Management”, (DPM). At the conclusionof DPM, each DPM student has prepared a project readinesspackage and assembled startup information to engage the restof the student team. The DPM students typically become theproject manager or lead engineer on their design teams, and as-sist with recruiting students to fill out their team. Approximatelyfifty students complete DPM each academic year. The fifth yearstudents take two courses in MSD, and during their first quar-ter, each team presents their concept design, embodiment design,and preliminary design to a design review panel, consisting of thefaculty coordinators, non-mentor faculty, and external customersand industrial advisory committee members. The review panelparticipates both in informal reviews throughout the quarter, aswell as a more formal managerial review at the end of the quarter.At the end of the second MSD quarter, the students present theirdesign, demonstrate their prototype, and present test and evalua-tion findings in the setting of a professional technical conference,while also undergoing a critical design review, which is open tothe public.

With nominally 400 students working more than two quar-ters (11 weeks) in MSD I and II, 50 students for one quarterin DPM, numerous faculty and corporate partners, per academicyear it becomes clear that this represents a significant investmentof talented design effort. Conservatively, we estimate that thestudents alone expend more than 45 engineer-years of effort inthe DPM/MSD program annually. Managing this level of design

effort represents both a significant challenge, and a large oppor-tunity.

In this article, we will review our reflections on how to cre-ate a structure for managing a large number of disparate designprojects, while at the same time trying to insure that the resultsfrom one student team get passed along to another project team.The hand-off between design groups represents a challenge facedin industry, and this MSD program attempts to re-create thatchallenge, and implement solutions, so that students can expe-rience a more realistic design project within the academic envi-ronment. A critical aspect of managing this large resource hasbeen to create several themes, or “tracks” of projects that stu-dents can readily associate with their academic programs, and todevelop “families” of closely integrated projects that span mul-tiple student teams and academic years. We will summarize themanner in which projects are organized by “track” and “family”,and then illustrate one example family of projects that has beenunder way for two years. We will introduce our future plans forthis family of projects, and end with a series of conclusions andrecommendations for next steps as we roll this program out to theentire RIT community, and collaborating institutions in Europe.

Project TracksA track is a general category of projects to which a stu-

dent project may belong. Tracks are helpful for students seek-ing project membership in that they provide a way to look fora project in an area, but without knowing the specific projects.Tracks of projects are generally correlated with the various con-centrations and options offered through the departments in theKate Gleason College of Engineering (KGCOE) at Rochester In-stitute of Technology (RIT). Six tracks currently being investi-gated by students in the multi-disciplinary senior design projectcourse include:

Assistive Devices and Bioengineering Track –These projectsare generally of interest to students enrolled in the bioengi-neering or biomedical options within their departments, orhave an interest in applying engineering upon the founda-tion of the biological sciences. Projects in this track includenumerous assistive device tasks, artificial heart pump testingsystems, robotic arm and hand manipulators, lung inhalationtesting apparatus, and bio-sample preparation.

Aerospace Systems and Technologies Track –These projectsare interesting to students in the Aerospace option, or withan interest in aeronautical systems, aircraft design, andspacecraft design. Projects in this track include low-earth or-bit launch vehicles, high altitude balloon launch platforms,platform recovery systems, air/space imaging and explo-ration systems, competition teams (SAE Heavy Lift Aerodesign, and Micro-Air Vehicle teams), open source aircraft,and micro-rocket design. Air and Space craft projects of-

2 Copyright c© 2008 by ASME

ten have overlap with other vehicle systems, but also haveunique aspects related to flight.

Vehicle Systems Technology Track –These projects should beof interest to students in the Automotive option, or with aninterest in Land and Sea vehicles. This track includes wa-ter craft, under-water craft, trucks, cars, trains, inter-modaltransportation and logistics, materials handling, forklifts,and robotic vehicles,etc. Also included are projects involv-ing student design competition teams (e.g. Formula SAE,Mini-Baja) and various independent projects such IC en-gines, Fuel Cells, dynamometry, and suspension system de-sign.

Systems and Controls Technology Track –These projectsdeal with the hardware and software of systems, modeling,controls, sensors, actuators, algorithms,etc. Studentsworking in this track may also have an interest in one ofthe other applications oriented tracks. Projects includenon-GPS and GPS based navigation, autonomous naviga-tion, embedded systems, open source / open architecturedata acquisition and control, and industrial automation andcontrol applications.

Sustainable Design and Product Development Track –These projects will generally be of interest to studentsin the Energy and Environment Option, students in theSustainable Design minor, or taking the public policyminor from the College of Liberal Arts. Projects includesmall and large scale energy production and utilizationsystems (wind-powered walkway lights, LED lighting forthe campus, and co-gen system design), projects for thirdworld application (with special focus on water purification),and projects focused on product stewardship issues such asrecycling, re-use, and re-manufacturing.

Printing and Imaging Systems Technologies Track –Theseprojects should be of interest to students doing a minor inImaging Science, or with an interest in imaging and printingsystems. Projects involve the development of printer orimaging systems or subsystems, hardware that supports thedevelopment of printer and imaging systems, or projectsthat support hardware development for use in imaging andcolor science.

Project FamiliesA “family” is a group of closely related projects, which are

all focused on a particular application. Project families are typi-cally built around areas of common interest held by one or morefaculty members in the College, regardless of what disciplineor technical background they may be from. Often, a family ofprojects is closely aligned with a particular technology track. Asof September 2007, the faculty of the College of Engineeringhave defined several project families. Project families typicallyhave a close affinity to a primary “technology track” but exhibit

overlap across tracks. Some families have been under develop-ment for several years, while others are newly populated dur-ing the 2007-08 academic year. Most project families are spon-sored by gifts or grants, while some innovative projects are boot-strapped with limited funding. Current project families include:

1. Assistive Devices2. METEOR3. Modular Scalable Robotic Platform4. Formula SAE competition team5. Mini-Baja competition team6. Lean Production systems7. Modular Scalable Systems and Controls8. Sustainable Technologies for Developing Countries9. Sustainable Technologies for the RIT Campus

10. Sustainable Technologies for the Global Marketplace,11. Next Generation Thermoelectric Systems12. Printing Systems Family13. Image and Color Science.

Robotic Platform FamilyThe mission of the robotic platform (RP) family of projects,

within the Vehicle Systems Technology Track, is to develop aland-based, scalable, modular open architecture, open source,fully instrumented robotic/remote controlled robotic platform foruse in a variety of education, research & development, and out-reach applications within and beyond the RIT KGCOE. Theprojects should use an engineering design process to developmodules and subsystems that can be integrated by subsequentMSD teams. The mission of each student team contributingto the RP family is to develop or enhance a particular subsys-tem, and provide complete documentation of the analysis, de-sign, manufacturing, fabrication, test, and evaluation of eachsubsystem to a level of detail that a subsequent team can buildupon their work with no more than one week of background re-search. The RP family of projects has overlap with air platformprojects and marine platform projects also within the vehicle sys-tems track of MSD, as well as overlap with project families in theAerospace Systems and Technology track and the Systems andControls track.

At the conclusion of two academic years, students have com-pleted seven projects in the RP family, as illustrated in Table1. The mission of the P07201 team was to develop a fullyfunctional, scalable motor module subsystem for use on the 10kg (RP10) robotic vehicular platform, while the mission of theP07202 team was to develop a fully functional, scalable motormodule subsystem for use on the 100 kg (RP100) robotic vehicu-lar platform. Both were to consist of a steerable drive wheel withencoders controlled by a microcontroller. The drive motor on theRP10 was to used as the steering motor on the RP100. The mis-sion of P07204 was to develop the drive platform for the robotic

3 Copyright c© 2008 by ASME

vehicular platform incorporating modular motors from P07201,with the ability to carry a 10kg payload. Team P07205 had a sim-ilar mission using motor modules from P07202 to carry a 100kgpayload. Team P08201 developed a second generation of the10kg platform and motor module system, while team P08205 andP08208 worked closely together to create a 1 kg payload versionof the family.

Table 1. MSD Projects in the Robotic Vehicle Platform Family of

Projects.

Project Title DPM MSD1 MSD2Term Term Term

P07201 RP10 MM Spr 05-06 Fall 06-07 Spr 06-07

P07202 RP100 MM Spr 05-06 Fall 06-07 Wtr 06-07

P07204 RP10 Platform Fall 06-07 Wtr 06-07 Spr 06-07

P07205 RP100 Platform Fall 06-07 Wtr 06-07 Spr 06-07

P08201 RP10 Platform Spr 06-07 Fall 07-08 Spr 07-08

P08205 RP1 MM Fall 07-08 Wtr 07-08 Spr 07-08Wireless

P08208 RP1 MM Fall 07-08 Wtr 07-08 Spr 07-08Drivetrain

During the course of two academic years, 51 undergraduatestudents (see Table 2) and four graduate teaching assistants havebeen engaged in the RP project family. Guided by Dr. Walter,

Table 2. Student Membership by discipline in the Robotic Vehicle Plat-

form Family of Projects.

Project ME EE IE CEP07201 2 6

P07202 3 4 1

P07204 4 4

P07205 4 4

P08201 2 3 1 2

P08205 3 1 2

P08208 5

the seven design teams have developed several items of hardwareand software, along with a system architecture which is intendedto address the needs of their customer base, as represented byDr. Hensel. The RP family of projects has brought students fromfour KGCOE departments together, and the results of the projectare being considered for use by several faculty members in theirresearch programs.

Figure 1, created by students in the DPM class [1], illus-trates the relationship between multiple projects in the robotic

platform family, as well as project families related to an air-borne platform, and an underwater platform. The RP10 andRP100 projects had been investigated during AY2006-07, andthe RP1000 project was indicated as a future project. Underwa-ter and airborne project families were investigated during bothAY2006-07 and AY2007-08, and shared technology around DCmotor controls and software.

Figure 1. Overview of the RP Family. [1]

During AY2006-07, the robotics platform family of projectsprogressed in two parallel paths, with two major subsystems perpath. The RP100 device consists of two primary subsystems: theRP100 Motor Module and the RP100 Platform. The RP100 mo-tor module, illustrated in Figure 2, is intended to be an easilyreusable, “self contained motor module, for use on a reconfig-urable, open architecture robotic platform ... [with an] on-boardmicroprocessor [that] interprets commands via a CAN commu-nication bus to control in closed loop the speed and angular di-rection of a drive wheel. Locomotion and steering are providedthrough the employment of two permanent magnet DC motors;speed control is provided by dedicated H-bridge circuitry. Inno-vative power transmission and gear-train designs allow for steer-ing angles of 360+ degrees.” [2].

The RP100 Motor Module team delivered two powered mo-tor modules and two idler modules to the RP100 Platform team.The RP100 Platform team was given the task of creating tworobots that would satisfy the following customer needs:

1. Ensure safety to the users and bystanders, the facilities, thepayload, and the robots themselves.

2. Carry a payload anywhere in the J.E. Gleason building withthe exception of staircases.

3. Carry a 25 kg payload of varying shape and size on the tri-angular platform (RP100A).

4 Copyright c© 2008 by ASME

Figure 2. CAD Model of the First Generation RP100 Motor Module. [3]

4. Carry a 100 kg payload of varying shape and size on therectangular platform (RP100B).

5. Must be able to drive by remote control.6. Use commercial-off-the-shelf components where practical.7. Be scalable in order to build smaller or larger versions as

needed in future applications.8. Provide open source documentation so others can review the

project and build duplicates.9. The design should be appealing to prospective engineering

students and be an effective educational tool.

The RP100A platform is illustrated in Figure 3, and has a 1”thick ultra high molecular weight (UHMW) polyethylene flat-top. The device was able to carry more than the required 25 kgpayload, and is illustrated carrying a PC104 computer (whichincluded hardware designed by another computer and electricalengineering MSD team) as part of its payload. The RP100A em-ployed one RP100 driven motor module, and two RP100 idlermodules, designed and built by the partner team. The battery forthe platform is slung beneath the carriage, and the control systeminterface is located on top of the UHMW deck, behind the PC104cannister. An emergency-stop switch is visible at the rear of therobot.

The RP100B platform, shown in Figure 4, built by the samedesign team as the RP100A, consists of a steel frame, and incor-porates two driven RP100 Motor Modules and two RP100 idlermodules. Students had to demonstrate the ability to rapidly moveone motor module and one idler module between the RP100Aand RP100B platforms in a timed change-over, much like a rac-ing “pit-stop.”

The RP100B robot was designed with a large volume ofopen space, and T-slots on top to accommodate a range ofpayloads. The RP100B includes peripheral bumpers tied intoa safety interlock, which disables the system in the event ofcollision. The team had pursued development of an open ar-chitecture motor controller that would both drive the DC mo-

Figure 3. First Generation RP100A triangular platform. [4]

Figure 4. First Generation RP100B rectangular platform. [4]

tors and incorporate regenerative braking to re-charge the bat-teries during deceleration. The team was unable to completethe regenerative braking system, since their second generationprinted circuit boards were not available by the conclusion ofthe academic quarter. In accordance with their backup plan, theteam used commercial-off-the-shelf (COTS) motor controllersmounted atop the cylindrical motor module shields as shown inthe figure. The students demonstrated that their design was ableto progress in a concurrent fashion, with new technologies (theopen architecture regenerative braking motor controller) replac-ing standard technologies (the COTS motor controllers) as thenew subsystems mature.

The first generation RP10 Motor Module was completed inAY2006-07, and is pictured in Figure 5. The RP10 motor mod-ule was driven by an on-board micro-processor and open sourceH-bridge controls. The design of the motor controller was scal-able, so that replacement electronic components would enable

5 Copyright c© 2008 by ASME

the RP10 open source motor controller to also be used with thelarger current draw requirements of the RP100 motor module.Note also that the steering motor of the RP100 motor module isthe same make and model as the drive motor for the RP10 motormodule. Thus, between the RP100 MM and RP10 MM teams,the group investigated COTS motor controllers, open architec-ture motor controls, and open architecture / regenerative brakingmotor controls. The PCB’s used for the RP10 MM were designedto meet the existing needs of the RP10 and RP100 motor mod-ules, as well as the anticipated needs of the future RP1 motormodule. The motor controller has “complete speed control over

Figure 5. Photograph of the First Generation RP10 Motor Module. [2]

the drive and steering motors by a control signal coming froma microprocessor. This motor control requirement is typicallyaccomplished with an HBridge, which uses a set of switches tocontrol the polarity of the voltage applied to the motor. ... Inaddition to controlling the direction of the motor, these switchescan also be switched on and off rapidly to limit the amount ofcurrent given to the motor. The H-Bridge requires a pulse widthmodulated (PWM) signal to control how long the switches in theH-Bridge stay open, and thus how much torque the motor canproduce. The HBridge must be capable of controlling all of thecurrent and voltage the motor will see.” [5] The RP10 teams re-lied on a 16-bit PIC microprocessor for motor control and sensorfeedback as illustrated in Figure 6. The first generation RP10platform team successfully developed both a triangular and rect-angular platform. However, both motor module teams agreed touse a common turntable for achieving infinite azimuthal steeringangle, which fundamentally limited the size of the RP10 motormodule, and hence the RP10 platforms, which look very similarto the RP100 platforms illustrated earlier in Figures 3 and 4, ex-cept they are made from lightweight plastic framing components.

The second generation RP10 Robotic Platform was devel-oped during 2007-08, and focused on addressing several of the

Figure 6. First Generation RP10 Electronic Motor Controls and Sensor

Interface used for RP10 Motor Module. [6]

issues identified for improvement by teams during the precedingyear. The end product is illustrated in Figure 7. The device isa complete redesign of the first generation [6], and consists ofa modular design with two powered motor modules, two idlermodules, large capacity batteries for multiple hours of operation,and a wireless communications link to a laptop computer basestation. All circuits, manufactured hardware, and software areopen source / open architecture. All purchased components areavailable from multiple vendors, or may be substituted with sim-ilar components from other vendors.

Figure 7. Second Generation RP10 Robotic Platform, showing two mo-

tor modules, two idlers, integrated electronics system, battery storage,

and flexible payload platform [5].

6 Copyright c© 2008 by ASME

The electronic control and power management system forthe second generation RP10 Platform is illustrated in Figure 8.As stated by the student team [5] on their team website,

...Motor control functionality is provided through opensource H-bridge circuits and supporting logic circuitrythat has the potential to drive and steer four drivewheels. In order to meet this objective, a [Freescale]micro-controller with eight PWM output signals was se-lected. Improved designs for power transmission andgear-trains allow for steering angles of 360+ degrees.All of these electronics are powered by 12V batteriesthat are monitored through multi-colored LEDs to pro-vide feedback on battery health. ... The visual batteryhealth indication method uses six of the transistor net-works ... two have red LEDs, two have amber LEDs,and two have green LEDs. When the battery is fullycharged all six of the LEDs will be lit, indicating thatthe robot can be operated safely. As the battery chargedecreases the voltage supplied by the batteries will de-crease and the LEDs will turn off sequentially fromgreen to amber to red. When the red LEDs are the onlyremaining the user should cease operation of the robotas the battery charge is low and operation is no longersafe.

The second generation device exhibited a significant improve-ment in craftsmanship and built upon the lessons learned by thepreceding design teams.

Figure 8. Second Generation RP10 Electronics Control Board, showing

student designed and fabricated power distribution, H-bridge motor con-

trol, PWM Logic board, and battery monitor boards [5].

The RP1 Motor Module team demonstrated a significantvariation from one key design concept used by the RP10 plat-form. The second generation RP10 platform team assumed that

the interface to the motor module was at an analog signal level– PWM power to the motor, and encoder outputs being returned.Conversely, the RP1 Motor Module team placed a dedicated mi-croprocessor and wireless communications link directly on eachmotor module – essentially turning it into an intelligent wheel.As illustrated in Figure 9, each motor module can be address viawireless or wired communications link to a base station. Thisdispute between where to place the “intelligence” in the systemdesign remains a topic of discussion between student teams, andthe faculty decided to let several alternatives be studied throughthe end of AY2007-08.

Figure 9. First Generation RP1 Motor Module Wireless Communica-

tions. [7]

A CAD model of the first generation RP1 Motor Moduleis illustrated in Figure 10. While not illustrated here all designteams were required to prepare and submit all CAD and Elec-tronic CAD drawings and documentation to a version controlledrepository, so that the detailed design information would be read-ily accessible by subsequent design teams. During the course oftwo years the student teams have generated a large volume ofdrawings, documentation, test results, and findings to the pointthat incoming student teams now struggle to come up to speedin timely fashion. Teams are expected to provide detailed pur-chasing information on all COTS components, and manufactur-ing drawings for all fabricated parts.

ObservationsEngaging students in a family of inter-related senior design

projects has led us to a number of observations.

1. Students enjoy working on projects that will carry on to asubsequent term, and that will “live on” beyond their efforts.When they become emotionally invested in the project, theyexpend a tremendous amount of effort to insure success.

2. Students have a difficult time overcoming the “sunken cost”of prior design decisions which may have been developed

7 Copyright c© 2008 by ASME

Figure 10. CAD model of First Generation RP1 Motor Module Drivetrain.

[8]

by prior teams. For example, during an early-quarter designreview of MSD II with the RP1 Motor Module team [7], thefaculty customer suggested a simplified drive train designthat would eliminate the entire belt and tensioning systemfor the drive motor, reduce size and weight, and preserveall other functionality. The team, having invested weeks intheir effort, was unwilling to make this design simplification,even though it was a clear improvement and was acknowl-edged to be easier to build, test, and evaluate. This “insti-tutional inertia” is an inhibitor to innovation, and has beenobserved by the authors in professional practice as well.

3. The family definition, or “road map” for technology devel-opment, is a critical aspect of managing large numbers ofstudent teams, staffed by inexperienced engineers, with lim-ited resources. Students gravitate towards designing subsys-tems that are part of an integrated larger system. It is essen-tial that individual design projects be designed in a mannersuch that every team can make a successful contribution tothe overall roadmap, even if a particular subsystem does notmeet all specifications. Current design education in manyinstances suggests an “all or nothing” or “success or failure”outcome, rather than demonstrating that a complex productevolves over time, with the design envelope being pushedin different directions. The family approach to MSD illus-trates the concept of design envelope and product evolutionto a much greater extent than individual stand-alone designprojects.

4. Student engineers often get lost in the details of their par-ticular design specifications, and lose sight of the underly-ing customer need. Numerous examples of students chasinga design specification, rather than really understanding andsolving the underlying customer problem, were observed.For example, the students were provided with a DC servo-motor at the beginning of the course and asked to use thatmotor for the drive motor for consistency as part of the over-

all family architecture. When they observed the gearbox thatcame attached to the sample motor, they immediately be-gan designing a complicated belt system to gear the outputshaft back up. After a meeting with the faculty members,it was pointed out that the students could employ a widerange of gearboxes that were available as standard optionsfor the specified motor, and that by thinking of the problemin slightly broader terms, they could design a single mechan-ical system that would span a wide range of operation. Thisinteraction was very enlightening for the students, and verymuch opened their eyes to the issue that specifications are atranslation of customer needs, but it remains critical for theengineer to truly understand the customer need itself, andnot rely exclusively on a set of specifications.

5. Managing information and decision control across multipledesign teams and members of a distinct product family in-troduce significant aspects of engineering design that are nottypically addressed in student design projects.

Future Plans

During the upcoming 2008-09 academic year, students willbe assigned the task of reducing the physical size, mass, and costof the RP1 motor module by nominally 50%. A parallel teamwill miniaturize the RP10 second generation platform, reusing asmany electronics components as feasible, to create a second gen-eration RP1 platform with reduced weight, size, and cost. OneRP1 motor module will be shared with our partner school, INSARennes, in France as a result of our student exchange programs.The Mechanical Engineering students at INSA Rennes will adda suspension system to the RP1 motor module design, and re-turn the result to RIT at the conclusion of the academic year.The RP10 platform will be shared with the software engineer-ing department at RIT, and that student team will consolidate allof the prior two years of software development into a compre-hensive open source, open architecture, object-oriented softwareenvironment for the robots. An EE/CE MSD team will be givenanother RP1 motor module, and will similarly improve the motorcontrollers, and revisit the regenerative braking system not com-pleted in the prior years. Our long term goal includes a fully opensource, open architecture design that can be used by researchers,student organizations, hobbyists, and commercial organizations.Eventually, we plan to incorporate the platforms, software, andmotor modules as high tech modular components that first yearstudents can use in fun design competitions, as an introductionto engineering design. Future plans include a comparative out-comes assessment of design teams working in families of relatedprojects in comparison to teams working on disparate projects.

8 Copyright c© 2008 by ASME

ConclusionsRunning a successful family of inter-related projects over

multiple academic terms and years requires that that every teamdocument their design thoroughly and accurately. Since initiat-ing the family-based approach to projects, we have observed thatteams are getting better at placing their complete design historyfile on the version controlled repository assigned to each team.Team members are now motivated to provide better documenta-tion for the next team, due to their concerns about the documentsprovided by the previous team. The family-based approach toMSD clearly illustrates to students that design documentation isan integral aspect of the design itself. However, students tend tothink of the “final documents” as the critical items to pass alongto the next team, and have not yet gotten to the point where ef-fectively documenting their individual efforts,as they completetheir work, in their logbook is the norm.

Some teams remain reluctant to see their effort as part of afamily of related projects, while other teams are motivated bythis. The “silo” mentality common to many workplaces hasarisen in the family-based MSD projects, where we see thatteams need to better share technology, resources, and budget.Some team members are reluctant to assist fellow teams that arestruggling, even when the team has available personnel or re-sources to spare. They don’t see themselves as part of the biggerpicture without constant encouragement and reinforcement.

Teams are happiest when their project works. When proto-types are not fully functional, students are disappointed, as is theguide and customer. Everyone, including the Dean, wants thestudents to leave RIT thinking that MSD was a great experience.MSD provides a chance for students to make mistakes in a pro-tected environment where it won’t cost them their job, as it couldin industry. On the other hand, these projects are supported bygrants from sponsors, so real resources are being expended, oftenin multiple thousands of dollars, so expectations are high that ev-erything works! The family-based approach to MSD projects canbe a critical element of this perspective. Each project with withinthe family should be designed such that every team can demon-strate a minimal basic set of low-risk outcomes, even thoughthe results may represent only a small incremental improvementfrom the prior design. Conversely, a well designed project withinthe family should allow teams to move forward and make signif-icant innovative advances in their design. Defining the road mapof projects, and the sequence of accomplishments is critical to thesuccess of the family-based model of MSD. This is analogous tothe frustration that many engineers face in industry, when theybegin projects and invest effort, only to have the project cut offa short time later. When the engineer understands that every de-sign investigation contributes to the overall platform evolution,they begin to understand that even design studies which resultsin a negative outcome can be a positive contribution to the systemarchitecture.

Students developed much common engineering sense. Some

invaluable lessons were learned that will never be forgotten. Inone case, a mechanical engineering student on platform teamP08201 ordered a sprocket with the ID the same as the OD of theshaft it was to mount on, and was amazed that the two did not fittogether. This had a cascading effect on two teams. The resultingdelay caused the P08201 electronics and control groups to suf-fer since they had nothing to test their side of the project with.Eventually, P08201 motor modules were partially completed butwithout encoders present, so navigation mode was not testable.Later, they were able to test with the motor modules from RP1.Since the platform weight for RP10 was heavier, the RP1 motormodules that worked fine for the RP1 team, broke down underthe added weight. Set screws on the RP1 motor modules loos-ened up. It is unlikely that the mistake that caused all the troublewill ever be repeated again in the mechanical engineering stu-dents career.

RecommendationsProject family roadmaps should be developed in a manner

that allows students to apply experience from previous courses.This quarter, students chose the Freescale micro-controller forthe RP1 since they had used it in a previous course. This ispreferable to choosing a microcontroller they are not familiarwith, even if the specs may be superior. The learning curve istoo steep on a new controller for a quarter schedule. For wire-less communications, the RP1 team chose TelosB that faculty arecurrently using in their courses or research. At the same time, themodularity of design should foster innovation by the students –so they may begin with a subsystem that is low-risk and limitedin capability, but easily be able to migrate to a higher-risk, morecapable design variant. This modularity of design is an importanttake-away for the young engineer to take to their early design ca-reer.

When one project in a family (e.g. the RP10 Platform) re-lies upon the end product from another family (e.g.the RP10 mo-tor module), the platform team needs a contingency plan in theevent of a subsystem failure. Teams should always have a back-up vendor for COTS being ordered, and a back-up plan for asub-system, if it is non-functional. For example, a wireless com-munications team may tend to jump immediately to a wirelesssolution, rather than demonstrating a tethered communication so-lution as a first step towards wireless communications. Studentteams need to recognize the importance of a fall-back position, sothat debugging of incremental technologies can be accomplishedwithin a subsystem, and that platform design can proceed in ro-bust fashion, even if one particular subsystem fails to make sig-nificant advances from one generation to the next. Many studentteams jump to a complete design solution, rather than developingeach subsystem and testing it, prior to system integration.

Teams appreciate having a real customer who is waiting onthe results, and plans to use the product for future activities.

9 Copyright c© 2008 by ASME

Teams get frustrated when the customer changes their mind aboutdeliverables, but this reflects the marketplace, and is somethingstudents should experience early in their careers. Team mem-bers in the family of projects are motivated by the fact that theirend-result becomes the starting point for a subsequent team.

It is important that each student be responsible for deliver-ing something concrete at every weekly meeting with the guide.In MSD I, bench-testing during concept development and selec-tion of alternative concepts will help the team identify the trade-offs associated with each. In MSD II, students may be askedto demonstrate the current status of the functionality of the sub-system they are developing. Having a “down-payment” on thefull functionality, helps push the project ahead, even if it is abench-test demo. In large families of inter-related projects, in-experienced students may lose sight of how their individual taskin any given week contributes to the “big picture”, and they needregular guidance in that regard.

ACKNOWLEDGMENTThe authors acknowledge the contributions of the numerous

students, faculty, and staff who have worked on these projects,and recognize the financial support and contributions of timeprovided by the Gleason Foundation, Dresser-Rand Corporation,and RIT.

REFERENCES[1] Kenyon, J., Lomnick, J., Williamson, R., Fung, W., Barrault,

E., and Nguyen, H., 2007. Classroom homework assign-ment, design project management course. Fall Quarter 2007-08.

[2] Mackos, N., Bucci, A., LaLone, Z., Wilkinson, J., Garcia,L., Kaupa, M., Majka, D., and Anderson, M. “P07201: Selfcontained motor module for 10 kilogram payload roboticplatform”. In Multi-Disciplinary Engineering Design Con-ference, Vol. 2007, Kate Gleason College of Engineering,Rochester Institute of Technology.

[3] Rosa, S., Capra, V., Lee, D., Moazam, M., Saltarelli, R.,Collins, D., Lommick, J., and Hauenstein, E. “P07202:Rp100 motor module”. In Multi-Disciplinary EngineeringDesign Conference, Vol. 2007, Kate Gleason College of En-gineering, Rochester Institute of Technology.

[4] Gomez, A., Baker, J., Gill, J., Smith, B., Aclub, J., Verma,A., Harris, J., and Zheng, T. “P07205: Multi-purpose roboticplatform for a 100kg payload”. In Multi-Disciplinary Engi-neering Design Conference, Vol. 2007, Kate Gleason Col-lege of Engineering, Rochester Institute of Technology.

[5] Lester, D., Feuerstein, C., Schwec, M. J., Hillmon, J., Yuen,O., Ng, D., Yu-Chen, H., and Hirpa, D. “P08201: 10 kgpayload modular robotic platform”. In Multi-Disciplinary

Engineering Design Conference, Vol. 2008, Kate GleasonCollege of Engineering, Rochester Institute of Technology.

[6] Boyer, N., Lorenz, A., Krisher, J., Heitzenrater, G.,Chavoustie, C., Howell, B., Whitlock, B., and Wong,D. “P07204: 10kg robotics platform (rp10)”. In Multi-Disciplinary Engineering Design Conference, Vol. 2007,Kate Gleason College of Engineering, Rochester Institute ofTechnology.

[7] Williamson, R., Rodems, E., Ponikiewski, A., Maglaty, J.,Hayes, B., and Edwards, P. “P08205: Rp1 motor mod-ule, first generation, electrical design focus”. In Multi-Disciplinary Engineering Design Conference, Vol. 2008,Kate Gleason College of Engineering, Rochester Institute ofTechnology.

[8] Fung, W., Anderson, A., Benedict, M., Edick, J., andJimenez, B. “P08208: Rp1 motor module, first generation,mechanical design focus”. In Multi-Disciplinary Engineer-ing Design Conference, Vol. 2008, Kate Gleason College ofEngineering, Rochester Institute of Technology.

10 Copyright c© 2008 by ASME