EGR 450 Project Final Report:  Crash Barrier Control Project

Overview

The purpose of this project was to control a hydraulically powered system for impacting and testing bumper systems.  These impacts help determine crashworthiness of a bumper system or a proposed change to a bumper system.  The hydraulics retract a large cylinder with a pulley on the end.  Around the pulley is a metal cable connected to a "trolley" on a single row of railroad-style track.  The trolley has a lever which connects to the crash vehicle.  With the trolley connected to the car, the pressure up, and the system activated the vehicle speeds toward a rigid wall.  On the wall is mounted load cells and a deflection measurement device.  These are necessary bits of data necessary for determining whether or not the bumper system will pass the requirements pressed upon it.

My only concern was to gain better control over the cylinder that pulls the car. My desire was to implement some sort of PID control loop based on the velocity of the cylinder recorded by an angular encoder.  I also hoped to use a Windows base program called LabTech to control the cylinder.  This program works in conjunction with a Digital-to-Analog;Analog-to-Digital (D/A;A/D) computer board.  With the encoder wired to an A/D input and the valve controller wired to a D/A output, I can use the LabTech program to implement a control system utilizing a PID equation.

Current Speed Controls

The current system is awkward, at best.  It relies on function generator.  The function generator is part of a large system that controls a hydraulic servo-style valve that is able to pass small or large amounts of fluid to obtain very small or very large cylinder movements.  The signal sent from the function generator goes through what is called an AC-Controller.  It has a lot of control elements, but we were mainly concerned with a set point and a scale factor.  The scale factor was set, and held, such that 1 Volt produces 1 MPH on the vehicle.  And by turning the set point one could get the cylinder to manually extend or retract at different speeds.  It is my theory that the previous system had no control characteristics, it simply fed voltages based on signals from the function generator, through the AC-Controller, to the valve.  I don't think it read the velocity and reacted to it.  No extensive tests were done to validate this theory, but when we lifted the cylinder position encoder off the cylinder no changes in speed were observed. We never ran the system with the encoder removed for fear of uncontrolled cylinder movement.  But its action indicates no control based on current velocity.

Running the system and getting a favorable result was an intensive series of events, and I refer only to the part that includes setting cylinder speed.  Much more was necessary to record data such as impact load, bumper system deflections, and actual vehicle velocity.
 

1. First the hydraulic pump must be started to maximum pressure and held during the impact.
2. Next someone would have to turn the set point dial on the AC-Controller to a value that will produce a small extending movement in the cylinder.
3. Then someone would have to flip a switch that by-passes all limit switches and safety devices (except all stop), in order to extend the cylinder past its retract limit switch.
4. When the cylinder is free of the retract limit switch the by-pass switch is returned to its normal run position.  At this point, the only way to get the cylinder to move is by holding down a non-retentive push button.
5. Before the car can be connected to the trolley and cable, the set point has to be set at a spot where the encoder reads a certain velocity (digital display hooked directly to the encoder).  This set point velocity was used with the values programmed into the funciton generator to produce the desired velocity.  The value on the set point dial must be remembered or written down so it can be used when the real impact is to be run.
6. Next the set point must be set to a value that slowly extends the cylinder so someone can manually pull the trolley out to where the car is waiting in starting position.
7. Then the set point is again changed to a slow retract to take out slack in the cable.
8. Finally it is ready to run.  After the set point is again set to the value found early in the manual calibration the function generator is set and the operator holds the push button until the vehicle hits the barrier.
All this only takes a few minutes, but if any step is skipped you can end up with an incorrect speed and ruin an expensive prototype on a useless test.

Proposed Speed Controls

If my theory about the lack of control charactersitics in the current system is correct, implementing a control system based on the encoder output should dramatically improve speed control.  We needed something that would look at the encoder output and compare it to a desired value and adjust the cylinder velocity based on the current velocity.  A good control algorithm for this is called a PID control loop.  The PC data acquistion software, LabTech, already has a PID control block incorporated into it.  Figure 1 below shows the diagram of the control system I plan to implement.

Figure 1.  Diagram showing the basic flow of data through the PID Control system.
 

The set point block defines how the user wants to see the system act.  The controller compares the previous output value from the process, in this case the hydaulic cylinder process.  The value in the process is measured by an encoder to explain the state of the process.  The process is set by the physical make up of the system and the set point function is determined by desire or need.  The PID controller block is the part we can change to get the desired response. The user has the option of changing the coefficients in the PID equation to achieve the desired response.  The general PID equation is as follows:

,
Figure 2.  General PID equation.
 

where m represents the PID output it uses to control the system, e is the error in the system from the desired, T is the timestep, and the K values are the coefficients we can change to change the response characteristics.  K_p, K_i, K_d represent the Proportional, Integral, and Differential coefficients, respectively.   The proportional coefficient controls how severely the controller tries to compensate for errors.  If this is to high it will oscillate around the desired value possibly slamming or vibrating the system badly.  The integral coefficient controls makes certain that as long as there is an error there is a compensation.  The derivative coefficient helps compensate for sudden changes.

Any successful computer based control system takes over much of the manual steps and automates them.  The main manual step I was determined to employ was the zero velocity calibration.  I was hoping to get the cylinder to have zero velocity very quickly, and pass that voltage value on to the PID used to control the impact velocity.  This would eliminate the step that the operator must take to make sure the cylinder is moving in the right direction at the correct speed.  I wanted it done quickly so that the car could be hooked up to the trolley and cable during this calibration and not be moved at all.  I was unable to get this zero velocity calibration done as described in the Discussion of Final Implementation Results section below.
 

Implementation Procedures

 The basic steps for implementing the PID style control were rather simple.  First I needed to input the voltage value from the encoder into the A/D input channel in the computer board.  Then I needed to connect the D/A output channel on the board to the valve controller.  Once these were connected I had to make sure that the voltages I wanted were sent and received by these channels. After I was satisfied with the input and output analog values, I went on to my last step of designing a PID control program using LabTech to actually control the cylinder action.

My boss already had a board made up that receives wires from the load cells and other input devices, so adding the encoder input was as easy as replacing existing wires with the new input.  By the end he made up a seprate board with a separate parallel plug for the inputs and outputs.

The output from the D/A channel took a little more effort.  The parallel plug had no pins into the D/A channels up until now.  I got to do most of the soldering of wires onto these pins.  The board has two D/A channels so we wired both, even though I only needed one for this project.  After a little research we found where this connection went into the valve controller.  The system has a main console seperate from the function generator.  It controls all the expansion controllers.  For example we have two other sets of smaller hydaulic cylinders that are used for towing simulation on rear bumper systems.  In this main console there is an option to utilize an external program to run the cylinders.  This is what we needed.

After we had the inputs and outputs wired in we had to check for voltage values put to those channels by the LabTech program.  Using the old method of running the crash barrier system we obtained a trace from the encoder showing voltage values we expected.  This meant that we could read straight values and not have to scale or offset them.  This was not true, however, for the output.  When I tried to set a 0.5 voltage using LabTech it came out around 2.5 volts.  I modified the scale and offset values provided on the output block in LabTech until I received the same voltage at the output channel as I was expecting.  It turned out that I needed to scale by 2 and offset -10.  Using those settings I always received the voltages I wanted thereafter.

The inputs and outputs were attached and reading correctly.  The next biggest step was to connect it to the cylinder and see if the cylinder would respond correctly.  After a weeks worth of intermittent research, hardware study, wiring, and voltage calibration, I was getting excited about the prospect of seeing the PC control the movement of the cylinder.  It turned out to be fairly simple.  I made certain that I had an input that was small so if control was bad it would not jump wildly.  It didn't jump at all.  It worked exactly like I programmed it.  Gaining control of the cylinder was the most worrisome part of the project.  At the outset we were pretty sure it could be done but not completely sure.  Well the big hurddle was behind us now, or so I thought.  All I had to do now was to program in a PID loop and a calibration and I was set for early submission.

That weekend every idle thought had given way to ideas and plans to implement my PID control.  When we returned on Monday we found a crash barrier system that acted irradically.  It could not hold a zero point and speeds were not able to be held constant.  It took June and most of July to find the time to actually diagnose the problem.  Once it was found the the new part was ordered and the crash barrier system was rock steady once again.  Unfortuneately I only had 5 days to implement my control system.  On top of that an urgent test sequence was underway.  One in which they needed my help to get it done on time.  So little progress was made on my project the first three days of my home stretch.  But on Friday before the project was due I had a system that worked well without the car attached.  That day I started by applying a constant set point to the PID and setting a low Proportional and integral coefficients.  I tuned them until I got the response I wanted.  I hoped that those settings would transfer favorably to the velocity curve I had made up to ramp the vehicle's speed to the desired speed of 5.2 mph.  It worked well with the curve, just as it had with the set point.  I varied the coefficients a bit to see what the response would be.  Increasing the proportional coefficient increased overshoot and caused vibration in the system when running.  Lowering the proportional coefficient made a sluggish response.  It seemed that I already had a good PID control set up.  Monday when I returned to work all that was left was to hook up the car and do a real test.  The system responded well to the desired set point function.

Discussion of Final Implementation Results

The hardware we had available made my 'Crash Barrier Calibration and Control' project into just a 'Crash Barrier Control' project right from the start.  The encoder was only able to output positive voltages.  In other words, no matter which way it turns it will always appear positive.  I wanted to find zero.  A short scan of the control loop diagram in the Proposed Speed Control section above shows that if you have a system must have the ability to move positive and negative to settle to zero.  The system does have the ability to go in both directions, however the encoder was unable to indicate this.  Another factor affecting the zero velocity calibration was the fact that the output to the valve controller was sent out from 0-10V_DC .  This means that the only way to get it to go in the negative direction (extend) was to change the set point sufficiently to extend the cylinder, as was done manually.  There was a permanent zero point on the AC-Controller that could have been adjusted, but without the bi-directional encoder, it would have been pointless.

So I accepted the fact that it was only a Velocity Control project.  When it comes to comes to controlling the vehicle speed there are only a couple of concerns.  The most important is boxed off in red on the graphs below.  This is the speed of the cylinder just before it stops and allows the vehicle to coast the rest of the way to the wall.  We call this the exit speed.  As you can see the current system goes above the desired exit speed, because it appears to slow down slightly before the vehicle is released.  This is thought to be caused by pressure drop in the hydraulic tank by that time.  The proposed control system slopes up to the desired exit speed and holds it rather steady.  This indicates that even if there is a pressure drop off that the controller can compensate for it.  When I was playing around with PID coefficient values I mostly ran with no pump running.  Even with the pump running the cylinder still achieved the desired exit speed.  This appears to indicate far superior control than was previously employed.
 
 
Figure 3.  Comparison between outputs from old and new velocity control methods.  Blocked area is most important control area.

Another important aspect of the velocity control is not to overly accelerate the vehicle from rest.  If the vehicle is yanked there is a good chance it will outrun the trolley just long enough to drop the trolley attachment.  If this happens the there will obviously be no more speed control through the rest of the cylinder stroke.  The current system uses a small step in the function generator and holds if for a significant amount of time to get the vehicle going slowly before it gets it up to speed.  Due to the constraints of time I was unable to develop a good set point function to eliminate this problem.  When I made my final run the vehicle did out run the trolley enough to drop the attachment.  Some work on the set point function could easily alleviate this jerking.  The important thing to remember that I wanted to design a system that will do what I tell it to do.  I told it to jerk, and it jerked.  Take for example the chart in Figure 4.  It shows how well the output followed the input.
 

  Figure 4.  Comparison of Set point function and actual system Response

Conclusion

It is concluded that the implementation of the PID controller in the system will be a great benefit.  As of this writing a good set point function has not yet been developed, but when it is it should help to dramatically increase acurracy and consistency in vehicle velocity for Crash Barrier bumper testing.  It appearst that the control system compensates for pressure loss, dirty hydraulic fluid, or even slightly deteriorated hydraulic system components, which should help to eliminate wasted prototype parts on faulty impacts.  The PID is only one component in an overall test system, but an important one.  Having a computer control the setup, testing, and data collection/display helps to eliminate errors and injuries.  Other additional components to an overall test system are explained below.

Future Considerations

• The most important feature that should be added in the future is the ablility to read positive and negative from the encoder.  This can be obtained by purchasing new hardware or modifying old.  This is necessary in order to ever have a chance at finding zero velocity.  Once this zero velocity point is found, then other helpful things can be used.  Since the cable gets pulled out the same distance every time, a program could be run to extend the cylinder all the way out slowly and safely while someone pulls the trolley out to the car.  You could also, with confidence, extend the cylinder beyond the retract limit switch.
• Another feature, that is nearly an essential, is to have the entire program run on an edge trigger sent from the non-retentive push button.  This would run the program as soon as the button was pushed, but still allow the pulling of the vehicle to be terminated if the button is released.
• The A/D;D/A card has some spare inputs.  These could be used to read the load cells, deflection device, and the actual vehicle speed with the electronic eyes.  After collecting all this data the computer could then process the data in a predetermined format without anyone taking the time.
• If LabTech were replaced by LabView, the program could be made into a C++ program that could be compiled and run as a seperate program in Windows to make it easier for the user to run these impact tests.