Vanderbilt Senior Design Project:
FSAE INSTRUMENTATION
Semester 1 Report
System Overview .......................................................................................................... 3
Overview of Formula SAE ........................................................................................... 3
The FSAE Car ............................................................................................................... 4
Stakeholder Identification ............................................................................................ 5
Operational Concept ..................................................................................................... 5
Budgetary Concerns ..................................................................................................... 6
System Context .............................................................................................................. 6
System Requirements ................................................................................................. 7
Measurable System Requirements .............................................................................. 7
Required: .................................................................................................................... 7
Optional: ..................................................................................................................... 9
Data Logging ................................................................................................................. 9
Environmental System Requirements....................................................................... 10
Operational Requirements ......................................................................................... 11
Graphical User Interface ............................................................................................ 12
Discussion of Options ............................................................................................... 15
MoTec Data Acquisition System................................................................................ 15
AIM Sports Data Acquisition System ....................................................................... 16
National Instruments cRIO ........................................................................................ 16
System Definition ....................................................................................................... 18
Analysis of Option Choice .......................................................................................... 18
Operational Definition ................................................................................................ 18
Methods of Measurement .........................................Error! Bookmark not defined.
System Diagrams .......................................................Error! Bookmark not defined.
cRIO Programming................................................................................................. 18
Component Definition ................................................................................................ 19
Instantiated Sensor List ........................................................................................... 19
cRIO Module Selection ............................................................................................ 19
Verification and Validation of System Design ......................................................... 19
System Overview
Overview of Formula SAE
Formula SAE is a student design competition sponsored by the Society of
Automotive Engineers. Starting in 1979 as an annual event hosted in Michigan, the event
has grown into an international series, sponsoring competitions in 8 competitions in 5
countries around the world. Despite event growth, the event in Michigan remains the
most competitive event in the world, drawing over 120 teams from around the world.
This year, event registration filled up all 120 available entries in less than 10 minutes.
The Formula SAE competition is split into two major sections. The first section,
called the static events, is comprised of the cost analysis, business presentation, and
design event. The cost analysis requires teams to document and report a full cost makeup
for the prototype vehicle brought to competition. This includes discussion of
manufacturing techniques, assembly labor and purchased components cost. The business
presentation requires teams to develop and present a business plan to a group of potential
investors, explaining mass manufacturing plans, marketing strategies, and financial
expectations. The design presentation requires teams to present the design and
engineering from which the vehicle was designed. This includes discussion of modeling
and simulation, as well as testing and validation. A critical part of the validation of the
engineering behind the vehicle will come through the addition of data collected by an
instrumentation system.
Each event in the competition is given a different weight, shown for the static
events in figure-1.
Figure-1. Static Events Weights
The SAE event is scored out of a total possible 1000 points between the static and
dynamic events. As it can be seen in figure-1, the static events only comprise a total 325
points in the competition, and the design part of those points has the highest weight.
The dynamic events included in the FSAE event are comprised of the acceleration
event, the skidpad event, the autocross event, a fuel economy competition and the
endurance event. The acceleration event is a drag run designed to test the straight line
acceleration of the car. The skidpad event is designed to test the cornering ability of the
car. The autocross is a single lap run with varying radius corners and straights of varying
length. The fuel economy event is run in conjunction with the endurance event and tests
the fuel consumption rate of the car. The endurance event runs on a similar course to the
autocross event, however the track is lengthened and the cars run for a half hour on
average. This tests the durability of the car and also is the place where a majority of
teams lose points as the rate of teams which complete the event is usually under 40%.
The dynamic events are also assigned point values, shown against the 1000 point
total in figure-2.
Cost & Mfg.
Presentation
350
Design
Acceleration
Skid Pad
Autocross
75
50
Fuel Economy
150
50
Endurance
Figure-2. Dynamic Events Weights
It can be seen by the above chart that the endurance event carries a majority of the total
available points in the competition. It can also be seen that the dynamic events as a group
comprise 675 out of the total 1000 points. This shows that the performance of the car is a
major factor in the overall performance of the team at competition.
The FSAE Car
FSAE cars are required to be compliant with a fairly loose set of restrictions
which form the Formula SAE Rules. Major restrictions include:
- a 20 mm restrictor in the intake manifold, decreasing overall engine output power
- a 610 cc engine displacement limit, causing many teams to use motorcycle engines
- independent four wheel suspension
- structural safety requirements, which keep the students who design and build the cars
safe while they are driving them
Stakeholder Identification
Stakeholders for the project are separated into 5 major groups: FSAE Design
Team, FSAE Competition Team, Data Analysis Team, FSAE Cost Team, and the Senior
Design Team.
FSAE Design Team – This stakeholder represents the Vanderbilt FSAE student members
who participate in the design of the car. As the design of the car is an iterative process
which allows the team to build on and perfect designs implemented in previous years
cars, quantitative data is needed by this group so that more informed and effective design
decisions can be made from year to year. Quantitative measurements of the cars
performance are also useful for validation of design decisions and are an essential part of
improving performance in the design event at competition.
FSAE Competition Team – This stakeholder represents the Vanderbilt FSAE student
members who prepare the car and drivers for the dynamic events at the FSAE
competition. As the dynamic events such a highly weighted part of the competition,
maximizing the performance of the car and its drivers is a very important part of
preparation for competition. The ability to collect data which will allow the car to be
quantitatively tuned is a very important requirement for this group.
Data Analysis Team – This stakeholder represents the individuals who will be directly
interacting with the system through the user interface. These users require an interface
which is easy to use and is simple enough that it can be used by a variety of users on the
FSAE team.
FSAE Cost Team – There are specific requirements which allow the system to not be
considered in the overall cost metric of the car. This stakeholder requires that those
requirements are met so that the cost analysis of the car will not be affected.
Senior Design Team – This stakeholder represents the individuals who will be designing,
constructing and implementing the data acquisition system. So that the system can be
effectively developed and implement within the time constraints of the academic
calendar, they drive requirements limited scope and ease of completion.
Definition of Problem
Currently, there are no quantitative performance measurements which are
available for validation or performance development. All performance feedback comes
through driver feedback, which extremely limits the performance tuning abilities of the
team.
Operational Concept
The end result of this project is to develop a data acquisition (DAQ) system which
can be implemented onto any Formula SAE car operating in varying weather conditions,
which will measure a variety of channels through a network of commercial sensors. The
sensors will be connected to a device which will read the sensor outputs, convert the
outputs to digital signals, and then process and store the signals. The system will have
some method which will allow the data to be downloaded to a personal computer. As a
part of the system, a graphical interface will be developed which will allow the data to be
further manipulated and analyzed by the user.
Budgetary Concerns
Some consideration within the system design process must be made to system
cost. Although cost will not be included in the cost analysis of the vehicle itself, the
FSAE team operates on a limited budget of roughly $25,000 a year. It is thus necessary to
balance system performance and cost, and to develop a system which is cost effective, yet
durable and reliable, so that it can be developed and utilized by future years’ teams.
System Context
There are a variety of context variables which affect the DAQ system. These have
been separated into two major categories. First are context variables. These variables,
including the car itself and the way in which the car will be operated, are variables which
drive the operational requirements and performance requirements of the car.
The other set of context variables identified for the DAQ system were defined as
environmental context variables. These included electro-magnetic interference, vibration,
and local heat sources encountered within the operating environment of the system (on
the car). Other environmental variables defined included the weather based environments
incurred through system operation, including rain, cold and hot ambient temperature
environments.
System Requirements
Measurable System Requirements
As in any data acquisition environment there are many signals that could
potentially be measured. Thus, we divide the potentially measurable signals into three
categories: required, optional, and extraneous. The signals and measurements laid out
under the required category are those that will contribute most to improving and
validating vehicle performance. They constitute the true measurable requirements of this
project and will be the primary focus of our efforts. Those items falling under the
optional category will be pursued only if the project runs considerably ahead of schedule
and far enough under budget to justify the added costs. It is noted that these items could
potentially be the focus of any subsequent follow up projects. Lastly, we note that the
measurables that fall under the final, extraneous, category do not add any information
regarding vehicle performance or validation and would only be monitored out of
convenience. Table-1 lays out the measurable signals into their respective categories, an
in depth discussion of the signals in the first two categories follows.
REQUIRED
OPTIONAL
EXTRANEOUS
Shock Position & Velocity*
Lateral & Longitudinal Accel.
Wheel Speed*
Engine RPM
Oil Pressure
Throttle Position
Steering Position
Brake Pressure
Tire Temperature
Ambient Temperature
Water Temperature
Exhaust Temperature
Oil Temperature
Wheel Load
Fuel Level
Fuel Consumption Rate*
Oil Level
Coolant Level
Tire Pressure
Ride Height
Chassis Slip Angle
Table-1. – Measurables
*-- indicates derived measurements
Required:
Shock Position/Velocity – Is fundamentally a measure of shock position as a function of
time. Four are needed, one for each shock. A linear potentiometer can be used to can be
used to measure the expansion and contraction of an 8” shock. Data obtained shows how
the car’s suspension reacts especially while cornering. It was decided that the resolution
should be 400 Hz which is equivalent to every about 3 inches on the track. The
potentiometer’s range needs to be 2.5” max distance with a maximum velocity of
400mm/sec. 4 channels will be required with a bit resolution of 16 and a bit rate of 3200
bytes/sec. To record 60 min of data 10.99 MB’s of memory will be needed for all 4
shocks.
Latitudinal and Longitudinal Acceleration - Is a measure of the car’s acceleration. A
dual or tri axial accelerometer can be used to measure both accelerations. Data obtained
shows the amount of acceleration both laterally and forward/backward that the car
experiences while racing. The data can be used to compare how hard two different
drivers can push a car in a corner or how quick they get on the throttle. It was decided
that the resolution should be 200 Hz which is equivalent to every about 6 inches on the
track. The accelerometer’s range needs to be +/- 4g. 2 channels will be required with a
bit resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of data 2.75 MB’s
of memory will be needed.
Wheel Speed – Is a measure of how fast the car’s wheels are spinning, i.e. how fast the
car is going. A Proximity or Hall Effect sensor can be used to measure wheel speed.
Two wheels, one front one back will be measured and averaged in order to determine the
car’s speed. It was decided that the resolution should be 200 Hz which is equivalent to
every about 6 inches on the track. The sensor’s range needs to be able to handle up to 60
rpm. 2 channels will be required with a bit resolution of 16 and a bit rate of 800
bytes/sec. To record 60 min of data 2.75 MB’s of memory will be needed.
Engine RPM – Is a measure of how many RPMs the engine is turning. This can be
measured directly from the current Honda CRB600F4 motorcycle engine. It was decided
that the resolution should be 200 Hz which is equivalent to every about 6 inches on the
track. The range needs to be from 0 to 13,000 RPM. 1 channel will be required with a
bit resolution of 16 and a bit rate of 400 bytes/sec. To record 60 min of data 1.37 MB’s
of memory will be needed.
Oil Pressure – Is a measure of the pressure in the engine where the oil is located. A
pressure transducer will be used to measure oil pressure. Oil pressure is extremely
important to measure in the SAE engine in particular because it is a motorcycle engine.
Because it is a motorcycle engine, it is designed to operate while tilting side to side;
keeping it flat when cornering like in the SAE car may negatively affect the oil pressure
in the engine. It was decided that the resolution should be 20 Hz which is equivalent to
every about 60 inches on the track. The oil transducer needs a minimum range of 0 to
150 psi. 1 channel will be required with a bit resolution of 16 and a bit rate of 40
bytes/sec. To record 60 min of data 0.14 MB’s of memory will be needed.
Throttle Position – Is a measure of the position of the throttle. A rotary or string
potentiometer can be used to measure the throttle position. It was decided that the
resolution should be 200 Hz which is equivalent to every about 6 inches on the track.
The potentiometer needs a minimum range 100 degrees. 1 channel will be required with
a bit resolution of 16 and a bit rate of 400 bytes/sec. To record 60 min of data 1.37 MB’s
of memory will be needed.
Steering Position – Is a measure of the position of the steering wheel as the driver turns
it. A rotary or string potentiometer can also be used to measure the steering position.
Data collected can be used to determine oversteer and understeer in the car. It was
decided that the resolution should be 400 Hz which is equivalent to every about 3 inches
on the track. The potentiometer needs a minimum range 540 degrees. 1 channel will be
required with a bit resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of
data 2.75 MB’s of memory will be needed.
Brake Pressure – Is a measure of the pressure in the break lines when the breaks are
applied. A pressure transducer can be used to measure the pressure in the break line.
Data collected can be used to determine an optimal front-to-rear break ratio to optimize
traction while cornering. It was decided that the resolution should be 200 Hz which is
equivalent to every about 6 inches on the track. The pressure transducer needs a range
from 0 to 2500 psi.. 1 or 2 channels will be required (to be determined) with a bit
resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of data 2.75 MB’s of
memory will be needed (for 2 transducers).
*Note: At this time the team has deemed only the Required measurements are necessary
and will not proceed with Optional, or Extraneous during the project.
Optional:
Tire, Ambient, Water Temperature – Is a measure of the temperature in the tires, outside
air, and water in the engine. An IR Thermocouple with a range from 50 to 250 degrees F
can be used. This data can be recorded with fair accuracy by measuring it manually
during pit stops.
Exhaust and Oil Temperature - Is a measure of the temperature out the exhaust pipe and
oil in the engine. An IR Thermocouple with a range from 0 to 1000 degrees F can be
used.
Wheel Load – Is a measure of the force applied to the wheels. A strain gauge can be used
to measure wheel load. Wheel load is especially important in cornering as excessive or
unbalanced loads can lead to uneven tire wear and poor traction.
Data Logging
Based upon the signals we wish to monitor, there are several system requirements
relating to data acquisition that we must define. These include bit resolution, sampling
rate, and storage capacity. In order to obtain a consistent and high precision in our
measurements, we choose a 16-bit resolution. The sampling rates are derived based upon
analyzing the desired positional granularity of measurements on track. For example, if
we want oil pressure measurements at every five-feet on track (at top speed), then we can
determine what the sampling rate must be for the oil pressure channel must be to obtain
this level of on track granularity. The table below computes these sampling rates based
upon desired granularity. Referring to data logging literature as well as conferring with
our project advisor confirms the selected sampling rates. Table-2 overviews the desired
granularity on track, sampling rate, and expected dynamic range for each sensor. Note:
top speed assumed to be 100 ft/sec.
Measured
Signal
Shock Position/Velocity
Lat./Long. Accel
Wheel Speed
Engine RPM
Oil Pressure
Throttle Position
Steering Position
Brake Pressure
Resolution
On track (in)
3
6
6
6
60
6
3
6
Sampling
(Samples/Sec)
400
200
200
200
20
200
400
200
Dynamic Range
2.5";Vmax = 400mm/sec
+/- 4g
60 rpm max
0-13,000 rpm
0-150 psi
100 degree range
540 degree range
0-12500 psi
Table-2. – Sampling Rates and Dynamic Range Requirements
An extended version of the above table, including number of channels and the
calculation deriving the data storage requirement, can be found in the appendix. The
calculation shows that our system will require 25MB of data capacity in order to store
sixty-minutes of logged data.
Environmental System Requirements
Now that we have determined all the requirements that we want to measure, we
must determine the requirements of the system based on the environment that it will be
operating in. Since the data acquisition system will be operating on the Formula SAE car,
most of these requirements are based on the external forces that can affect both the car
and the data acquisition system (DAQ).
Electromagnetic Interference (EMI): A motor vehicle inherently has a large amount of
electromagnetic interference, due to the combination of the engine and all other
electronic systems required for the operation of the car. At this time, the actual amount of
EMI is not easily quantifiable. However, the data acquisition system must be capable of
operating under conditions with a large amount of EMI, along the lines of other industrystandard automotive applications. To accomplish this, either the DAQ itself must be
immune to such interference, or a suitable shield must be built around it to minimize the
amount of interference. This applies to not only the DAQ system, but the whole wiring
system as well (i.e. cables must be electronically shielded).
Water Exposure: The FSAE car may be operated in a variety of weather conditions,
including rain. Since the car has an open body and is so close to the road, water may
inevitably splash up and come in contact with various parts of the car, including the
DAQ. As a result, the whole DAQ system (including all cabling and connections) must
be suitably waterproof. If this is not possible, the DAQ must be placed in a location
and/or enclosure that prevents any water exposure.
Vibration: All parts of the car being built must be suitably durable to withstand all sorts
of constant vibration. The DAQ is not excluded from this requirement. Vibrations
encountered may include not only major bumps that may be along the track, but also
constant shaking simply due to road noise and vibrations of the car.
Temperature: The DAQ will be submitted to a wide range of temperatures. This includes
not only a wide range of external ambient temperatures (40-90 degrees F), but also local
heat sources in the car well in excess of 100 F.
Weight: The weight of the FSAE car is an important characteristic that can potentially
have a profound effect on the performance of the vehicle. To minimize the possible
negative effects, it has been decided that the total weight of the entire DAQ system not
exceed 20 pounds.
Physical Size: Based on an analysis of the previous year's FSAE car design, it has been
determined that the optimal location for the DAQ system will be right in front of the
driver, underneath his/her bent legs while in the seated driving position. This location
prevents an uneven weight load because it is along the centerline of the car, and with a
proper enclosure, should not be accidentally dislodged by the driver during a normal test
run or competition. This space can accommodate a DAQ system with a maximum size of
10"x12"x5".
Other: A few other minor forces may exist that can adversely affect the performance of
the data acquisition system. The system must be designed in such a way that the impact
of these extraneous forces be minimized. For example, the location of the DAQ when
mounted on the car must be chosen properly so as to minimize any air resistance, as well
as prevent the driver from accidentally dislodging the system or any connections.
Similarly, the whole wiring harness system must be mounted properly to withstand all
normal operating conditions in addition to being out of the way when the driver is
entering, exiting, and operating the vehicle.
The FSAE car is a motor vehicle operated in an outdoor environment and as such is
subject to a wide barrage of external forces including electromagnetic, acts of nature, and
the physical surface of asphalt. The car itself is designed and built to be able to withstand
such an onslaught; the data acquisition system must be able to do the same. Not only
must the DAQ survive taking such a beating, it must be able to continuously log and
relay real-time data during the whole process without skipping a beat.
Operational Requirements
Triggering: The system must have a manual triggering mechanism if the system memory
limit is less than the minimum requirement in order to collect the most important data
that occurs after the vehicle warms up. However, if there is ample system memory the
triggering should be automatic, so that the data collected has a buffer between warm up
operation and prime operation.
Filtering: As in any data acquisition environment, some form of filtering must be
implemented in order to maintain a high level of precision. Our system shall contain low
pass filters to remove high frequency noise and distortions from our signals. The actual
form of the filter depends on the exact signal and the sampling rate being filtered. The
passband of each low pass filter should extend up to half the signal sampling rate. Note:
some sensors may already include sufficient backend filtering. Typical low pass filter
implementation can be wired with a resistor and capacitor.
Data Transfer: As far as data transfer is concerned, the data collected from the racecar
must be uploaded to a computer for analysis and interpretation. This transfer must be
done by using the ports of Universal Serial Bus (USB) or Ethernet Cable (Category 5e).
The aforementioned data must be stored within the system for the duration of testing.
Based on standard FSAE testing, a minimum of 40 minutes will be required in order to
collect sufficient data.
SAE Compliance: To exclude the cost of the system from the FSAE competition report,
the entire instrumentation system must conform to the SAE stand-alone rules. According
to the FSAE competition guidelines, the stand-alone data acquisition system must only
monitor and record the vehicle data during operation. This system must not have a
control or display function that would interact with the driver. Lastly, the entire system
must be removable without affecting the performance of the vehicle in any way.
Final Display: For the Graphical User Interface (GUI) the system requires accessibility,
filtering, various math channels, a visual display, and specific data collection rates which
are detailed in the Appendix. For accessibility, the GUI must have standard graphing
tools that have the ability to transpose multiple data sets. Moreover, the interface of the
data sets must have multiple speed playback ability so as to precisely focus or zoom into
a particular section. The only filter requirement for the types of data that will be
collected is the Fast Fourier Transform (FFT). For math channels, the interface must
have transform and analog function capabilities. As far as the Visual Display is
concerned, the goal is to have the interface with various options to represent data by
graphs, gauge levels, scatter plots, channel history, FFT output, channel reports, and
section times with the adaptability of real-time playback.
Graphical User Interface Requirements
The Graphical User Interface (GUI) for VU FSAE Instrumentation is a vital part
of the project because the raw data collected from the sensors are useless unless they are
converted to a format that is readable and useful to the user. These data are Shock
Position/Rate, Latitudinal or Longitudinal Acceleration, Wheel Speed, Engine RPM, Oil
and Brake Pressure, Throttle Position and Steering Position. Below is an example of how
the datasets can be displayed for various channels:
Figure-3. Signal Channels and Analysis*
Figure 1, above, shows the Speed (mph) of the car followed by the Throttle position,
Brake Pedal, Gear and Engine RPM. (*MoTec Systems USA, http://www.motec.com/)
The speed graph shows how fast the car is traveling and whether it is accelerating
or decelerating. The peaks show the fastest point on each straight while the troughs are
the slowest point at each corner/run.
The throttle position shows what the drive is doing at specific time. The aim of
this graph is to help the user (driver) to be always either accelerating or braking in order
to achieve the quickest lap time.
The Brake Pedal Position trace will be replaced with Brake Pressure Developed.
This shows when the brake is being applied. 100% means the brake is fully applied while
0% means no brake is being used. This trace is often used alongside the wheel speed
traces to make sure the car is slowing as quickly as possible with no brake lock ups.
The Engine RPM trace shows how fast the engine is revving and how well the
driver’s gear choice matches the demands of the circuit. The first gear ratio should be low
enough to drive well out of the slowest gear on the circuit while the final gear ratio
should see it reaching max rpm at the end of the longest straight.
In addition to the graph representations of the data, the user also requires that the
data be represented in a way that a regular car driver would see them. A virtual dashboard
that displays all the information required will be created. An example of a virtual
dashboard supplied by the maker of the racing game GTR2 is displayed in figure 2,
below:
Figure-4. Virtual Dashboard and Playback Display*
This provides a real time representation of what happens over the lap. It’s useful for
giving an overview and can provide an insight into the cars responses. (*MoTec Systems
USA, http://www.motec.com/)
The steering in the middle of the virtual dashboard simulates the actual steering
during the entire course of the race in real-time. The data that are read from the rotary or
string potentiometer on the steering are translated here so that the user can determine
oversteer or understeer when it happens.
The virtual dashboard must also have four horizontal bars that reflect the data
collected from the linear potentiometer attached to each of the four shocks. Data from
shocks on the left side of the car will be placed on the left side while data from the right
shocks on the right side. Front and rear shock position data are distinguished by putting
the bars in top and bottom arrangement. Below is an example of how they could be
positioned on the virtual dashboard.
Figure-5. Possible shock representation
Discussion of Options
There are about 10 to 20 major manufactures of data acquisition systems that have
products that could be appropriate for Formula SAE racecar data acquisition. Of those
companies, MoTec and AIM Sports offer the best turnkey systems in the industry in
terms of performance and price. The final option we will discuss is using the National
Instruments cRIO platform.
MoTec Data Acquisition System
MoTec is one of the leading manufacturers of Engine Management and data
acquisition systems for performance racing around the world. In order to use MoTec
hardware and software for data acquisition, the following complete package would need
to be ordered. M4 ECU with Advanced Tuning & Logging (See picture in Appendix I),
MoTec SDL Data Logger, M4 10 foot unterminated Harness, Clockwise rotation Throttle
Sensor, Harness Termination Kit, Communications Cable, USB Communications cable,
MoTec Data Analysis Software, and a 1000 Channel Beacon Receiver. Additionally all
sensors would need to be purchased and of MoTec brand.
There are many advantages of using the MoTec system. The system is an easy to
install and use. The hardware and software equipment has been proven based on its high
use in the motor sports world. Additionally the graphical user interface that works with
the MoTec hardware/sensors is extremely user friendly and high quality (See picture
appendix II). Furthermore, ordering the system from a major company like MoTec
provides product support incase of failure or troubleshooting.
The two primary disadvantages of this system are its price and system constraints.
The price of the entire MoTec data acquisition system including an ECU is $5059.59.
That is before the purchasing of sensors (Christiansen). This is out of the SAE/Senior
Design team’s budget. Furthermore the MoTec system would require the purchasing of
only MoTec sensors which are inflated in price by 25% to 150% over competitors, likely
another $2,000 to $3,000. Another drawback is that the code used to interpret data in
MoTec software is proprietary. This creates a problem because if the team ever wanted
to record and interpret data from a sensor not supported by MoTec it would not be
possible. Although the MoTec system is great in terms of performance, its price is a
major deterrent making it obsolete as an option for a Data Acquisition System. The
system is of very high quality in both design and performance. The team will likely
attempt to mimic certain aspects of this well designed system with whatever design is
chosen.
AIM Sports Data Acquisition System
AIM Sports also offer data acquisition systems similar to MoTec. DaVid is the
video and data logging system for race cars offered by AIM (AIM Sports). The AIM
system is very similar to the MoTec system both in terms of hardware and software. See
AIM specs in Appendix III. The AIM system is slightly cheaper than MoTec starting at
$2000; it does not include an ECU (ranging form $500 to $10,000) or sensors (AIM
Sports). The same problem that affected the MoTec system where that the software’s
code cannot be modified to support additional sensors and data input also is a problem for
the AIM software. The AIM system is better than the MoTec system in that a broader set
of less expensive sensors can be used, but its overall performance and user interface and
performance appears to be worse. Although the AIM data acquisition system is slightly
better than the MoTec system in terms of price, it is still far too expensive costing at least
$2500 more than other alternatives.
National Instruments cRIO
National Instruments provides a wide range of products in the data acquisition
system market. Of these, the NI CompactRIO (cRIO) is the most suitable to operating in
a harsh yet mobile environment.
The cRIO (in combination with National Instruments' LabVIEW software suite) is
a very capable data logging and analysis system. The cRIO-9012, in combination with
the cRIO-9103, has a 400MHz internal processor, 64 MB of DRAM (and 128 MB of
internal storage), and 4 modular slots of input & output. There are (at least) two modules
that are applicable to the applications in this project: the NI 9205 has 32 channels at 16
bits resolution with up to 250,000 samples per second, and the NI 9215 has 4 additional
channels at 16 bits resolution and up to 100,000 samples per second per channel. With
both of these modules loaded into the chassis, the total system weighs 3.082 pounds and
measures approximately 7"x4.5"x3.5". The cRIO supports both Ethernet and USB
connections for to integrate with the LabVIEW software on a computer. In terms of
durability, the cRIO system is rated to withstand temperatures from -40 to 148 degrees F,
and shock up to 50g.
Using the National Instruments cRIO system has several distinct advantages. First
of all, unlike the other two DAQ choices, the choice of sensors is very open and not
limited by the National Instruments system. Not only does this allow for more options in
terms of the type of sensors used, it allows for sensors of different brands to be
purchased, possibly decreasing costs. Besides reducing sensor cost, using the cRIO
system is essentially free for the senior design group. Not only is the cRIO already in our
possession (donated by NI), Vanderbilt also has a site license to the LabVIEW software
suite, making it free of charge to the senior design team. Going along with this,
Vanderbilt also has many contacts with National Instruments, ensuring that technical
support will always be accessible and assisting. In addition to being a low-cost solution,
the modular design of the cRIO allows the system to be interchangeable and expandable.
If in the future it is decided that components or requirements need to be changed, added,
or removed, the whole system does not need to be scrapped – instead, modifications just
need to be made to the LabVIEW FPGA code.
There are two possible disadvantages that come up when discussing the NI cRIO.
First, since it is not a turnkey system, installing and managing the hardware (and
software) will require more troubleshooting. Similarly, LabVIEW is reputed to be a
complicated development environment with a steep learning curve. However, with a
plethora of technical support in a wide variety of forms available, these obstacles will
surely be overcome.
System Definition
Analysis of Option Choice
Every aspect of all three system options was carefully considered. After an analysis of all
advantages and disadvantages and the system requirements, the senior design team
elected to use the National Instruments CompactRIO system. In addition to the major cost
benefits of using the cRIO and LabVIEW, table-3 below demonstrates how the NI system
(cRIO-9103 in combination with NI-9205 & NI-9215 modules) meets or exceeds all the
system requirements.
Category
Sampling Rate
# Channels
Memory
Data Transfer
Operating Temp.
Shock/vibration
Weight
Physical Size
Requirement
~3.5k Samples/sec
14
25MB
0.4 MB/s
20 – 105 F
automotive industry standard
<20 lbs
10"x12"x5" max
Capability
650k Samples/sec
36
64MB DRAM
USB: 1.5 MB/s
-40 – 148 F
50g
3.082 lbs
7"x4.5"x3.5"
Table-3. Requirements vs. Capabilities
Operational Definition
LabVIEW FPGA
The programming platform of LabVIEW FPGA (Field-programmable Gate Array) and
the cRIO is the perfect combination for the system. The most important advantage is that
the technology allows for custom hardware alterations when the testing requirements
change in order to avoid having to build new hardware. The LabVIEW FPGA allows the
creation of custom Input/Outputs (I/O) and control hardware using the easy-to-use
graphical development. Furthermore, LabVIEW FPGA has built-in interface functions
that integrate the cRIO hardware onto the Windows environment.
Figure-7.
cRIO Programming
Component Definition
Instantiated Sensor List
After careful review and product comparisons, sensors were selected. Quality, price,
durability, and ease of installation in that order were the primary factors considered in
choosing between sensors.
Measurement
Sensor
Brand
Part Number
Cost
Shock Position/Rate
Rotary Potentiometer
P3
MP20IP
Latitudinal and
Longitudinal Acceleration
Accelerometer
Crossbow
GP Series tri axis
Wheel Speed
Proximity Sensor
Omega
PRX-102-8n
Engine RPM
Direct
**Data can be taken directly from engine - Honda
CBR600F4
Oil Pressure
Pressure Transducer
Omega
PX32B1-250GV
Throttle Position
Rotary or String Pot
Steering Position
Break Pressure
Rotary or String Pot
Pressure Transducer
Omega
PX305-3KGI
$315
$85
Already own
Table-4. Instantiated Sensor List
Note: Sensors for ‘Optional’ and ‘Extraneous’ measurement items were not selected
because the team decided not to proceed with those measurements. Note however that
the Omega OS36-2-J-80F IR Thermocouple is recommended for tire and ambient air
‘Optional’ measurements.
cRIO Module Selection
Verification and Validation of System Design
$285
APPENDIX
A.1 – Data Logging Requirement
A.2 – NI - cRIO Industrial & Environmental Certifications