G-CART Autonomous Navigation and Controls
G-CART Autonomous Navigation and Controls
Senior Design Team 05107
[pic]
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 5
1.1 Mission Statement 5
1.2 Project Description 5
1.3 Scope Limitations 6
1.4 Stakeholders 8
1.5 Key Business Goals 8
1.6 Primary Market 8
1.7 Secondary Market 9
1.8 Innovation Opportunities 9
1.9 Background Research 9
1.10 Formal Statement of Work 10
2 CONCEPT DEVELOPMENT 11
2.1 Subgroup 12
2.2 Bus Architecture Concepts 15
2.3 Steering Concepts 22
2.4 Velocity Control Concepts 27
2.5 Emergency Brake Concepts 36
3 FEASIBILITY 39
3.1 Bus Architecture Feasibility 40
3.2 Steering Feasibility 41
3.3 Speed Control Feasibility 43
3.4 Feasibility Conclusion 46
4 OBJECTIVES & SPECIFICATIONS 47
4.1 Design Objectives 48
4.2 Performance Specifications 48
4.3 Safety Issues 50
5 Final Design 55
5.1 Steering Design and Simulation 55
5.2 Speed Control Design and Simulation 62
5.3 PID Controller Design 66
5.4 Communication Protocol 69
5.5 Testing and Integration 71
5.6 Budget 74
6 CONCLUSION 75
7 REFERENCES 76
8 APPENDIX 77
8.1 Software Charts 77
8.2 LabVIEW Screenshots 80
Index of Figures
Figure 5.1: Steering Control System 56
Figure 5.2: System Block Diagram 58
Figure 5.3: PWM Signals 58
Figure 5.4: PWM % duty cycle vs. output voltage 59
Figure 5.5: Victor 883 technical drawing 60
Figure 5.6: US Digital Optical Quadrature Encoder 60
Figure 5.7: X1 Encoding Waveform Diagram 61
Figure 5.8: X2 Encoding Waveform Diagram 61
Figure 5.9: X4 Encoding Waveform Diagram 61
Figure 5.10: Vehicle Velocity Encoder Mount and Assembly 63
Figure 5.11: Braking Motor Mount with Position Encoder 64
Figure 5.12: Throttle Motor Encoder Mounting and Assembly 64
Figure 5.13: Velocity Control System 65
Figure 5.14: Brake Control System 66
Figure 5.15: The measured throttle motor step response when installed in the vehicle. 68
Figure 5.16: The measured brake motor step response when installed in the vehicle. 69
Figure 8.1: Motion Control Input/Output 77
Figure 8.2: UDP Discovery Process 78
Figure 8.3: TCP Communication Read 78
Figure 8.4: TCP Communication Write 79
Figure 8.5: Servo Loop 79
Figure 8.6: Hardware Block Diagram 80
Figure 8.7: LabVIEW Front Panel 81
Figure 8.8: PXI Control Code 81
Figure 8.9: Throttle Control Front Panel 82
Figure 8.10: Throttle Control Code 83
RECOGNIZE AND QUANTIFY NEEDS
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.
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
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.
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
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.
6 Primary Market
• D.A.R.P.A is the host of the race
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
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
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.
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.
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.
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.
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 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.
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.
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 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.
[pic]
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.
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 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.
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.
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.
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.
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.
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.
3 Steering Concepts
1 DC Drive Concepts
Many different approaches were researched, although the final concepts were restricted by the final motor selection.
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:
[pic]
Figure 2.3.1.1.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 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.
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 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.
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.
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.
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 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.
[pic]
Figure 2.4.2.1
[pic]
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.
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.
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.
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.
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.
[pic]
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.
[pic]
Figure 2.5.1.2
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.
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.
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 |Relative Weight |I2C |USB |PXI |IEEE1384 |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.
2 Steering Feasibility
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.
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 |Relative |FPGA |Microcontroll|NI Real Time |
| |Weights |Controller |er |Controller |
|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 Speed Control Feasibility
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.
2 Velocity Control Feasibility
1 FPGA
For 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.
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 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.
[pic]
Figure 3.3.3.1
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.
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.
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.
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.
1 Steering control performance specifications
1 The response of the steering system, at a minimum, shall respond as quickly as a human operator.
2 The steering system shall be capable of controlling a wide selection of DC permanent magnet motors.
3 The system shall be flexible enough to be able to easily be installed in comparable vehicles.
4 The steering system shall minimize the error between the desired wheel angle and the measured wheel angle.
2 Speed control performance specifications
1 The speed control system shall minimize the error between the measured speed and desired speed.
2 The system shall effectively stop the vehicle in response to a zero velocity command.
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.
3 Communication performance specifications
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.
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 ()
Underwriter Laboratories ()
National Fire Protection Association ()
(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) and ASTM American Society for Testing and Materials.
• 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 200 |Ventricular fibrillation; holds unconscious victim to the circuit, could be fatal |
|200 or more |Heart 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.
Final Design
1 Steering Design and Simulation
1 Steering Control Final Design
The 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.
[pic]
Figure 5.1: Steering Control System
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 Specification
|Assembly using motor |Steering |Brake |Throttle |
|Make of motor |Ametek-Lamb Electric |Bosch |Brevel |
|Model of motor |116308-02 |904-190600 |713 |
|Operating Voltage (V) |12* |12 |12 |
|No 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 | | |
3 H-Bridge and PWM
[pic]
Figure 5.2: System Block Diagram
Full-Reverse
[pic]
Full-Forward
[pic]
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 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 velocity
|Inputs (PWM duty cycle) | | DC motor response |
|5% | |Full-Reverse Speed |
|7.5% | |Stop |
|10% | |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
[pic]
Figure 5.5: Victor 883 technical drawing
[pic]
4 Optical Encoder Research
The 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.
[pic]
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.
[pic]
Figure 5.7: X1 Encoding Waveform Diagram
[pic]
Figure 5.8: X2 Encoding Waveform Diagram
[pic]
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.
2 Speed Control Design and Simulation
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.
[pic]
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.
[pic]
Figure 5.11: Braking Motor Mount with Position Encoder
[pic]
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.
[pic]
Figure 5.13: Velocity Control System
[pic]
Figure 5.14: Brake Control System
3 PID Controller Design
The 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. [pic]represents the set point, while [pic]represents the full range of possible set points. [pic]represents the process variable or feedback for the system. [pic]is the linearity factor that produces a non-linear gain term. For a linearity value of one, the controller is completely linear.
[pic] (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.
[pic] (2)
[pic] (3)
[pic] (4)
[pic] (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.
[pic]
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%.
[pic]
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.
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 |Description |
|0x01 |#Ethernet Data |
|0x02 |#Error Broadcast |
|0x03 |#Error Acknowledgement* |
|0x04 |#Error Quench* |
|0x05 |#Error !Quench* |
|0x06 |#Discover |
|0x07 |#Discover Acknowledgement |
|0x08 |#Source Quench |
|0x09 |#Reboot* |
|0x0A |#Ethernet Data Request |
|0x0B |#Ethernet Data Quench |
|0x0C |#Node Locate |
|0x0D |#Node Acknowledge |
|0x0E |#Ethernet Requested Node Data |
Table 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 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.
6 Budget
[pic]
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.
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.
REFERENCES
[1] LabVIEW PID Control Toolset User Manual. National Instruments Corporation, 2001.
[2] US Digital encoder data.
[3] Nice Specialty Ball Bearings (2005 catalog).
[4] NI-DAQ 7 Device Documentation CD’s. NI-DAQmx Help Quadrature Encoders.
[5] IFI ROBOTICS. 24V Victor 883 (H-Bridge). .
[6] MIT Safety Codes.
APPENDIX
1 Software Charts
[pic]
Figure 8.1: Motion Control Input/Output
[pic]
Figure 8.2: UDP Discovery Process
[pic]
Figure 8.3: TCP Communication Read
[pic]
Figure 8.4: TCP Communication Write
[pic]
Figure 8.5: Servo Loop
[pic]
Figure 8.6: Hardware Block Diagram
2 LabVIEW Screenshots
[pic]
Figure 8.7: LabVIEW Front Panel
[pic]
Figure 8.8: PXI Control Code
[pic]
Figure 8.9: Throttle Control Front Panel
[pic]
Figure 8.10: Throttle Control Code
-----------------------
50 Hz (period=20ms
5% duty cycle =1ms
50 Hz (period = 20ms)
PWM Signals output from PWM driver
GND
PWM driver
12V
Power
Supplier
+ -
Victor 883
Bridge
+
12V DC motor
-
-
10% duty cycle =2ms
PWM
Victor 883 Bridge
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- use of portable hepa filtered ventilation
- final empire part 1 the history of disintegration
- resource guide for non builder owners of canard composite
- environmental law outline
- 1986 trooper le 2 door
- he explained to me the m yola
- manual pearson education
- the last whole earth catalog simplyscripts
- chapter i schram
- g cart autonomous navigation and controls
Related searches
- chevy sun and navigation package
- g ml to g liter
- g l to g ml converter
- p and g dividend history
- 1880 g to lbs and oz
- prophets and kings by ellen g white
- g x and f x calculator
- instrumentation and controls books pdf
- instrumentation and controls training course
- free instrumentation and controls training
- e g white prophets and kings
- johnson controls valves and actuators