g-cart autonomous navigation and...
TRANSCRIPT
G-CART Autonomous
Navigation and Controls
Senior Design Team 05107
Critical Design Report
Project 05107
Darren Rowen EE (Team Lead)
Scott Glover EE
SatSat Fox EE
Chaichat Boonyarat EE
Delwin Guiao EE
Derick Call ME
Luan Nguyen EE
1 RECOGNIZE AND QUANTIFY NEEDS............................................................................51.1 Mission Statement...........................................................................................................51.2 Project Description..........................................................................................................51.3 Scope Limitations............................................................................................................61.4 Stakeholders.....................................................................................................................81.5 Key Business Goals.........................................................................................................81.6 Primary Market................................................................................................................81.7 Secondary Market............................................................................................................91.8 Innovation Opportunities.................................................................................................91.9 Background Research......................................................................................................91.10 Formal Statement of Work............................................................................................10
2 CONCEPT DEVELOPMENT............................................................................................112.1 Subgroup........................................................................................................................122.2 Bus Architecture Concepts............................................................................................152.3 Steering Concepts..........................................................................................................222.4 Velocity Control Concepts............................................................................................272.5 Emergency Brake Concepts...........................................................................................36
3 FEASIBILITY........................................................................................................................393.1 Bus Architecture Feasibility..........................................................................................403.2 Steering Feasibility........................................................................................................413.3 Speed Control Feasibility..............................................................................................433.4 Feasibility Conclusion...................................................................................................46
4 OBJECTIVES & SPECIFICATIONS................................................................................474.1 Design Objectives.......................................................................................................484.2 Performance Specifications.......................................................................................484.3 Safety Issues...............................................................................................................50
5 Final Design.........................................................................................................................555.1 Steering Design and Simulation....................................................................................555.2 Speed Control Design and Simulation...........................................................................625.3 PID Controller Design...................................................................................................665.4 Communication Protocol...............................................................................................695.5 Testing and Integration..................................................................................................715.6 Budget............................................................................................................................74
6 CONCLUSION.....................................................................................................................757 REFERENCES....................................................................................................................768 APPENDIX...........................................................................................................................77
8.1 Software Charts.............................................................................................................778.2 LabVIEW Screenshots...................................................................................................80
Index of Figures
Figure 5.1: Steering Control System.............................................................................................56Figure 5.2: System Block Diagram...............................................................................................58Figure 5.3: PWM Signals..............................................................................................................58Figure 5.4: PWM % duty cycle vs. output voltage........................................................................59Figure 5.5: Victor 883 technical drawing......................................................................................60Figure 5.6: US Digital Optical Quadrature Encoder.....................................................................60Figure 5.7: X1 Encoding Waveform Diagram..............................................................................61Figure 5.8: X2 Encoding Waveform Diagram..............................................................................61Figure 5.9: X4 Encoding Waveform Diagram..............................................................................61Figure 5.10: Vehicle Velocity Encoder Mount and Assembly......................................................63Figure 5.11: Braking Motor Mount with Position Encoder...........................................................64Figure 5.12: Throttle Motor Encoder Mounting and Assembly....................................................64Figure 5.13: Velocity Control System...........................................................................................65Figure 5.14: Brake Control System...............................................................................................66Figure 5.15: The measured throttle motor step response when installed in the vehicle................68Figure 5.16: The measured brake motor step response when installed in the vehicle...................69Figure 8.1: Motion Control Input/Output......................................................................................77Figure 8.2: UDP Discovery Process..............................................................................................78Figure 8.3: TCP Communication Read.........................................................................................78Figure 8.4: TCP Communication Write.........................................................................................79Figure 8.5: Servo Loop..................................................................................................................79Figure 8.6: Hardware Block Diagram...........................................................................................80Figure 8.7: LabVIEW Front Panel.................................................................................................81Figure 8.8: PXI Control Code........................................................................................................81Figure 8.9: Throttle Control Front Panel.......................................................................................82Figure 8.10: Throttle Control Code...............................................................................................83
1 RECOGNIZE AND QUANTIFY NEEDS1.1 Mission Statement
The primary goal of the G-CART senior design team was to design a robust modular
control system with bidirectional communication ability, to direct a vehicle’s steering and
velocity.
1.2 Project Description
Complete a 175 mile all terrain course in less than 10 hours.
Have to avoid a variety of obstacles while staying with the G.P.S boundaries
Output Controls:
Steering direction
Vehicle stop
Speed condition
Throttle position for speed control
Brake position for speed control
Speed override (to shut the vehicle down as fast as possible).
Error with respect to desired speed
Error with respect to desired steering position
Measured vehicle speed (to guidance system).
System Inputs:
Kill switch (if any problems arise)
Current throttle encoder position
Current brake encoder position
Desired speed (velocity variation 0x0000-0xFFFF), incremental values spanning the
vehicles desired velocity capability (i.e. 0 to 64 kph)
Current steering encoder position
Desired steering position (steering variation 0x0000-0xFFFF), incremental values
spanning the full possible range of the front wheels.
Measured vehicle speed
Communication inputs
Mechanical:
Steering control
Throttle control
Brake control
Emergency brake system
Measured Vehicle Speed
1.3 Scope Limitations
Funding is expected, but not yet available. Due to the complexity of this project,
supporting the best solution could become a problem that affects the end results. It is expected
that once implementation in preliminary vehicle is successful, then funding for an all-terrain
vehicle (SUV or Truck) will be provided.
Testing could be limited as a result of approaching competition deadlines and expected
delivery time. Also, the new G-CART vehicle has not yet been acquired, which is a major
limiting factor of our design. This is because the acquisition of a vehicle is contingent upon the
qualification of the vehicle into DARPA’s Grand Challenge. The vehicle qualification deadline
extends beyond the senior design deadlines, thus responsibility for full testing of the motion
control system will be placed on the G-CART club. Lacking a desirable all-terrain vehicle has
also resulted in a significant overhaul of the entire design. The current vehicle does not have off
road capability, a CAN system, a Continental Teves compatible ECU for brake-by wire
implementation, or a throttle-by-wire system. This resulted in the inability to implement
previously expected designs.
The Executive Boards needs have been hazy at best. We have redefined our
responsibilities several times, based on the Executive Boards input. Our teams reduced role in
the overall project is proving to be problematic with respect to the design of deliverable goods to
satisfy our senior design project. We are currently broken into two sub teams responsible for
steering of the vehicle and speed control. The objective is to resolve the steering and speed
control.
Another limitation is our team’s lack of VHDL knowledge and time to learn it, for the
purpose of FPGAs. Some of the members have explored the feasibility of an FPGA solution.
However, due to the donation of a real-time controller by National Instruments, the FPGA
solution is no longer required. Further information is contained in the FPGA design section.
1.4 Stakeholders
R.I.T could win the two million dollar prize money.
D.A.R.P.A is the host of the race
Automotive industry could use some or all of the design
Public transportation (bus, taxi)
Continental Teves
Evolution Robotics, Inc.
Egnite Software
National Instruments
EE Faculty advisors
G-CART team members
1.5 Key Business Goals
Create funding for the completion of the project
Stay within budget, which minimal in comparison to the expected funding
Win the two million dollar prize for a first place finish
Advertise our sponsors that have donated money or products that aided the design and
completion of the autonomous vehicle.
Advertise Rochester Institute of Technology.
1.6 Primary Market
D.A.R.P.A is the host of the race
1.7 Secondary Market
Car manufactures – autopilot function or advanced cruise control system
RIT research and development for EE/ME/CE, which may attract R&D funds
1.8 Innovation Opportunities
High speed navigation
Save human life (military vehicle with no operator or passengers on board)
Artificial Intelligent vehicle - autonomous
Optimize for less error in comparison to human operation (commercial vehicle with
passengers)
Future NI software control modules
1.9 Background Research
The purpose of the G-CART team is to design a vehicle capable of autonomous
navigation through a variety of terrain. Once the autonomous vehicle is developed, it is the goal
of the team to compete in various competitions throughout the United States. The venues for
competition include DARPA’s Grand Challenge; a race of autonomous ground vehicles from
Los Angeles to Las Vegas with a cash award of two million dollars to the team that completes
the course in the shortest time.
To accomplish this goal, G-CART plans to research the existing technology in the
generic field of autonomous vehicular control and apply our knowledge to further research being
conducted in this area by RIT faculty, staff, and senior design teams. Ultimately, after our initial
goal of constructing an autonomous vehicle has been reached, we will continue research and
development in the realm of autonomous navigation and control. It is the club’s long term hope
to develop a streamline system of autonomous control, unique to RIT, which could be used in a
variety of different application; including ones that could potentially be marketable. To
complete this objective the club will develop a sensor/controller network that interacts with
customized computer algorithms, capturing and processing the data using cutting-edge Artificial
Intelligence constructs. For obstacle-avoidance and path planning, multiple sensors will be
incorporated, such as: optical, radar, sonar, laser, and Global Positioning System data (GPS).
The result will be an intelligent vehicle that will have the navigating a dynamic environment.
The G-CART club has successfully developed a completely wirelessly controlled vehicle
over the course of three months. The team was successful in altering a 1991 Geo Storm into a
vehicle capable of being controlled from several hundred yards away. Completion of this task
marks the end of the first phase of the project. The team is actively pursuing corporate
sponsorship to continue on their journey to develop an autonomous vehicle able to compete in
the 2005 DARPA Grand Challenge.
1.10 Formal Statement of Work
The G-CART club’s Executive Board has requested that the senior design team develop
systems to control the throttle, braking and steering. For the throttle and braking portion, the sub
team must deliver a “modular” control board that is capable of being adapted to one of several
choices of sport utility vehicles. The system must interact with a TCP bus for the purpose of I/O
signaling. The system must also maintain bus master functionality and appear as such to the
guidance computer. At this time, the controller will not connect to a throttle by wire system and
Continental Teves brake by wire prototype. Instead, a pulse width modulated motor will be
connected directly to the throttle butterfly. A cam and motor assembly will directly contact the
brake pedal, controlling the brake pressure as needed. The controller must maintain the desired
vehicle speed within ±2 percent settling margin, except at a desired speed of zero. It is required
that the system must be capable of responding at least as well as a human operator. Through
tests the vehicle’s maximum performance will be determined, and used to optimize vehicle
response to the controller input.
To avoid serious brake overheating, the controller must choose either braking or active
throttle, not a combination of the two. An emergency brake will provide a means of stopping the
vehicle when the conventional braking system fails to bring the vehicle to a stop. Through the
use of a linear actuator, the vehicle can activate a “last resort” method of deceleration.
2 CONCEPT DEVELOPMENT
This section will cover the different design concepts our team considered. The
first few sections discuss the break down of the team. Since there are many different aspects to
the project, the team of seven engineers broke up into subgroups. From the subgroups, ideas
were generated and brought together to aid in concept development on communication
architecture, bus architecture, vehicle steering, and speed control.
The team was broken into the three following subgroups, Steering Control, Velocity
Control, and Communications. The communications team is responsible for developing a system
that allows all system nodes to transfer data. The developed communications system must be
able to communicate through multiple protocols as well as have the ability to send custom
system flags, data packets, and system information. The teams collectively had to develop a
software interface between the communication system and the various subsystems. The velocity
control group had responsibility for the actuation of both the brake and throttle system. Custom
mounts were developed for both of these systems, as well an appropriate software interface.
2.1 Subgroup
The team was divided up to concentrate on the different aspects of the project. There were
3 different subgroups, although the Bus Architecture group had a short term focus and the team
members were assimilated into the other remaining subgroups. The subgroups are Bus
Architecture, Steering, and Speed Control.
2.1.1 Bus Architecture
The G-CART navigation computer, navigation sensors and vehicle control systems need
to have a communication bus to transfer data and commands. This subgroup was created with a
short-term goal: to design a communication network within the first few weeks of the fall
quarter. Scott Glover and Darren Rowen worked on this subgroup. They presented their
research to the RIT G-CART Club and hammered out which design would be best for the
project.
2.1.2 Steering
The steering subgroup was formed in approximately the third week to focus on the
electronics for the steering control system for the vehicle. The steering subgroup was to work
closely with the Mechanical Senior Design team. The Mechanical team was responsible for
picking out an appropriate motor, gearing and motor mounting. The steering subgroup from the
electrical senior design team was responsible for designing a motor drive and controller for
steering system. The controller for the system must be able to communicate with the guidance
computer and be able to read measured feedback data.
2.1.3 Speed Control
The purpose of the speed control sub-team was to create a control system for braking and
throttle. Originally, the first part, braking, would be the easier of the two. Continental Teves is a
company that designs drive by wire systems for Ford and Toyota. They have asked to help
implement their prototype brake by wire system. Braking would have been controlled by a
pressure sensor and a pump attached to the master brake cylinder. The vehicles CAN system
would give the current master cylinder pressure as well as deliver the desired master cylinder
pressure. The velocity sub team will read in desired velocity to our control board, make
adjustment to the brake pressure and test results for amount of error with respect to desire
velocity and pressure and compensate for unexpected results.
The second part of the task was to control a throttle sensor and throttle position motor.
The difficulties lie in the off road application. The vehicle will be subject to many road
obstacles, uneven surfaces disturbances, turning on dirt surfaces, up/downhill non-linear gradient
disturbances to the system. The controller will read in current speed, desired speed, and pseudo-
acceleration variables via the I2C bus. The output will control the throttle position motor via the
CAN system, test results of the position command, and adjust for unexpected results.
The controller has to be fast enough to parse data from the I2C and CAN bus networks.
In addition the controller must be able to make any required control calculations and react to
system errors in accordance with the defined error procedures.
2.1.4 Concept Changes
The senior design team had to deal with several radical concept revisions. The G-Cart
club failed to acquire a Toyota Sequoia or comparable SUV. Multiple resources were tapped in
an effort to attain a vehicle worthy of competition. During this process we were assured, by our
sponsors, that an SUV with a Continental Teves throttle by wire system would be available for
system integration by the December of 2004. Continental Teves committed to adapting a Brake
by wire system in to such a vehicle. The main source of feedback for our control systems was
based on a CAN bus interface. After 15 weeks of research, design and testing, we were informed
that our system would now need to be integrated into a 1991 Geo storm. The Geo does not have
a throttle by wire system, a CAN bus, nor does it support the Continental Teves brake by wire
prototype.
The new system required DC motors for mechanical actuation of throttle, brake, and
speed feedback. The team’s limited budget and time constraints were not conducive to proper
engineering design processes. Our new design was restricted to a selection of existing and used
motors that were often from manufactures that were no longer in business. The quest to find
catalogue and or specification data for these motors was very unsuccessful. Unavailable torque
and max current ratings created serious concerns as to motors capability, especially during
periods of extended use. The limits of modular design were definitely tested. Our team adapted
using engineering judgment when needed to use components for applications they weren’t
designed to perform. By the use of cautious testing and experimentation, a workable system was
developed and has been partially tested.
In all fairness the G-CART was promised money for a vehicle, contingent upon
acceptance to the DARPA Grand Challenge. The club has to prove the Vehicles capabilities in
several stages. The first step to DARPA acceptance is a video demonstrating of initial design
progress. The next stage is a DARPA supervised test. Finally, the vehicle has to complete a test
course. After the G-CART club purchases an SUV, system modifications will be required to
adapt to the new application. The current system is capable of being used for a variety of
applications, but the ability to run the system in an alternate vehicle would take many
adjustments. For example, the current system is required to actuate the brake pedal to achieve
braking pressure. In another vehicle, a brake-by-wire system could be used. Clearly the design
for a pedal actuation can’t be transported for use in a brake-by-wire vehicle without any
modifications. Our team’s goal has been to make the system as modular and capable as possible,
but customization will be required to fit the appropriate vehicle and corresponding components.
2.2 Bus Architecture Concepts
Perhaps the most important goal of this years G-CART project was to produce a
modular design, which would allow for future additions to the project. In order for future
integrations to go smoothly, a standard communications protocol between processors,
sensors, and actuators should be established. This communications bus should allow for
simple future additions while also providing reliable and noise-free communication
between all in-car nodes. The following block diagram shows the current G-CART bus
architecture design.
Figure 2.2.1
Below is brief description of the five communication bus protocol concepts that
were seriously considered for implementation into the G-CART vehicle. Lastly, an
overall comparison of the bus architecture concepts is presented.
2.2.1 I2C
The first communications bus protocol considered was the inter-integrated circuit
(I2C) protocol, developed by Philips Semiconductor. This concept is a simple two wire
system, which can transmit addressable packets at a rate of 3.4Mbps. This protocol
allows for seven bits of addressing (128 devices), which would allow for a great amount
of future upgradeability. This protocol also has the ability to generate broadcast
messages, which are packets sent to all nodes regardless of addressing. This would allow
for emergency messages to be sent over the network, causing all nodes to act
simultaneously, rather then sending important commands one at a time to each system
node.
An I2C communications bus is currently used on existing G-CART vehicle to
handle simple communication between closely spaced processors. Therefore the G-
CART team already has a working knowledge of this communications protocol, which
should expedite the implementation of this design.
The only major concern of the I2C protocol is its lack of noise immunity and error
correction. Although no problems with the current I2C bus have been identified, it has
only been used for small distances and limited bus traffic. For the new G-CART design,
the communications bus will be run throughout the vehicle (several meters) and be
subjected to greater amounts of EMI from both the vehicle itself and from outside sources
(power lines, radio traffic, etc.).
2.2.2 USB
The Universal Serial Bus (USB) was also considered for the communications bus
protocol. USB is a robust, fast and reliable protocol that has become somewhat of an
industry standard today. This protocol would allow for new sensors or actuators to be
connected to the bus on the fly, and immediately be recognized by the system. USB also
has the benefit of having a built-in error checking and fault-handling mechanism. This
would allow for our communications bus to have greater length and handle more volatile
environments.
The major drawback to using a USB system is cost. Processors with
programmable USB ports are typically more costly than alternatives, and software
configuration is generally more difficult as well. Even though USB is an open-source
protocol it has many advanced features that would not be required by our application.
These additional features may be distracting and cause unnecessary overhead in our
vehicle.
2.2.3 PXI
PCI Extensions for Instrumentation (PXI) is a protocol that combines the high-
speed PCI bus with integrated timing and triggering lines for data capture and
comparison. Like USB, PXI devices are typically dynamically reconfigurable, which
results in a ‘plug-n-play’ system. This protocol was designed specifically for data
capture and analysis, and therefore has several unique triggering and comparing features.
It is yet uncertain whether or not these features would be used in the communications bus
of the current G-CART design, but they could potentially be of great use in future design
revisions.
PXI devices are typically very robust and high modular. Most of the PXI DAQ
board that we looked at for this design were rated for extreme temperature, vibration, and
EMI, all much outside of the range that is expected to be encountered for this project. If
a PXI bus were implemented, all processors and controller would be similar to a PCI card
(like those used in standard PCs), which would plug into specialized PXI chassis.
Again, the main drawback to this concept is cost. Both the PXI chassis and
controllers are very expensive. This concept is mainly considered because one of the
major PXI vendors, National Instruments (NI), is currently considering the RIT G-CART
team as a sponsor. If this sponsorship is obtained then the cost of the PXI equipment
would be greatly reduced and some of NI's pre-built systems could be integrated into the
G-CART vehicle.
2.2.4 IEEE 1384
The next bus protocol concept considered was the IEEE 1384 standard,
commonly referred to as firewire. This protocol is also fast becoming an industry
standard for high-speed data transfer. Firewire is typically seen in video applications
were high bits-rates are required. In addition to its speed, firewire also allows for an
extremely high number of nodes to be connected on a bus, which would allow for future
adaptability. Firewire also included noise immunity and error correction similar to USB,
which would make it durable and reliable in the G-CART application.
It is unsure whether or not the high speed of IEEE 1384 is required on a
communications bus. Currently, there are no plans to include any video-based sensors on
this network and therefore the high bit-rate may not be needed. Also, it is relatively
difficult to find cheap controllers with IEEE 1384 programmable connectors. Most
devices that include firewire interfaces are video-specific, and include features that will
not be used for a typical bus-level controller.
2.2.5 RS 485
The final communication bus protocol investigated was RS-485. This protocol is
a more robust version of the widely popular RS-232. RS-485 is a four wire design, which
broadcasts packets from a bus master and has variable message lengths. This protocol
also has error correction, although not as comprehensive as the method employed by
USB or IEEE1384. RS-485 is a popular choice for industrial communications because it
has to be ability to provide high noise immunity over long distances. This would allow
for the communications bus to be run throughout the G-CART vehicle without worrying
about maximum distance or line capacitances.
RS-485 is also considered to be a good solution because it is easily interfaced
with most microcontrollers and processors. Most devices come standard with either a
RS-232 port or a full UART. Both of these can be used to receive RS-485 signals with
little software overhead.
2.2.6 Ethernet based TCP and UDP
Although TCP and UDP protocols were not originally considered as a
communications protocol during the preliminary design phase of this project, certain
changes to the overall communications architecture made this option more appealing.
Initially, our subsystems were to be under the control of a CBM, which in turn would
interface with a navigation computer. The interface between the CBM and the navigation
computer was originally to be an I2C link as well. A major design change modified the
CBM to navigation computer link. Instead an Ethernet connection would be employed,
and the CBM would hand packets to our system via a simple I2C interface. During our
system design it became evident that our National Instruments controller had the ability
to handle all CBM level functions, and therefore our system did not need a higher level
CBM to parse data packets. In addition, hardware shipment delays combined with the
design change to an alternate vehicle restricted the amount of engineering time for the
development of a custom I2C interface. The NI controller’s network card proved to be a
viable option. To simply the communications system, our system could talk directly with
the navigation computer over TCP and UDP. Because this protocol allowed for the
elimination of a CBM level device, which reduced system cost and development time,
this protocol was eventually adopted.
2.2.7 Compare and Contrast
The concepts listed above demonstrate the wide range of communication
protocols that can be implemented into the G-CART vehicle. All six of the
communication protocol concepts allow for individual and broadcast addressing,
bidirectional communication, and a high number of attachable nodes. Some concepts
have specific attributes that make them appealing, such as the specialized triggering
commands in the PXI protocol. Other concepts provide simple bus architecture with
limited overhead, such as RS-485 and I2C. However, because of interface requirements
with both the navigation computer and with other CBM level devices, the most logical
communications protocol was found to be Ethernet. Because the speed and throughput
requirements for the G-CART vehicle are quite low, Ethernet will be more than adequate
to handle the communications load. The non-deterministic nature of TCP
communications is not ideal for the motion control system. Our support for using a CAN
communication protocol was not shared by other affiliated teams. In some cases the
embedded designs did not currently have CAN communication capability. Ultimately,
the decision to use a deterministic communication protocol was not ours to make.
2.3 Steering Concepts
2.3.1 DC Drive Concepts
Many different approaches were researched, although the final concepts were
restricted by the final motor selection.
2.3.1.1 PicMicrocontroller with Hall Effect Feedback
There are some alternatives to control the motor drive (bridge). One way would
be to control it using hardware approach, which is relatively more expensive and the
reliability is questionable. Using the software approach, the design will be more cost
effective. The design will be more reliable over all due to lower hardware complexity.
For the design, the PIC microcontroller was chosen due to its cost effectiveness, available
resource and documentation, and simplicity. The recommended set up for a PIC
microcontroller based 3 phase BLDC motor control is shown below:
Figure 2.3.1.1.1
2.3.1.2 PicMicrocontroller with no commutation feedback
This concept is very similar to the DC drive using commutation feedback. The
main difference is that the microcontroller will energizes the coils in a fixed pattern. The
main drawback to this design is that with loading, the motor may not speed up to the
fixed pattern and a stall could result. In the start up scenario, without motor position
information, the fixed pattern would only assist in starting the motor for one third of each
excitation cycle. A primary concern is having enough start-up torque. So the loss of
start-up torque makes this design option highly unlikely.
2.3.2 Controller Concepts
The controller would have the responsibility of reading and parsing the I2C
communication from the navigation computer. In addition, the controller would have to
monitor the vehicles CAN traffic and parse out messages containing the vehicles wheel
angle. From this data, the controller would need to computer an error signal. Using the
error signal the controller would then have to compute the appropriate motor speed and
direction.
2.3.2.1 FPGA Controller
One possible approach was to use an FPGA to act as the controller. The FPGA
would have to be capable of reading and parsing both CAN network messages and I2C
network messages. The programming of the FPGA to read and parse network data from
both I2C and CAN networks could prove a difficult task. In addition, a Digital to Analog
converter would be required to provide the reference voltage for the DC Drive.
An FPGA would easily be able to implement a fixed weight FIR filter to
implement the control algorithm. In an FPGA, the ability to adapt or vary the weights
would add a tremendous amount of programming complexity.
The FPGA would have to be installed on a circuit board with auxiliary circuitry
including power supplies, external pull-up and pull-down resistors and filtering
capacitors. In many cases demonstration boards are available for purchase.
2.3.2.2 Microcontroller
The wide range of microcontrollers on the market offers an amazing range of
capability. There are microcontrollers available that are capable of reading CAN and I2C
network traffic. A microcontroller would also be capable of implementing an FIR filter.
Being the values for the weights of the filter would be stored in memory; they could be
changed or adapted without having to reprogram the device. One concern is the ability of
a microcontroller to implement an adaptive control algorithm, such as the least-mean-
square (LMS) algorithm. Implementation of an adaptive controller requires very high
speed computations in order to minimize the adaptation time. It is questionable as to
whether a microcontroller would have the processing power to implement such a control
algorithm.
The programming of a microcontroller can often require proprietary software and
hardware, adding a lot of cost to this approach. Most microcontrollers can be
programmed via writing C or assembly code and then downloading it to the
microcontroller.
The microcontroller would have to be installed on a circuit board with auxiliary
circuitry including power supplies, external pull-up and pull-down resistors and filtering
capacitors. In many cases demonstration boards are available for purchase. In addition, a
Digital to Analog converter would be required to provide the reference voltage for the
DC Drive.
The validation of such a controller would be very involved. External
communications monitoring hardware would most likely be necessary. Troubleshooting
could prove very difficult for a microcontroller based controller.
2.3.2.3 National Instruments Real Time Controller
National Instruments offers a Real Time Control module for the PXI platform.
This module uses the LabVIEW Real-time operating system. There are several different
models available, which all have different features. There is a module available that has
an extended temperature operating range and a tremendous amount of processing power.
The extended operating range would work well for our application. These modules are
designed for an industrial environment and would offer many advantages in terms of
reliability.
The programming of the Real Time Control Module is done using a standard
Ethernet link. After the code was written in LabVIEW on any windows or Macintosh
computer it can be downloaded via the Ethernet link to the embedded real-time target.
The control module would have to be installed in a PXI chassis. These chassis are
designed for modular components. Other modules, such as a CAN communication card
could simply be snapped into place. No external wiring or circuitry would be required.
For reading I2C and CAN traffic there are PXI modules and drivers readily
available. The CAN module offered by National Instruments comes with software
capable of parsing data.
The validation and testing of the controller and steering system would be made
much easier by using a National Instruments Controller. National Instruments originally
started out in the electronics testing business and have since expanded. The built in
troubleshooting and test capabilities could prove invaluable.
Although National Instruments equipment is typically expensive, we may be able
to obtain their sponsorship. The company’s interest in partnering with RIT will most
likely allow for the donation of the majority of the equipment required.
2.4 Velocity Control Concepts
The main focus of the velocity control subgroup was to develop a method to
reliably and quickly alter the G-CART vehicle’s speed. This involves interpreting set
points handed to the communications bus by a higher level navigation computer, and
making corresponding changes to a the vehicle’s throttle and braking systems. Below is
a description of controller concepts investigated by the velocity control subgroup. An
analysis of the feasibility of each control method is shown in section 3.3.
2.4.1 Controller Concept
After much research, it became obvious that a PID controller was necessary as the
controller for the throttle/braking portion of the autonomous vehicle. It was decided that
our system should work similar to how a cruise control system would work. The only
difference being that overshoot would not be a problem as long as the response time was
better and the setting time was reasonable.
To understand why a PID controller was necessary, it is important to understand
what a PID controller is. PID stands for proportional-integral-derivative, each of which
makes up the three parts of the controller. For a PID controller, there is usually a desired
set point that the controller must meet. It is based on error between the desired set point
and the output of the system. The proportional part of the controller is just the error
multiplied by the gain Kp. The integral portion is the integral of the error multiplied by
the gain Ki. Finally, the derivative portion of the controller is the rate of change of error
multiplied by the gain Kd. Kp, Ki, Kd are gains that can be changed in order to meet the
optimal response.
The most basic control system would be the proportional controller. Basically,
what the proportional controller would do is adjust the throttle proportional to the error.
Therefore, the greater the error became the greater the throttle. The problem with that
type of system would be that the closer the car was to the desired velocity, the slower the
car would accelerate and when a fast response time is desired, this type of system is not
reasonable. Also, if the car was traveling up a hill that was steep enough, it may not
accelerate at all.
The next type of controller is the proportional-integral controller. This type of
controller does everything that the basic proportional controller can do and more. The
integral of the speed is distance. Therefore, since the integral of the error is taken, the
integral portion of the controller gives the difference between the distance that the car
should have traveled if it were to have traveled at the desired speed and the distance that
it has actually traveled. This corrects problems that may arise when traveling up hills and
also helps to settle the car into the correct speed and stay there. The integral portion of
the controller removes the need for a tilt sensor to provide another signal to the controller.
It also makes the programming for the controller less complicated.
The final type of controller is the proportional-integral-derivative controller. The
derivative of speed is acceleration. Therefore, it can be seen that the derivative portion of
the controller will affect the acceleration of the vehicle. The derivative portion of the
controller will help the car to respond quickly to changes. For instance, if the car begins
to slow down due to a hill, the controller will see the downward acceleration before the
speed of the vehicle changes significantly, and will therefore respond by increasing the
throttle.
While a proportional or a proportional-integral controller would probably be able
to control the car, a PID controller has all the qualities that the desired vehicle should
have in order to compete. Not only do we want the car to be able to get to a desired
speed, but we want it to reach that speed as fast as possible to ensure that the car is as
close to where it should be as possible.
2.4.2 FPGA Concept
FPGAs are digital ICs (integrated circuits) that contain configurable blocks of
logic along with configurable interconnects between blocks. Design engineers can
program this kind of device to perform a remarkable variety of tasks. Field
Programmable means that the device has not been hardwired by the manufacturer, which
creates the flexibility. Some FPGAs can only be programmed once, while others can be
reprogrammed many times over. This would be similar to CD-R verse CD-RW for data
storage on a disk. One-time programmable (OTP) is the implicit term used in reference
to FPGAs.
FPGAs create a middle ground between ASICs (application–specific integrated
circuits) and PLDs (programmable logic device). An FPGA can be used to implement
large and complex functions that previously had to be realized by ASICs. The cost of
FPGA design is much lower and easier to manipulate for design changes. This means
that small engineering groups can realize hardware and software on a test platform
without major fabrication costs. Some FPGAs contain millions of gates, and can offer
high speed Input/Output interfaces, digital signal processing (DSP), and reconfigurable
computing (RC). RCs are used as a “hardware accelerator” for software algorithms.
FPGA devices are capable of being programmed while remaining resident in a higher-
level system; this is referred as being in-system programmable (ISP). Altera’s Nois II
board was donated to our team as a possible means for a speed control solution.
Figure 2.4.2.1
Nios II Processor System Basics:
The Nios II processor is a general-purpose RISC processor core, providing:
■ Full 32-bit instruction set, data path, and address space
■ 32 general-purpose registers
■ 32 external interrupt sources
■ Single-instruction 32 × 32 multiply and divide producing a 32-bit result
■ Dedicated instructions for computing 64-bit and 128-bit products of multiplication
■ Single-instruction barrel shifter
■ Access to a variety of on-chip peripherals, and interfaces to off-chip memories and peripherals
■ Hardware-assisted debug module enabling processor start, stop, step and trace under integrated
development environment (IDE) control
■ Software development environment based on the GNU C/C++ tool chain and Eclipse IDE
■ Instruction set architecture (ISA) compatible across all Nios II processor systems
■ Performance beyond 150 DMIPS
One of the notable features of the Nios II processor is termed Configurable
Soft-Core Processor. The CPU is in a “soft” design form, contrary to fixed
microcontrollers. Essentially, it is a blank FPGA. This allows the user to configure the
processor and peripherals to meet their needs and then program the system into an Altera
FPGA. Altera offers some ready made Nois II systems design, so that the user does not
have to create a new processor configuration for every design. A Flexible peripheral set
and address maps allow for an exact peripheral set intended for the target application.
Furthermore, Altera’s SOPC Builder design tool fully automates the process of
configuring process features and generating a hardware design that can be programmed
into an FPGA. After the system generation and programming the board, the software can
be debugged through on board execution.
One of the Key ideas discussed in the Quartus II handbook is the
significance of timing in relation to system reliability. A synchronous design implements
a clock signal trigger for all events. All of the registers’ timing requirements must be
must as well. Without such a design the system may be dependent on propagation delays
and create possible glitches. Typically, the data inputs of registers are sampled and
transferred to output on every active rising edge. The outputs of combinational logic
feeding the data inputs of registers will then change values. The internal circuitry of the
registers isolates data output from inputs; therefore instability in combinational logic does
not affect the operation of the design as long as two things are considered. First, the data
input must be stable for the setup time of the register (before an active clock edge).
Second, the data must remain stable for the hold time of the register (after an active clock
edge). If the setup (tSU) or hold time (tH) is not met, output can be set to an intermediate
level between high-low values. In this unstable state, small disturbances, like noise in the
power rails, can cause registers to assume unpredictable valid states. When controlling
the speed of an autonomous vehicle, unpredictable valid states are not an option. The
throttle could be held in an “on” position, the brakes could malfunction or the brakes and
throttle could be active at the same time. System stability is a requirement for a speed
FPGA controller.
2.4.3 8051 Concept
One of the other potential controller options is a Rigel Development
Board, provided through the Electrical Engineering Department at RIT. This board uses
a C515C processor, which is a subset of the Intel 8051. Because this board uses an
industry standard processor, there is a considerable amount of pre-existing libraries and
functions that could potentially simplify controller design.
This control board is used in several RIT courses, and members of the
velocity control subgroup already have experience using this software, which should
reduce the difficulty in implementing this design. In addition, this controller design also
includes 48 digital I/O lines and eight analog inputs. Although the current design should
not require more than four digital I/O lines, this adaptability could provide useful for
testing and data logging purposes. This control board also has
An on-board Full-CAN controller, which would allow for decoding of message from the
automotive CAN bus without extensive software programming.
An on-board DUART, which would allow for simple connection to either an RS-232/485
or I2C communication bus
10-bit A/D converter for analog actuator control
Multiple priority interrupts, which could be manipulated by the controller bus masters in
order to change message priorities
Although the current Rigel boards are available free of charge for this project,
they are somewhat obsolete. They operate at 12MHz, with most operations taking 12
machine cycles. This speed is notably slower than the FGPA alternative, and may limit
the effectiveness of this solution. There are newer control boards produced by Rigel that
operate much faster, and are completely backwards compatible. Therefore, if a controller
was designed on this board and it was determined during the testing stage that the
response was too slow, then faster boards could be purchased (~$200) with no software
changes required.
2.4.4 NI Real-Time Controller Concept The National Instruments (NI) Real-Time controller was donated to the G-CART
team, and has proved invaluable to the development of our control system. This
controller has an embedded Pentium4 2.2 GHz processor with separate processors to
independently handle TCP, CAN, and serial communications. The controller also has
256Mb of RAM and an internal 40 GB hard drive. The Lab-View RT software has many
pre-built software libraries that allows for fast software design and troubleshooting.
The data acquisition card that was donated along with NI controller has the
capability to process eight differential analog I/O lines and two analog outputs, all of
which can transmit at a rate of 2.8 mega samples per second. The DAQ also has the
ability to simultaneously process 24 digital I/O lines, some of which have optional
counting and timing abilities. These interface capabilities, along with the ability to easily
interface with various protocols made the NI controller a very appealing option. Because
this controller was donated to the project, there were no issues with cost. Also, members
of our team were already familiar with the LabVIEW software package; therefore the
difficulty of software development was reduced.
2.5 Emergency Brake Concepts
The E-brake concepts that were considered are divided into two parts, the actual
method of actuating the brake and the type of actuator to be used. The combinations of
these two parts also play a big role on each other, which will be discussed in the next
sections.
2.5.1 Actuating method
The first method is to pull the e-brake from behind as seen in Figure 2.5.1.1 with
the other end of the actuator mounted to the floor panel. This design allows for the
mechanical advantage of the lever to be used but the disadvantage of this is that the
stroke of the cylinder will have to be longer which causes a longer response time for
actuators with slow travel speeds. After testing and taking the worst case of five different
vehicles I came up with a stroke of approximately 4 inches and a load of roughly 130 lbs
for this method of actuation. The biggest benefit of this design is that it is the simplest
and most versatile of the two and probably the most reasonable of the two since the exact
application is unknown, so the system that is designed will have to be easily modified to
meet the vehicle needs.
Figure 2.5.1.1
The second method is to remove the brake lever all together and pull directly on
the cable without any mechanical advantage which can be seen in figure 2.5.1.2. This
design will have a very short stroke compared to the first concept which will lead to a
quick response time which is a very large advantage. The downfall to this is that since
we are not using the mechanical advantage this short stroke is going to have a very large
load which makes the actuators more expensive and less compact. The stroke
requirement for this application is roughly 1.5 inches and a load of roughly 450 lb.
Figure 2.5.1.2
2.5.2 Type of Actuator
There are three types of actuators that were considered air, electrical, and
hydraulic systems. They all have there advantages and disadvantages. And depending
on the method of actuating the brake they also have there advantages and disadvantages.
The air system has very fast stroke rates with high loads which is essential when
time is one of the biggest factors. Air cylinders are also a very simple mechanical device
and therefore also very robust but for this application it is not a very crucial attribute.
Since we will probably only actually use the actuator a few times if any. The downfall of
the air system is the complexity of the overall system and the time it will take to install
the system. When looking at the price of the system it is not far behind an electric system
since there are many more components in the air system, like air compressor, tank,
electric valves, etc.
The hydraulic actuator has many of the same attributes the air actuator has. The
biggest problem with the hydraulic actuator is we don’t have the expertise to install a
system like this and since it is allot like the air the air actuator will be chosen over the
hydraulic actuator.
The electrical actuators are a little more than the air system if you want good
response times but if time could be sacrificed the electrical actuators are much cheaper
than the air systems. Some very good attributes to the electrical system are there
versatility and there ease of installation, which with the time constraint that we are under
is very good since we need time to install theses systems and debug them.
3 FEASIBILITY
Feasibility studies were preformed on many of the design concepts to guide our
team on the direction to proceed. Pugh’s Method and the weighted method were both
used as references while performing the feasibility assessment.
3.1 Bus Architecture Feasibility
The five original bus architecture protocols were analyzed through the use of a
weighted method, which took into account the nine indicators shown on the table below.
Each characteristic is assigned a weight between zero and ten, which is multiplied by the
score given to a particular concept. The sum of all the individual indicators gives the
final feasibility of each concept.
Defining Bus Characteristics
Rel
ativ
e
Wei
ght
I2C
USB PX
I
IEE
E13
84
RS
485
Bus Speed 5.0 5 8 7 10 4
Number of Nodes on the Bus 3.0 5 5 3 8 7
Error Handling 5.0 0 8 4 8 4
Noise Immunity 3.0 3 9 8 7 8
Robustness of Design 5.0 4 7 10 7 8
Simplicity of Design 5.0 10 5 2 2 8
Cost of Components 6.0 9 6 1 4 8
Difficulty of Integration 8.0 9 5 7 2 8
Team Familiarity 8.0 10 2 2 2 5
Score (sum of weighted values) 325.0 274.0 226.0 236.0 317.0
Normalized Score 1.000 0.843 0.695 0.726 0.975
Table 3.1.1
This weighted method shows that the I2C method of communication is the most
effective for our application. This is mainly due to the low cost, ease of integration with
existing components, and previous G-CART team experience with the protocol. The
IEEE1384 and PXI concepts were identified to be poor alternatives due to high
complexity and difficulty of integration. Despite this conclusion, we were given the
requirement from our sponsor of interfacing with the navigation computer over an
Ethernet connection. Therefore, this was the final protocol decided upon. Given our
hardware’s flexibility and the availability of software toolboxes this transition was
possible within the project’s timeframe. During the testing phase of this project the
Ethernet connection was shown to perform within all specifications.
3.2 Steering Feasibility
3.2.1 DC Drive Feasibility
The DC Drive must be capable of driving the permanent magnet bushed DC
motor chosen by the G-CART club. The steering motor demands that the drive be able to
supply 12V and continuous current of 3.5A. The Brushed DC motor operates directly off
a DC voltage source. An optical encoder was used to detect the rotor position.
3.2.2 Controller Feasibility
The controller concepts described were analyzed through the use of a weighted
method, which took into account the nine indicators shown on the table below. Each
characteristic is assigned a weight between zero and ten, which is multiplied by the score
given to a particular concept. The sum of all the individual indicators gives the final
feasibility of each concept.
Defining Controller
Characteristics Rel
ativ
e W
eigh
ts
FPG
A C
ontr
olle
r
Mic
roco
ntro
ller
NI R
eal T
ime
Con
trol
ler
Processing Power 6 8 7 9
Testability 8 3 3 10
Troubleshooting Capability 8 4 4 10
Programming Difficulty 9 3 5 10
Robustness of Design 6 7 7 8
Simplicity of Design 3 3 4 9
Cost of Components 4 10 7 4
Difficulty of Integration 5 3 4 9
Team Familiarity 5 3 5 7
Score (sum of weighted
values) 252 270 475
Normalized Score 0.53 0.57 1.00
Table 3.2.2.1
This weighted method shows that the National Instruments Real-Time Controller
is the best choice for our application. This is mainly due to the Testability, trouble
shooting capability and programming ease. The availability of drivers and modular
communication cards makes this system very easy to integrate. Being we have not yet
heard a final word on the sponsorship of these components the Cost was rated at 4/10. If
the sponsorship comes through, this would increase this score and make this design even
more feasible. It should be noted that the same type of control algorithm could be
implemented in any of these designs. So although one concept is more feasible, all of the
concepts looked at are certainly capable of fulfilling the needs of this project.
3.3 Speed Control Feasibility
3.3.1 Controller Feasibility
The greatest advantage of a PID controller is its robustness. The three different
error control operations of the controller help to rapidly correct any deviation between the
desired speed and the actual speed. The controller’s ability to quickly correct these
deviations is necessary for proper function of the autonomous vehicle. However, a major
draw back to the PID controller is situations that can disrupt the effectiveness of the
derivative portion of the controller.
There are two situations that occur that causes problems with the derivative
portion of the controller. The first is any sharp change in the desired velocity with
respect to the current velocity. This sharp change would result in an unreasonable size
control input to the vehicle. This may not be a problem for our vehicle due to the fact
that we do not anticipate any dramatically sharp changes in the velocity. The stability
system on board should stop any slippage from causing a spike in the velocity measured.
Also, it is expected that the any changes in velocity would be received from the on board
computer in smaller increments to insure smooth transitions in speed. The second
situation that may be more of a problem is noise. Noise may cause undesirable spikes in
sensor information that would be fed into the controller. Like in the previous situation,
the sharp change would result in an unreasonable size control input to the vehicle. This
could possibly pose a problem for our system.
At this point, even with the problems, a PID controller may still be the best
option. Current cruise control systems use PID controllers as a means to adjust velocity
without many problems. For this reason, a PID controller remains the number one
option. A PI controller may work as an alternative, but it would not be as robust and as
quick to respond to changes, but would accomplish the task.
3.3.2 Velocity Control Feasibility
3.3.2.1 FPGAFor our purpose, an FPGA controller seems ideal with respect to the design task at hand.
FPGAs are adaptable, more than fast enough, free of cost to us, and expandable to meet
unforeseen needs. The problems do not lie in the technology, but are inherent in our team. Our
team does not have a license for the software that was provided with the x-caliber FPGA.
Another problem is the time limitations set forth by the Fall/Winter blocks. None of our team
members are familiar with VHDL, and we would not want our project to fail based on our lack
of VHDL knowledge. There are several other options that can be used to implement a solution,
and will be discussed further.
In order to give our team time to acquire a software license and to become familiar with
the VHDL language, the 8051 development board will be implemented as a primary solution.
This development board has more than enough speed to parse the income I2C and CAN data-
streams. At the time this primary software development is completed, it will be determined
whether or not we can use the FPGA to perform the actual PID control. If the FPGAs are
deemed feasible, we will use it in conjunction with the code already developed on the 8051
board. If the FPGAs are not feasible we will perform the PID control on the 8051 development
board itself.
3.3.2.2 NI Real-Time Controller
While the FPGA would have met all the requirements needed for the motion control
system, the drawbacks made the option less ideal when National Instruments decided to donate a
real-time controller. While the NI real-time controller was not feasible at first due to the cost,
once it was donated, it easily became the best option.
The real-time controller was to be programmed in LabVIEW, a program that known by
some members of the team. Also, the ease of the program allowed for other team members
unfamiliar with the program to quickly pick up the language and help the implementation of the
control system. The most important aspect of the NI real-time controller that became extremely
beneficial was the troubleshooting capabilities. Even while the program was running on the
vehicle, it was easily possible to troubleshoot and find flaws or errors in the system. The
reprogram ability was also an added benefit.
As can be seen by the controller feasibility table above, the NI controller was the ideal
controller for our application. The only thing that initially prevented its use was the lack of
funding to buy it. However, its donation greatly increased the robustness of the motion control
system and also allowed for tremendous future expandability.
3.3.3 Emergency Brake Feasibility
The feasibility assessment for emergency brake was assessed using a radar chart with the key
attributes being cost, versatility, durability, reaction time and ease of installation. In this method
the polygon that has the greatest area is the most feasible system. From this radar chart below it
can be seen that the electrical system is the most suitable for this application. With the air
system not far off, but as discussed earlier when considering versatility, and being able to easily
bench test the system the electrical is the best choice.
01234
low cost
high versitility
high duribilityshort reaction time
easy overall installation Air
ElectricalHydraulic
Figure 3.3.3.1
3.4 Feasibility Conclusion
For the bus architecture, the team selected the UDP and TCP protocols. This
design proved to be the best fit for the G-CART vehicle. It was primarily due to the final
G-Cart redesign specifications and time constraints that these protocols were found to be
better than the other alternatives. As part of the communication protocol deviation from
the original design, the velocity control computer also had to mimic ether-nut bus master
functionality. The purpose was to bypass the I2c protocol, which was not easily
incorporated into the NI real time system
The steering subgroup has decided to implement their control algorithm on a
National Instruments Real-Time controller module. This concept was selected because of
its high testability, ease of programming, and robust design. The mechanical G-CART
senior design team (5106) was initially responsible for selecting the motor to drive this
subsystem. The G-CART team has since provided the current steering motor. The motor
feasibility is a result a hierarchy of decision making, beyond the scope of the senior
design team. Budget constraints were also a key element in feasibility consideration.
The speed control subgroup has decided to use a software implemented PID
control method in conjunction with the provided throttle motor and encoders. This
control will be performed on the National Instruments Real-Time controller module. The
G-CART club has decided to implement a linear actuator for the purpose of the
emergency brake system. This deviates from the original plan to have our Mechanical
Engineer design the emergency brake system.
4 OBJECTIVES & SPECIFICATIONS
A set a guidelines, design objectives, and performance specifications was
established to assist the team in properly assessing on how successful the outcome of the
project is. The following section of the chapters will go through the different objectives,
specifications, and guidelines that the team agreed upon.
4.1 Design Objectives
There are a number of design objectives that required the attention of the team.
These objectives have to be specified in order for the team to have a list of goals and aims
to achieve. These objectives are listed below:
1) The first objective of the design project is to design a system that will be able to
receive desire velocities and steering angles from the G-CART guidance system.
2) The second objective is to design the system such that it will also be able to process
encoder data to maintain knowledge of all motor positions.
3) The third objective is to design the system in a way such that the system, given the
input above, will be able to drive the steering motor to turn the wheel to the desired
angle positions.
4) The system, given the input above, should be able to control the car’s acceleration
and braking system to achieve the velocities requested by the navigation computer.
5) The systems should be designed in modules for the purpose of modular testability and
for the ease of system expansion.
6) The final objective is to ensure that the systems operate reliably and swiftly.
4.2 Performance Specifications
The DARPA Grand Challenge is an autonomous vehicle competition. The
contest requires contestants to successfully create an autonomous vehicle capable of
traversing a timed 175 mile off road desert race. Additionally, vehicles must be able to
stay within given GPS boundary points while avoiding various natural and man-made
obstacles without causing any damage to the course. While the overall task may seem
daunting, our concern is on a much smaller scale. The scope of this project required the
design considerations of three separate entities. These three entities were the steering
control system, the speed control system, and the communication bus that connects the
Navigation computer to the various subsystems.
4.2.1 Steering control performance specifications
4.2.1.1 The response of the steering system, at a minimum, shall respond as quickly as a human operator.
4.2.1.2 The steering system shall be capable of controlling a wide selection of DC permanent magnet motors.
4.2.1.3 The system shall be flexible enough to be able to easily be installed in comparable vehicles.
4.2.1.4 The steering system shall minimize the error between the desired wheel angle and the measured wheel angle.
4.2.2 Speed control performance specifications
4.2.2.1 The speed control system shall minimize the error between the measured speed and desired speed.
4.2.2.2 The system shall effectively stop the vehicle in response to a zero velocity command.
4.2.2.3 The system shall be capable to use the emergency brake to stop the vehicle in the case of power loss, communication timeout, or loss of brake response.
4.2.3 Communication performance specifications
4.2.3.1 In the event of a communication timeout with the guidance system, the vehicle speed control system will quickly bring the vehicle to a complete halt until communications are reestablished.
It is inevitable that as the project continues, the team will face numerous obstacles
and problems. However due to time constraints, not every issue will be addressed. By
having a list of performance specifications, it will aid the team in prioritizing what is
crucial. This will help manage time more wisely into what problems must be fixed and
which obstacles the team can overlook.
4.3 Safety Issues
Electrical and Mechanical Safety
The senior design team followed a well established MIT safety Codes to ensure the safety of
the team members.
Electrical Safety
To safeguard against injury when using electrical equipment, requirements and standards
have been established through the implementation of nationally recognized codes, approval tests
and electrical safety work practices.
All electrical equipment should be installed and maintained in accordance with the
following standards:
OHSA Regulations – 29 CFR 1910 (http://www.ohsa.gov)
Underwriter Laboratories (http://www.ul.com)
National Fire Protection Association (http://www.nfpa.org)
(NFPA) 70E, Electrical Safety Requirements for Employee Workplaces
Wiring
All electrical installations or the replacement, modification, repair or rehabilitation of any
electrical installation must comply with the requirements of the National Electrical Code (NEC)
of the National Fire Protection Association, and/or the U.S. Department of Labors’ Occupational
Safety and Health Administration.
Grounding
All equipment should be grounded and fused in accordance with NEC. All extension and
power cords must have a grounding pin.
Insulation
All electrical equipment should be properly insulated. Any power cords that are frayed must
be discarded and any live/hot wires should be insulated to prevent danger of electrical shock.
National Consensus Standards for Design and Installation
All electrical equipment should be installed and maintained in accordance with the
following standards:
OHSA Regulations - 29 CFR 1910
Underwriter Laboratories
National Fire Protection Association
(NFPA) 70E, Electrical Safety Requirements for Employee Workplaces
Standards on electrical products and systems, such as the National Electrical
Manufacturers Association (NEMA) www.nema.org and ASTM American Society for
Testing and Materials. www.astm.org
Institute of Electrical and Electronic Engineers (IEEE) "Color Book Series" - design of
electrical power systems for industrial and commercial facilities
National Fire Protection Association (NFPA) 70
National Electrical Code (NEC)® -supported by the NFPA provides electrical safety
requirements for wiring methods used in the workplace, for live electric supply and
communication lines and equipment for employees in the workplace.
Factors Involved in Electrical Shock
THE QUANTITY OF CURRENT FLOWING THROUGH THE BODY
Current (amperes) is the killing factor in electrical shock, not the voltage. The voltage
only determines how much current will flow through a given body resistance. In general,
the body's resistance to electrical shock is minimal (150,000 to 600,000 Ohms.) Even
contact with standard 110-volt circuits can be lethal under certain conditions. Refer to
the chart below.
THE CURRENT PATH THROUGH THE BODY FROM ENTRY TO EXIT
Hand-to-hand, hand- or head-to-foot, and ear-to-ear current paths are the most dangerous
because they may cause severe damage to the heart, lungs and brain. This is why it is
important not to wear metal jewelry, not to lean against or use both hands on electrical
equipment so as not to become part of the circuit.
THE LENGTH OF TIME THE BODY IS IN THE CIRCUIT
The longer the body is in the circuit, the greater the damage. You may be unable to let go
of a 15 to 20 milli-ampere current. The body temperature may increase possibly
damaging tissues, bones, and organs.
CURRENT IN
MILLIAMPS
EFFECTS OF 60 HZ CURRENT PASSING THROUGH
THE BODY
1 or less 5 May not be felt - Maximum harmless intensity
1 to 8 Sensation of mild shock, can let go at will
8 to 15 Painful shock, muscles contract, may still be able to let go
15 to 20 Painful shock, can NOT let go
20 to 75 Intense pain, breathing may be paralyzed
100 to 200Ventricular fibrillation; holds unconscious victim to the
circuit, could be fatal
200 or moreHeart stops, muscles contract intensely & could break bones,
severe burns, breathing stops
Electrical Safety Reminders
Re-route electrical cords or extension cords so they don't run across the aisle/corridor or
over pipes or through doors.
Turn off and unplug equipment before removing the protective cover to clear a jam,
replace a part, etc.
Don't use an electrical outlet or switch if the protective cover is ajar, cracked, or missing.
use dry hands and stand on a dry surface when using electrical equipment.
Remove any combustible materials, such as paper and wood from the area. Be sure
flammable liquids and gases are secured away from the area when the appliance is in use.
Never put conductive metal objects into energized equipment.
Remove cord from the outlet by pulling the plug instead of pulling on the cord.
Don't carry equipment by the cord - only by the handle or base.
Be sure extension cords are properly rated for the job and used only temporarily.
Use extension cords with 3-prong plugs to ensure the equipment is grounded. Never
remove the grounding post from a 3-prong plug so you can put it into a 2-prong.
Don't overload extension cords, multi-outlet strips or wall outlets.
Take seriously any warning signs, barricades or guards posted when electrical equipment
is being repaired, installed, etc.6
Additional Safety Procedures when working with G-Cart Vehicle
When testing the vehicle in an enclosed area, appropriate ventilation must be present
to avoid the inhalation of toxic fumes produced by the vehicle emissions.
The vehicle must be equipped with an easily accessible ignition kill button that
immediately stops the engine.
Initial testing of the throttle position control system must be preformed with the
engine disabled.
The vehicle speed control system must be proven effective prior to vehicle
movement testing. As an additional precaution, the emergency brake system must be
fully tested and operation prior to vehicle movement testing.
The emergency brake must be engaged when the vehicle braking system can not
effectively bring the vehicle to a complete stop.
In the event of a communication timeout with the guidance system, the vehicle
speed control system must quickly bring the vehicle to a complete halt until
communications are reestablished.
5 Final Design
5.1 Steering Design and Simulation
5.1.1 Steering Control Final DesignThe steering system communicates with external systems through an Ethernet connection
via TCP messaging. In general, the steering control system receives angular position commands
from a navigation computer system. A closed looped servo system was designed to accurately
achieve the desired steering position. The design includes the use of a NI real-time controller, a
NI Flex Motion Control card, an NI servo drive and a permanent magnet DC motor with a
position encoder. The NI Flex Motion Control card runs a PID based closed-loop at a 62.5
microsecond period. The powerful functionality of the dedicated motion control card off-loads
complex motion functions from the real-time controller for improved system performance. The
servo drive uses a PWM signal with a frequency of 32 kHz to drive the DC motor. The new
steering position command is feed to the NI Flex Motion Controller at a rate of 20 new position
commands per second. A block diagram of the system can be observed in Figure 5.1.
Figure 5.1: Steering Control System
5.1.2 Motor Analysis
There are many types of motors that can be used for steering as listed below, with many
advantages and disadvantages as briefly described below. Although in the end with the limited
budget we were forced to make the best of donated motors.
2 Phase DC Motor (with Brush/ Brushless)
3 phase DC motor (with Brush/ Brushless)
Multi–phase DC motor (with Brush/ Brushless), which is similar to a stepper
motor.
Stepper motor
The brush motor concept does not rely on controlled commutation to run, because the
brushes provide a mechanical commutation. However, this motor does not have as high
reliability as a brushless DC motor. Brush life may limit the lifespan of a Brushless DC motor.
The Brushless DC motor does not have the same lifespan concerns due to the absence of
mechanical contact inside the motor. An extended reliability is thus obtained.
The stepper motor for this application does not have the holding torque for our
applications therefore a stepper motor would be a poor decision for these systems.
For the final design we were donated the following motors to be used in the listed
assemblies. The list contains specifications that were obtained through manufacturing specs or
through testing.
Table 1: Motor SpecificationAssembly using
motor Steering Brake ThrottleMake of motor Ametek-Lamb Electric Bosch Brevel
Model of motor 116308-02904-
190600 713Operating Voltage
(V) 12* 12 12No Load Speed
(RPM) 590 75 -Stall Current (A) 9* 44 -
Continuous Current (A) 3.5* - -
Stall Torque (Ft-Lb) - 25 -* As tested by the G-Cart team
5.1.3 H-Bridge and PWM
Figure 5.2: System Block Diagram
Full-Reverse
Full-Forward
Figure 5.3: PWM Signals
System Description:As shown in Figure 5.2, the DC servos motor was driven by the PWM signal, which
provided a 50Hz square wave at 5% and 10% of duty cycle. The victor 883 bridge received the
PWM signals and translated the signal to DC output voltages. The bridge was used to supply
appropriate DC voltages to the DC motor. As shown in Figure 5.3, the motor rotated at full
+ 12V DC motor--
+ -
Victor 883Bridge
12V Power Supplier
PWM driver
10% duty cycle =2msPWM
GND
50 Hz (period = 20ms)
5% duty cycle =1ms
10% duty cycle =2msPWM
50 Hz (period=20ms
PWM Signals output from PWM driver
reverse state when supplied with PWM at 5% duty cycle. The motor reached Full-Forward
speed, when 10% duty cycle PWM was supplied. At 7.5 duty cycle PWM input, the motor stops.
Table 2: PWM input vs. motor angular velocityInputs (PWM duty cycle) DC motor response
5% Full-Reverse Speed7.5% Stop10% Full-Forward Speed
The following plot displays the relationship between PWM input and DC output of the Victor
883 bridge.
Figure 5.4: PWM % duty cycle vs. output voltage
PWM % duty cycle VS. output voltage
-15
-10
-5
0
5
10
15
0 2 4 6 8 10 12
Victor input PWM duty cycle (%)
Vict
or 8
83 o
utpu
t DC
volta
ge
PWM % duty cycle VS. output voltage
Victor 883 Bridge
Figure 5.5: Victor 883 technical drawing
5.1.4 Optical Encoder ResearchThe encoders used were the EM1 and HEDS transmissive optical encoder modules with code-
wheels from U.S. Digital Corporation. An example of one of these optical quadrature encoders
can be seen in Figure 5.6.
Figure 5.6: US Digital Optical Quadrature Encoder
Quadrature encoders typically consist of a spoked pickup wheel attached to the mechanical input.
The spokes pass through a pair of optical interruption sensors consisting of one led and one light
sensor, one led and two light sensors, or one light sensor and two modulated LEDs. The device
generates a pair of phase shifted output streams. The direction of movement can then be
determined by determining whether the A or B signal stream is leading. The EM1 and HEDS
come with a third channel, the index channel, that is used to establish an absolute mechanical
reference position within one encoder count of the 360° encoder rotation. The index signal can
be used to do several tasks in the system. It can be used to reset or preset the position counter
and/or generate an interrupt signal to the system controller.
Figure 5.7: X1 Encoding Waveform Diagram
Figure 5.8: X2 Encoding Waveform Diagram
Figure 5.9: X4 Encoding Waveform Diagram
Three types of encoding can be used on the quadrature encoders: X1, X2, and X4. The basic
difference between the schemes is that X1 encoding counts once per cycle, X2 counts twice per
cycle, and X4 counts four times per cycle. By counting more times per cycle, X4 is appropriate
for high resolution applications. X1 encoding on the other hand, is less susceptible to noise,
because the count is only executed once per cycle. Since the application did not require
measurement of extremely high resolution, X1 encoding was chosen for the project.
5.2 Speed Control Design and Simulation
5.2.1 Speed Control Final Design
Originally, for the proposed G-CART vehicle, both throttling and braking system
were to be done “by-wire.” With a “by-wire” system, the vehicle’s throttle and brake
would be adjusted by a voltage signal from the motion control system to the car’s ECU.
However, lack of funding resulted in the need to use the existing vehicle. The existing
vehicle was a 1991 Geo Storm which lacked “by-wire” capabilities. Therefore, a drastic
change was needed for the design.
Since a CAN system was on the vehicle, other means to measure the vehicle
speed was needed. The velocity control system designed for this project monitors the
desired vehicle speed from the communication bus and attempts to achieve this speed
quickly and smoothly. The system interfaces with the vehicle’s speedometer cable in
order to monitor the current speed. The speedometer cable is mounted to a high precision
encoder, which provides 65,536 counts per mile. The mounting specifications on the
encoders were the biggest challenge to mounting the encoders. The disc has to be
mounted with a maximum run-out specification of 0.004” and axial play of 0.010” or
less. To achieve these specifications the encoder is rigidly mounted to the same plate as
the adapter. The bearing also has to be able to operate at 1,000 RPM with a minimal
axial or radial load. Also the machining of the adapter had to be very precise to alleviate
any run-out. An exploded view of the speedometer assembly can be seen in Figure 5.10.
The assembly consists of the speedometer cable, encoder, adapter, bearing and mounting
plate.
Figure 5.10: Vehicle Velocity Encoder Mount and Assembly
The output of the velocity control system is the actuation of two motors, which
control the vehicle’s brake pedal and throttle plate. The brake motor was mounted to the
floor panel of the car, and the throttle motor rigidly mounted to the motor and coupled to
the throttle plate. The two assemblies can be seen in Figure 5.11 and Figure 5.12. The
brake assembly consists of the mounting bracket, adapter, encoder and cam. The throttle
assembly consists of the encoder, mounting plate, adapter, motor, coupler and the throttle
plate. The same mounting specifications required for the vehicle velocity encoder were
also employed when designing the throttle and braking assemblies. In addition to the
given encoder mounting specifications, consideration of the flexing of the L-bracket
assembly lead to a design in which the encoder was rigidly attached to a plate central to
both the motor and encoder. This allows the encoder move to move in tandem with the
motor shaft in the event of the plate flexing. Also, to help minimize run-out caused by
the shaft flexing when the brake is depressed, the encoder was mounted on the shaft as
close to the motor as possible. The actual method of actuating the brake is done with the
use of the cam mounted on the motor. When the motor shaft rotates the cam action
depresses the brake pedal to the desired position. The throttle assembly is directly
attached to the throttle plate so the plate can be rotated by the motor to effectively
achieve the desired position.
Figure 5.11: Braking Motor Mount with Position Encoder
Figure 5.12: Throttle Motor Encoder Mounting and Assembly
The velocity controller monitors both the desired and actual speed of the vehicle
and decides an appropriate position for both the brake and the throttle motor. This is
done in a method designed to minimize brake usage, in order to limit the amount of
brake-pad wear that will occur during the race. Our controller design is similar to that of
a modern cruise control system. If our actual speed is below the desired speed, our
controller will gradually increase the throttle position until the car speed increases to an
appropriate level. If the actual speed is over the desired speed by a small margin, the
controller will first decrease the throttle and let the car ‘coast’ down to the desired speed.
The brake will only be actuated if the actual speed is above the desired speed by a certain
threshold. For our system, this threshold is set to be ten percent of the current vehicle
speed. This allows for tighter control of the vehicle’s velocity at low speeds, and more
flexibility at higher speeds.
Figure 5.13: Velocity Control System
Figure 5.14: Brake Control System
5.3 PID Controller DesignThe PID Controller design was a very easy integration into the controller. LabVIEW has a
manual dedicated to the explanation of PID controllers which made the task easier. Equation 1
shows the formula used for calculating error in the Throttle Control Sub-System. represents
the set point, while represents the full range of possible set points. represents the
process variable or feedback for the system. is the linearity factor that produces a non-linear
gain term. For a linearity value of one, the controller is completely linear.
(1)
The controller output is equal to the sum of the proportional, integral, and derivative
action as seen in Equation 2. The proportional term is simply computed using Equation 3. The
advance PID algorithm used for the throttle control system also uses Trapezoidal Integration to
avoid sharp changes as a result of sudden changes in the process variable or set point. The
integral action equation can be observed in Equation 4. A partial derivative action was employed
for the computation of the derivative term, as can be seen in Equation 5.
(2)
(3)
(4)
(5)
The design objectives for selecting the PID parameters for the Throttle Control Sub-
System were to achieve extremely fast response with minimal to no overshoot. The after
extensive tuning and testing, the following PID parameters were selected for the Throttle Control
Sub-System: L=0.7, Kp=0.12, KI=0.02, Kd=0.0007. The derivative sampling period was
equivalent to the loop time of 1ms. The measured step response can be observed in Figure 5.15.
Due to the large dead zone of the motor, some small oscillations can be observed when the
measured position settles to the desired position. These oscillations are within 2% of the desired
set point.
Figure 5.15: The measured throttle motor step response when installed in the vehicle.
Ts = 96ms, Max Overshoot = 1.5%
For the Braking Control System the following PID parameters were utilized: L=1,
Kp=700, KI=6, Kd=32767. For the Braking Control System, the derivative sample period was set
6 cycles or 325 microseconds. The measured step response representing the transition from zero
to full brake depression can be observed in Figure 5.16. For the braking system, a more liberal
overshoot of 10% was deemed acceptable. A very small steady state error was required for this
application, as small changes in brake pedal position can result in shape changes in velocity. In
the final application, the servo loop actually uses velocity and acceleration control for trajectory
moves. Thus the overshoot in the final application will actually be much less than 1%.
Figure 5.16: The measured brake motor step response when installed in the vehicle.
Ts = 432ms, Max Overshoot = 10%
The Steering Control System also utilizes a PID algorithm similar to the Braking Control
system. Delays from other affiliate teams have precluded system testing and PID tuning at this
point.
5.4 Communication Protocol
Communication between the navigation computer and the controller bus master (CBM)
level is handled by two protocols, both of which are transmitted over an Ethernet connection. A
UDP protocol is used for peer identification across the network. Our system broadcasts a simple
identification packet on this protocol and listens for broadcasts from other systems. By
monitoring these broadcasts our system updates a list of active IP addresses on the network.
This method of identification allows for our system to react if another system node fails. When
another node fails it will stop broadcasting discovery packets, and after a timeout of two seconds,
it will be removed from our table of active system IP addresses. Likewise, if our node was to
fail, other system nodes would be alerted to the failure.
After the UDP protocol has initialized and discovered active IP addresses on the network,
those addresses are used to actively monitor data communication over a separate TCP protocol.
This TCP protocol can handle up to ten simultaneous connections with different system nodes.
Each connection is bi-directional and allows for the transmission of various commands, data, and
system flags.
Table 3 lists the various types of communications that occur between system nodes.
Each TCP connection simultaneously writes and reads data as needed until a TCP error is
detected. Such an error is most likely caused by a system node failure. In the case of a read TCP
connection failure, the system closes the respective TCP port and returns to listening for valid
data. Similarly, in response to a write TCP failure, the TCP connection is closed and then
attempts are made to open a new TCP connection unless the system is removed from the list of
active IP addresses.
Type Code Description0x01 #Ethernet Data0x02 #Error Broadcast0x03 #Error Acknowledgement*0x04 #Error Quench*0x05 #Error !Quench *0x06 #Discover0x07 #Discover Acknowledgement0x08 #Source Quench0x09 #Reboot*0x0A #Ethernet Data Request0x0B #Ethernet Data Quench
0x0C #Node Locate0x0D #Node Acknowledge0x0E #Ethernet Requested Node DataTable 3: TCP Communication Types*These communication types only originate from the navigation computer to the CBM level, therefore our system does not have the ability to send these types.
5.5 Testing and Integration
Testing and integration was arguably the most important and time consuming task. There
were several different components that needed to be individually tested before they could be
integrated to the control system. While it was possible to test most of the equipment
independently, the final system required some components to control others. Therefore, it
became important to test each of the components systematically.
The testing of the control system came in several different phases. The first phase was initial
communication testing to verify the UDP discovery process. Some minor coding errors were
resolved and the UDP discovery process was validated with multiple computers. Next, TCP
commands were tested. After some modifications to which ports were used for reading and
writing to multiple computers, it was discovered that some other devices that would be
communicating with the motion control system were incapable of handling multiple TCP
connections by listening on a single port. Thus the specifications were modified to allow for
individual port numbers to be assigned for each system. A full communications system test has
still not been completed due to delays incurred by other teams. Thus our completed
communications hardware and software will not be fully tested and validated until other
affiliated teams are prepared for testing.
Meanwhile, parallel to communication verification, the optical encoders and the software to
control the motors needed to be tested. While it was assumed that the encoders would work, it
was necessary to confirm that the software would properly read the encoders so that accurate
counts could be made. The first motor to be tested was the throttle motor. Initially, it was
powered through the National Instruments servo drive. After it was establish that the encoder
accurately controlled the position of the motor, the motor was then powered through the H-
bridge. At first the H-bridge did not work properly. Instead of being able to rotate both
clockwise and counter-clockwise, the motor would only turn in one direction. However, it was
soon realized that the range set on the H-bridge was not properly calibrated. As soon as it was
properly configured, the H-bridge correctly drove the throttle motor in both forward and reverse
directions. The brake motor also needed to be tested. Due to its need for a high current for
greater torque, the current limit on the servo drive had to be put at the maximum setting in order
for the motor to produce the required torque. However, a situation arose with the motor during
initial closed-loop testing. The provided motor and encoder mounting hardware did not properly
hold the encoder optical reader perpendicular to the motor shaft. As a result of this
misalignment, the encoder disk and reader were damaged during testing. The order for a new
optical encoder delayed brake testing. The motor and encoder mount was redesigned by a
member of our senior design team to avoid further problems. Once the new encoder was
mounted onto the brake motor, the testing went flawlessly.
Once independent testing of the various components were accomplished, it became necessary to
integrate each of them onto the car and test their ability to control the car. Experimentation had
to be done with each of the motors to find the critical PID gain parameters needed by the system
to control the motors. Because of budgetary constraints, many of the motors used for the design
were used older models. The motor manufactures had, in several cases, gone out of business and
data sheets with motor parameters were impossible to obtain making mathematical modeling of
the motors was impractical. Thus an experimental approach was taken in determining the PID
gain values. The throttle motor was one of the first motors to be tested in the vehicle. The motor
was connected directly to the butterfly flap of the car. The butterfly flap had ninety degrees of
motion from fully closed to full throttle. Initial tests of the throttle motor turned out to be better
than expected. Therefore, an initialization sequence was tested on it. The initialization sequence
assumed the worst case scenario for the position of the throttle motor on start up. On start up,
the sequence would rotate the butterfly flap to fully closed. Once closed, the position of the
encoder would be reset to zero degrees in the control program. After testing of the throttle
motor, the steering motor was next. For the steering control, an existing assembly designed by
members of the G-CART club last year was used to connect and appropriately gear the steering
motor to the steering column. The existing assembly used chains to fasten the gears together.
Initial testing showed that the chains were not tight enough and sometimes came loose.
Modifications were made to the assembly to tighten the chains. The initial testing and
calibration of the steering motor proceeded quite well. In subsequent testing, it was discovered
that at some points the optical encoder was skipping many counts. A flawed encoder mounting
design allowed the optical reader to move with respect to the steering column when the steering
motor was operating. Modifications are currently underway to improve the optical reader mount
so that it is rigidly mounted.
5.6 Budget
Description Manufacturer Part # Quantity CostH-Bridge Servo Drive IFIRobotics Victor 883 1 Donated
Throttle Encoder US Digital E2-1024-250-IHG 1 $25.63Brake Encoder US Digital E3-1000-500-IHM 1 $60.30Steering Encoder US Digital E3-1024-750-IHM 1 $64.30Vehicle Velocity Encoder US Digital E3-64-750-IHG 1 $64.30Steering DC Motor Ametek - Lamb Electric 116308-02 1 Donated
Throttle DC Motor Brevel Motors Inc. 713 1 Donated
Brake DC Motor BOSCH 904-190600 1 Donated
PXI-1031, 4-Slot 3U Chassis with Universal AC Power Supply National Instruments 778932-01 1 Donated
PXI-1031 Rack Mount kit National Instruments 778948-01 1 Donated
AC Power Cord, 2.29 m, U.S. 120 VAC, Japan 100 VAC National Instruments 763000-01 1 Donated
NI PXI-6281 M Series Multifunction DAQ and NI-DAQ Software National Instruments 779121-01 1 Donated
SCB-68 Noise Rejecting, Shielded I/O Connector Block National Instruments 776844-01 1 Donated
NI PXI-8463 Single Wire Series 2 CAN, 1 Port, 9 Pin DSub National Instruments 778780-01 1 Donated
NI PXI-7352 2-Axis Flexmotion Stepper/Servo Motion Controller National Instruments 778540-02 1 Donated
MID-7652, Integrated 2 Axis Servo Drive w/Power Supply,US,120V National Instruments 778004-01 1 Donated
SHC68-C68-S, 68 pin VHDCI to 68 pin VHDCI, 2m National Instruments 186380-02 1 Donated
NI PXI-8186 P4 2.2 GHz Controller with LabVIEW Real-Time National Instruments 778755-33 1 Donated
LabVIEW Full Dev System for Win 2000/NT/XP (English) National Instruments 776670-03 1 Donated
LabVIEW Real-Time Module (ETS) for Windows National Instruments 777844-03 1 Donated
SH68-68-EP Shielded Cable National Instruments 184749-02 1 Donated
Total Cost: $214.53
The Budget table demonstrates the value of donations. Our system is worth more than
the vehicle it is installed in. Without National Instrument’s generous contributions, we would
not have a project. As a result of limited budget constraints, we were forced to incorporate parts
that were salvaged from other projects as well as the RIT’s robotics lab. Overall, the project
relied heavily on donations from many companies.
6 CONCLUSION
The senior design team focused the six facets of design: Recognizing and
Quantifying Needs, Concept Development, Feasibility Assessment, Design Objectives
and Performance Specifications, Synthesis and Analysis, and final Design.
The goal of this senior design team was to provide engineering assistance to the
RIT G-CART club in the development of vehicle steering and speed control. Our
engineering knowledge as 5th year electrical and mechanical students proved to be very
helpful to the RIT G-CART club which has many younger members. Our senior design
team was able to bring a more formal design process to the table and help to organize the
different facets of the design process for the greater G-CART project.
Extensive research and concept development efforts were undertaken. Our design
process was forced to be very flexible as many factors were influencing our design
choices. The RIT G-CART club is still in the process of obtaining a vehicle for the race.
Since a vehicle was unable to be attained in time for the original designs using CAN and
a throttle/brake-by-wire system, a major design change was necessary. This very late
change in design made time even more of a constraint than usual. Also, the current
vehicle’s lack of a CAN system forced the control system to be very flexible. Despite
unforeseen changes, a very limited budget, and many other constraints, the control
system is on track and fully capable of meeting all the goals and specifications required.
Full system testing has been precluded by numerous delays that were incurred by affiliate
teams. All systems have been tested independently, however full system testing is still to
be completed.
This has design team has proven its flexibility by completely adapting the design
to a vehicle not originally slotted as a possible candidate for the competition. It required
many compromises from both the senior design team and the G-CART team. Through
all affiliate team members dedication, a working system has been created and soon to be
fully tested.
7 REFERENCES
[1] LabVIEW PID Control Toolset User Manual. National Instruments Corporation, 2001.
[2] US Digital encoder data. http://www.usdigital.com/products/em1-heds/index.shtml
[3] Nice Specialty Ball Bearings (2005 catalog). http://www.rbcbearings.com/designeng-
nice.pdf
[4] NI-DAQ 7 Device Documentation CD’s. NI-DAQmx Help Quadrature Encoders.
[5] IFI ROBOTICS. 24V Victor 883 (H-Bridge). http://www.IFIrobotics.com.
[6] MIT Safety Codes. http://web.mit.edu/enviornment/ehs/electrical_mechanical.html
8 APPENDIX
8.1 Software Charts
Figure 8.17: Motion Control Input/Output
Figure 8.18: UDP Discovery Process
Figure 8.19: TCP Communication Read
Figure 8.20: TCP Communication Write
Figure 8.21: Servo Loop
Figure 8.22: Hardware Block Diagram
8.2 LabVIEW Screenshots
Figure 8.23: LabVIEW Front Panel
Figure 8.24: PXI Control Code
Figure 8.25: Throttle Control Front Panel
Figure 8.26: Throttle Control Code