P17316: Light Rail

Detailed Design

Table of Contents

For additional documentation see the Detailed Design Documents directory.

Team Vision for Detailed Design Phase

During this phase, the main goal for the team was solidifying proof of concept analysis and making design decisions in each of our three sub-teams. For the mechanical design, the team aimed to finish up feasibility analysis and testing, examine an actual cymbal stand, design brackets to attach the Light Rail components, and meet with a mechanical engineering faculty member. For the electrical design, the team wanted to select specific components and a power supply. The team also wanted to discuss options for user control with Dr. Edmunds. The software goals for this module were writing the C code that would allow the Raspberry Pi to control the LEDs.

Progress Report


Feasibility calculations have been performed for rail deflection and end point stability. A rail material has been selected. A maximum horizontal load for the cymbal stand has been determined experimentally. We learned that as it exists currently, the cymbal stand will not support the rail when subjected to horizontal forces over 6 newtons (1.3 lbs). We met with Dr. Landschoot regarding the modeling of the mechanical elements of the Light Rail.

By the end of the detailed design review, the mechanical team will have decided on and ordered components so we can begin building next semester. If necessary, we will have provided the machine shop with bracket designs so they can be created. We will put together drawings for the custom made parts of the design and gather the specs and images associated with the purchased parts of the design. Each of these tasks will be completed as a team by both the team’s mechanical engineers.

We have decided to use aluminum segments for the rail and cymbal stands for the end points. We have decided to reinforce the stability of the cymbal stands so that all configurations of height differences are stable. We have decided to bracket the Light Rail together with hinged brackets.

How much should we factor unexpected forces (someone bumping, laying a hand on the rail) into our analysis?


The general circuit has been designed and a preliminary circuit has been partially constructed for initial testing. Power calculations prove that components must be powered through a dedicated power source and cannot be powered by the microcontroller. The shift registers will function as needed using the microcontroller.

When the rest of the components are delivered, we will finish constructing the circuit including the LEDs, shift registers, resistors, BJTs, and wires. Ensure circuit functions as expected through various testing using oscilloscope and required hardware.

Components have been purchased including the microcontroller. A 5V/1A “wall wart” will be used as the primary power supply for components. The microcontroller will be powered separately using its own source.

We need to decide on how will be designing a thumb clicker with the mechanical group members. We also need to discuss possible choices for user peripherals with Dr. Edmunds but this will be done at the final design review at the end of the semester. Our only question to ask Dr. Amuso is: will we have any parasitic capacitance across the wires that will interfere with the signals?


The current goal is to create a piece of code that can update a signal out fast enough to meet the requirements e.g. If the LED lights are to simulate a 100mph baseball then each LED must be turned on/off 0.0137 seconds after the previous LED. At this point the program will be heavily designed using the library WiringPi. WiringPi already has functions with the ability to measure/delay time down to the microsecond.

Libraries compatible with the Raspberry Pi 3 m.B have been researched and installed on the Pi. (TimingPi)

LED Control: Preliminary ideas on how the code will send on/off information to the LEDs is to have a string of bits work its way through the circuit’s shift registers turning the lights on/off. LED timing will be determined (formula based / lookup based). A GUI will be designed. The timing stop with input signal will be determined.

The Raspberry Pi will be used as the microcontroller for the Light Rail. Python will be used as the language for the GUI and storage of results. C will be used as the language for everything actually controlling LEDs.

An issue that may arise is the effect of other native processes running on the Raspberry Pi delaying the execution of the commands controlling the LED. I am currently researching ways to set priority of the program high enough so that this will not be an issue. Simpler ways to mitigate the problem would be to turn off features that we won't be using (for now) such as wi-fi and bluetooth.

Prototyping, Engineering Analysis, Simulation

The team continued to prototype and conduct feasibility analysis for the detailed design phase. Below are the results of that analysis for each of the three sub-categories: Mechanical, Electrical, and Software.

Drawings, Schematics, Flow Charts, Simulations


public/Photo Gallery/DetailedDesign/mece1.PNG

Link to full document.

Full Structure Schematic

public/Photo Gallery/DetailedDesign/Structure1.JPG

Bracketing and Hardware

public/Photo Gallery/DetailedDesign/Structure2.JPG

public/Photo Gallery/DetailedDesign/Structure3.JPG

public/Photo Gallery/DetailedDesign/Structure4.JPG

public/Photo Gallery/DetailedDesign/Structure5.JPG

public/Photo Gallery/DetailedDesign/Structure6.JPG

Link to structure document.


1.public/Photo Gallery/DetailedDesign/DSC1592_web.jpg 2.public/Photo Gallery/DetailedDesign/lFP3y.jpg

Techniques for providing stress relief on the wires. The second technique will be used (still under discussion). Holes will be drilled into the project boards.

public/Photo Gallery/DetailedDesign/Matlab RL.jpg

Theoretical MATLAB graph showing that the experimental circuit will not experience any problematic time delays. This will be tested experimentally.

public/Photo Gallery/DetailedDesign/TEK0000.JPG

Oscilloscope capture showing that the experimental circuit will not experience any problematic time delays. The concern was that if the signal switches too quickly, the wire won’t have enough time to transmit the data and data may be lost.

public/Photo Gallery/DetailedDesign/tumblr_lujouwi46I1qf00w4.jpg

A 5V/4A wall wart will be used to power the system components. This does not include the microcontroller which has its own power supply.

public/Photo Gallery/DetailedDesign/Full Design.JPG

public/Photo Gallery/DetailedDesign/SingleSR.JPG

Link to full document. Link to single shift register design.

public/Photo Gallery/DetailedDesign/WireResistance.JPG

Wire Resistance and Capacitance Calculations

public/Photo Gallery/DetailedDesign/Power.JPG

Power Calculations

public/Photo Gallery/201701261207181000.jpg

When the hardware is placed within the cable manager it will have a cross section similar to this. With the components soldered together on a project board and a wire harness connecting the different modules together to form the light rail electrical components.


public/Detailed Design Documents/Software/code flowchart 1.3.jpg

Bill of Material (BOM)

public/Photo Gallery/DetailedDesign/BOMDD.JPG

New BOM here.

Test Plans

A majority of the test plans have remained unchanged from last phase.

Mechanical Test Plans

The following mechanical engineering requirements will be tested to the following specs after project completion.


To ensure the weight requirement for the finished product is met, the entire apparatus (Mechanical and Electrical Components) will be weighed using a scale after completion of the project. The product will be designed with weight in mind so the estimated weight of the final design will be below the maximum acceptable value of 50 lbs.

Stored Footprint

To ensure the product fits within the required storage footprint, the Light Rail will be disassembled into the storage state. The summation of maximum length, width, and height combination of the disassembled apparatus will be recorded. This value will create a single metric to compare to the engineering requirement.


The maximum load on the mechanical system will be determined. The worst case location for stress and cyclic loading will be analyzed to predict number of cycles until failure (fatigue analysis) and maximum acceptable loading (buckling analysis).

Height Range

The Light Rail vertical structure will be raised to it’s maximum operating height and this value will be measured and compared to the engineering requirement for height.

Ease of Setup/Teardown

The teardown and setup time for the Light Rail will be measured for 5 trials. The average of these times will be compared to the engineering requirement for ease of setup/teardown. The test can be repeated with people who have received written instructions for setup and teardown if it is deemed necessary by the design team.

Electrical Test Plans

The following electrical engineering requirements will be tested to the following specs after project completion.

Power Consumption

The Light Rail will be a low-power device. LED lights do not consume much power and the Raspberry Pi does not as well. The maximum power for a 120 Volt/15 Amp wall outlet is 1800 Watts but the Light Rail will not consume nearly that much power. The LED lights that we have chosen have a forward current of 20mA at 5V which is 0.1W per LED. Our design will use 40 lights so the lights will consume about 4 Watts of power. The 74HC595 shift register IC has a very low power consumption, 80-µA Max ICC. There is remaining power for the microcontroller as well as anything else electrical. At the moment, we are anticipating power consumption to be about 10 watts.

Speed Accuracy

The Light Rail will cover a wide range of speeds simulating speeds up to 90 MPH over a 15 foot range. Testing will be done to ensure that the lights are in fact moving to simulate up to 90 MPH with an acceptable error of 1 MPH faster or slower than the desired speed. Using the clock cycle from the microcontroller and the total number of LEDs (40), the total time can be calculated using the number of clock cycles required to have the 40 LEDs on. With the time, velocity can be calculated by finding the quotient of the total length (20 feet) and the time required to turn all 40 of the LEDs on. We will test perceived speed using a high speed camera to ensure accuracy of the Light Rail.

Max Error Allowed in Calculation

The Light Rail must be accurate down to the millisecond to represent real time as stated in the customer requirements. This will not be a problem as the technology can handle this quite easily. Testing trials will be performed to ensure that the microcontroller is accurate and consistent with the necessary timing down to the millisecond.

Software Test Plans

The following software engineering requirements will be tested to the following specs after project completion.

Max Error Allowed in Calculation (Code)

The Light Rail’s upper and lower boundaries for accuracy must be discovered and outlined. This will be done by setting the light speed to as low/high as possible for a test trial. The same process will be applied to the upper bounds. This ties into the engineering requirement ‘Max Error Allowed in Calculation’. Extensive testing will be done on the three desired/predetermined speeds requested by the customer to ensure accuracy.

Profile Storage

At least 1000 test user profiles will be made to ensure that the storage available is adequate for long term use. A user profile will also be exported to prove that concept.

Edge Case Times

Check for large range of results, meaning check that very early/late times are still accurate, i.e. 300 ms early, 50 ms early, 150 ms late etc.

GUI Verification

Go through the programs GUI and select each pre-determined option available to ensure that the program has no possibility from crashing or other unexpected functionality due to a valid input selections.

Design and Flowcharts

public/Photo Gallery/Light Rail Chart 1.1.jpg

Simplified Design Flowchart

public/Detailed Design Documents/Schematics/Functional Decomposition Diagram 1.4.jpg

Functional Decomposition

Risk Assessment

The project's risks have remained minimal for this phase. For the full document please click here.

public/Photo Gallery/RiskManagement2.PNG

Plans for next phase

Questions for Dr. Edmunds

The following are questions that we would like to discuss with our customer before the build and test phase begins next semester.

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation