Hydraulic Hybrid Vehicles: Reducing Heavy Diesel Vehicle Emissions at an Affordable Price

31  Download (0)

Full text


Hydraulic Hybrid Vehicles:

Reducing Heavy Diesel Vehicle Emissions at an Affordable


ECE402 Second Semester Report

Spring Semester 2009

Written by:

Kathleen Plymell

Indra Wicaksono

Ryan Paccini

Matthew Del Margo

Prepared to partially fulfill the requirements for ECE402

Department of Electrical and Computer Engineering

Colorado State University

Fort Collins, Colorado 80523

Sponsored by: Czero

Industrial Advisors: Dr. Guy Babbit and Chris Turner

Academic Advisor: Dr. Peter Young



As the population of the world grows, so do the number of vehicles on the road. In many highly populated areas of the world people use public transportation because the roads are too congested or they cannot afford a car. By using public transportation the amount of emissions produced decreases, but the vehicles that are used for public transportation are not as efficient as they could be. The vehicles used for public transportation, waste disposal, and delivery are heavy and run on diesel. One way to capture the wasted energy of the diesel vehicle is to integrate a hydraulic system that uses regenerative braking. This is the task of one Electrical and Computer Engineering senior design team. They have taken on the task of designing a control system for a hydraulic regenerative braking hybrid vehicle to help reduce the carbon emission in lesser developed and highly polluted areas of the world. The research and design that was done by Senior Design students has consisted of designing a

computerized control system that will effectively and efficiently control the vehicle’s engine and the hydraulic system that will aid a vehicle in acceleration. This system will monitor the hydraulic and mechanical system’s pressure and speed in order to keep all measurements within a safe range, and should the system reach critical levels; the automated control system will perform the necessary

shutdown tasks in order to maintain safety. The control system will control the amount of pressure that is generated by the deceleration process and is stored in the accumulator, and will likewise control the pressure released from the accumulator when the vehicle accelerates.

The previous team implemented a working prototype of the control system. The current team of students will develop an automated control system that transitions smoothly from discharging the accumulator to charging the accumulator.


Table of Contents

Title Page………..… 1

Abstract………..….. 2

Table of Contents………..………. 3

List of Figures, Pictures, and Tables………..………..………. 4

Section 1: Introduction………..……… 5

Part A: Why Hydraulic Hybrids Instead of Electric Hybrids?...5

Part B: Hydraulic Hybrid System………...5

How the Hydraulic System Actually Works………..…6

Part C: Marketability………..………..6

Part D: How is Electrical Engineering Applied to this Project?... 7

Part E: Budget……….. 7

Section 2: Spring 2008 Team’s Work and Details of the Hydraulic System……….……..…………..……. 7

Part A: Getting Started………...7

Part B: Spring 2008 Team’s Accomplishments.………..………..8

Test Skid………..………. 9 The Truck………..……….. 9 Safety Controller……….………….10 Safety System……….………11 Solenoid Valves……….……11 Motor Controller………....11 Transfer Case……….11

Displacement Pump Controller………...12

Implementation of Control Algorithm on Test Skid………12

Implementation of Control Algorithm on the Truck………..13

Section 3: Current Teams Work First Semester…….………..……….…. 13

Part A: Milestones……….. 13

Part B: Improvements to Previous Team’s Work………..… 14

Electrical Connections………... 14

Part C: Fall 2008 Accomplishments………..14

Manual Switches……….14

Displacement Pump Controller………....15

Serial Communication……….17

Transfer Case……….18

Illuminated Switch……….19

Section 4: Current Teams Work Second Semester……….19

Part A: Milestones………...19

Part B: Spring 2009 Accomplishments………19

Drive by Wire……….…19

Serial Communication………..…20

Modes of Operation……….….…23



Section 5: Current and Future Automation Process………. 27

Part A: Current Status and Future Plans………27

References……….……… 29

Appendix A: Abbreviations….………..………..… 30


List of Figures, Pictures, and Tables











FIGURE 11: Frequency to Voltage Converter……… 20

FIGURE 12: SERIAL DATA………..……….… 22













Section 1: Introduction

With unpredictable gas prices and the concerns for the environment many vehicle corporations have developed new hybrid vehicles. While car corporations like Toyota, Ford, and Honda are focusing on electric hybrid vehicles some are focusing on hydraulic hybrid vehicles like Eaton. Eaton has developed a parallel hydraulic hybrid system for large scale diesel vehicles that mostly operates in stop and go mode. Their parallel hydraulic hybrid system captures up to 70% of the truck’s kinetic energy. The driveline torque increases the diesel vehicle’s acceleration by 20%. Fuel economy will increase by 20 to 30%. There is a 20% emission reduction of CO2 and a 17% emission reduction in NOx. The system doubles the lifetime of the brakes by using regenerative braking. [1]

Part A: Why Hydraulic Hybrids Instead of Electric Hybrids?

For a large vehicle like a delivery truck or a bus an electric hybrid system cannot be used, because there is no practical way to store the amount of energy required for a large vehicle to accelerate in an

electrical storage system. A hydraulic system is much larger than an electric system and can store more energy at a faster rate. Since buses, delivery trucks, and waste management vehicles mostly operate in stop and go mode they require a lot of initial torque to get going. The hydraulic system can provide this initial torque to the system because of its capability to store and release energy rapidly.

Hydraulic motors can produce 6,400 more Watts per kilogram than an electric motor. The hydraulic hybrid can store 2,350 more Watts per kilogram than a battery electric hybrid and 500 more Watts per kilogram than an ultra-capacitor electric hybrid. The cost of the hydraulic system is low to medium and an electric hybrid system is medium to high. A hydraulic hybrid system will have a lifetime of 10 or more years and extend the lifetime of other parts on the vehicle, where a battery electric hybrid will only have a lifetime of 5 years and the lifetime of an ultra-capacitor electric hybrid is unknown. [2]

Part B: Hydraulic Hybrid System

In Figure 1, you can see when large diesel vehicles brake, the majority of energy is lost through the deceleration process. If the vehicle design can harness the lost energy and store the energy it can then be used to assist in the accelerating mode of the vehicle. The hydraulic hybrid system harnesses the lost energy by converting the momentum from the deceleration process into kinetic energy, which is then converted into pressure and stored in an accumulator. When the vehicle accelerates, the energy stored in the accumulator is released.


How the Hydraulic System Actually Works

Say a hydraulic regenerative braking system has been installed onto an existing city bus. The hydraulic regenerative braking system consists of a displacement pump that converts mechanical energy into pressure and vice versa, an accumulator that holds the pressurized oil in a bladder that is compressed by gas, and a low pressure tank. When the city bus accelerates the position of the displacement pump changes so the pressurized oil is allowed to leave the accumulator and power the drive train. When the pressure begins to run out the displacement pump will slowly change positions. This will allow the internal combustion engine torque to be added to the torque produced by the remaining pressure. The displacement pump head will continue moving until the internal combustion engine is fully powering the drive train. When the city bus starts to break the displacement pump will change again and the oil from the low pressure tank will be pumped into the accumulator. This will continue until the city bus starts to accelerate, then the pressure will be released again.


Part C: Marketability

In America, the trend is to own your own car, so most Americans are concerned with the fuel economy and emissions of their own personal vehicle and not of a city bus or a waste management truck. In highly populated countries like India, China, and Singapore, the trend is to take a bus or train because people cannot afford to own their own vehicle or the roads are too crowded because of highly

populated areas. When people of these countries take the bus or train they are reducing the amount of emissions produced, but the busses used still produce a lot of emissions and do not work efficiently. In Table 1, you can see that the number of large diesel vehicles in India is increasing each year. As the number of vehicles on the road increase so does the pollution which increases the need for fuel efficient vehicles. So to decrease the pollution why don’t more people from India, China, and Singapore just go out and buy new fuel efficient diesel vehicles? The answer is they can’t afford to buy a brand new vehicle or even a used vehicle. This is why a group of senior design students are designing a hydraulic system. The difference between the team’s system and the system used on the America UPS trucks is that our system can be placed on an existing diesel vehicle. Our hydraulic hybrid system is a retrofit kit that can be purchased by itself and installed on any existing diesel vehicle that is in service. The goal of Czero, the founding company, is to be able to manufacture these retrofit hydraulic systems so less developed countries with a high population density can afford to buy the product.



Part D: How is Electrical Engineering Applied to this Project?

A majority of hydraulic system is related to mechanical engineering; however, a control system is what ties all the different parts of the system together. The control system allows all the parts of the diesel vehicle to work with the hydraulic system in an efficient manner. Some control systems can be

implemented using mechanical devices and methods, but since our hydraulic system is a retrofit kit we have to be able to fine tune each kit to the existing vehicle it will be attached to so the system will be operating at its highest efficiency.

The team controls the displacement pump and safety controllers with a MotoTron 128 ECU. The

controllers are very self explanatory. One controls the displacement of the pump position and the other controls the safety backup in case of a system malfunctions. In order to design the controllers, an advanced knowledge of MATLAB, circuit design, and electrical control systems is required.

Part E: Budget

As you can tell our project can help the aide the current economic and environment issues. Due to the benefits of our project we are qualified for many grants. The senior design team was initially budgeted $50k from Czero to get the project moving. Czero then received a $25k grant from the Colorado Governor’s Office. A local company, MotoTron, donated several ECU controller modules for the test skid and the test truck. The multitude of funding has made this project possible. (See Appendix B)

Section 2: Spring 2008 Team’s Work and Details of the Hydraulic System

Part A: Getting Started

For the electrical engineering team, this project began in the spring semester of 2008. The project was originally a Mechanical Engineering senior design project that began in the fall semester of 2007. The first semester of this project, a large group of mechanical engineers began to think through the design of the hydraulic system. Most of the semester was spent researching previous experiments and possible designs that could be applied to this project. Many Simulink models were created in MATLAB to predict the efficiency of the vehicle, what size of vehicle was needed, and how much pressure needed to be stored in order to supply sufficient power to the vehicle. Also in the fall semester of 2007, the group


also purchased a “test skid” from the University of Michigan. The details of the test skid will be explained in detail in the following section.

There was relatively no electrical engineering work that was done on this project prior to the spring 2008, because this was too big of a project for just the mechanical engineers to work on. A senior design team of electrical engineers was formed. They spent the semester researching the best methods of controlling this system and came upon a local company in Ft. Collins called MotoTron. MotoTron designs electric controller units (ECUs) for high performance vehicles. What made MotoTron the controller of choice was its seamless interface between the hardware and a MATLAB toolbox called Simulink.

Part B: Spring 2008 Team’s Accomplishments

The majority of the time and effort was spent understanding what was being controlled and why it needed to be controlled. In the Figure 3, there is a schematic of the hydraulic system which illustrates where all the items that need to be controlled are.


The hydraulic system is broken down into two main controllers: the safety controller and the

displacement controller. The safety controller and the displacement controller both monitor the system for dangerously high engine rpms (rotations per minute) and pressures. If sensor reading exceeds the maximum threshold levels within the controller, the displacement controller is activated and attempts to adjust the displacement pump until the system reaches stability. Similarly, if the pressure in the accumulator increases too rapidly or reaches critical levels, the displacement controller will set the displacement pump so there is no pumping to the accumulator. Should the displacement pump not gain control of the system, or fail completely, the safety controller, which is a completely separate unit, will assume control of the system and turn off the hydraulic system. The safety controller will also release any pressure from the accumulator, and in our test case, and applies the brakes to reduce any


Test Skid

The test skid is a displacement pump that is connected to a large flywheel (in order to simulate the load of the vehicle) and an accumulator. The mechanical engineers and electrical engineers used the test skid to perform all their initial tests on.


The Truck

The test truck used for the project was purchased by Czero and donated to the team in order to have an accurate model for the hydraulic system. The cargo box was removed from the truck in order to allow easy access to the drive shaft and undercarriage. This is necessary to attach all of the different

components and allow the senior design students to see how the system is operating and if there are any visible or obvious safety hazards. The MotoTron controller is placed in the cab under the passenger seat. All the outputs and inputs of the truck feed in or out of the MotoTron controller.


The truck has extensive wiring because the internal combustion engine, the displacement pump, the pressure transducers, and many other items need to be connected to the MotoTron controller. The MotoTron controller is powered by the truck battery. Figure 4 was designed so the senior design students could visualize how the truck should be wired. The wiring was a large task because both the test skid and the truck needed to be wired. The two wiring setups were very different. The test skid had many different pressure monitors and speed sensors that were used to

collect initial data, but the truck does not have these



sensors. This means the wiring is somewhat simpler on the truck. There were still difficulties with the truck wiring. Two wiring challenges that arose were the controller needed to be powered reliably off of the truck battery and the wire had to routed through the truck so they do not interfere with the normal operation of the truck.

Safety Controller

The test skid has a safety controller integrated into it that limits the fly-wheel from going over 2000 RPMS. This is primarily to protect people standing around and to also prevent the test skid from getting damaged incase a malfunction does occur. When the skid spins above 2000 RPMs the solenoids will release and the hydraulic fluid will push on the emergency brake pads to slow the fly-wheel.

The gas pedal input is the result of a magnetic pickup going into the crank signal input of the controller. This is done using a MotoTron 48 pin controller which isolates it from the other controller and will always be operational. If over 90% of the values entred were over 2000 RPMS then the emergency brake system would activate. The time it took to sample this array took two seconds. So many samples were taken in case there were small spikes of noise which result in inaccurate readings. With this size of array and sample time the skid would have to have 180 out of 200 samples to be over 2000 RPMS. The system worked great in this simulation; however there were problems compiling the Simulink model in MotoTron. First, the S-function needed to be a discrete S-function and not in continuous time. Even after this was changed the Simulink model did not compile. The senior design team had to contract MotoTron to resolve the problem. The solution was to include files that were mission. Even after the files were included, Simulink would not compile. A solution was needed quickly due to the time crunch of getting the test skid up and running.

The team’s next idea was to try and implement the safety controller with standard Simulink blocks with no S-functions. This idea was implemented using many switch blocks and discrete delays. The new system, Figure 5, would read in the speed and if it was over 2000RPMS would output one value or if not the system would output different value. The same speed input was then delayed in increments of 250 ms three times and the same logic was applied. With this system only four speed samples were taken over the course of 750 ms. When all four samples were over 2000 RPMs then the emergency brake system would be applied. This method worked successfully, but was not as accurate because fewer samples were taken.


Safety System

Another problem that was encountered with the displacement controller was when an over speed was detected then the brakes would be applied, but then when the RPMs went below 2000 then the brakes would release. In order to keep the brakes applied more logic needed to be implemented. The solution can be implemented by ‘tricking’ the speed input. When the brakes are applied then the speed sensor input is taken away and a constant input of 2100 RPMs is applied even though the system is actually slowing down. This way the system thinks that the RPMs are still above 2000 RPMs and the brakes will be kept on. The only way to over ride this is to reset the system by turning it off. Overall, the newly implemented system proved to be very reliable and has been in operation since it was implemented.

Solenoid Valves

Three solenoid valves are being used in the hydraulic system. On the test skid the solenoids are rated at for 12 V at 6.4 Ω. From this it is determined that 1.8 Amps or approximately 2 Amps are needed to flip the solenoids on or off. The solenoids are switched by using the injector driver outputs from MotoTron Simulink. On terminal of the solenoids are attached to the truck battery that supplies 12 V. The other terminal is connected to the injector drivers on the MotoTron controllers. The injector driver acts like a BJT switch. The solenoid is triggered off by applying a digital zero value. When the solenoid is triggered off it behaves as a floating circuit with no voltage across it. When the solenoid is triggered on a digital one value is applied. The injector driver connects the circuit, grounding it, which completes the circuit. The solenoid then turns on with a voltage of 12 V applied across it.

Motor Controller

When the team was conducting their initial tests, the HB-25 controller was used to control the DC motor. One purpose of the displacement pump is to control the DC motor that changes the

displacement. The DC motor has reverse polarity inputs to change directions. The decision to use a motor controller was made for many reasons. First, the speed that the DC motor would rotate at could be varied. Second, it is able to reverse the polarity of the motor without physically changing the system. Last, it allowed a way to interface the DC motor to the 128 pin controller and actually have control over it rather than just being on or off. The DC motor controller brand is Parallax model number HB-25.


Transfer Case

The transfer case is what changes the truck between 2WD, 4HI, 4LO, and Neutral. It is desired to be able to control the transfer case through MotoTron. The transfer case has four inputs from an encoder that


reads in a high or low value. Inside the transfer case there is a DC motor that can be turned to a desired position. The team was never successfully able to gain control of the transfer case.

Displacement Pump Controller

Controlling the displacement of the hydraulic pump is critical to the operation of a hydraulic-hybrid vehicle. Its importance lies in the fact that the displacement of the hydraulic pump governs how the vehicle behaves like a hybrid. The torque on the axel of the vehicle due to the hydraulic system is proportional to the pressure difference between the high-pressure and low-pressure accumulator times the displacement of the hydraulic pump. A torque on the axel accelerates or decelerates the vehicle making control over the displacement very important. For the hybrid, the accumulator pressure is not regulated; therefore the torque applied to the axel via hydraulics is controlled solely by adjusting the displacement. The displacement of the hydraulic pump is dictated by the position within the pump and is variable.

A higher level system controller will determine the appropriate displacement based on the pressure in the accumulators, the speed of the vehicle, the driver’s position on the gas pedal, and perhaps other factors. By evaluating these conditions, the higher level controller will command the displacement controller to a given displacement. The displacement can be positive, negative, or zero allowing for torque to accelerate, decelerate, or add no torque from the hydraulic system. With positive displacement, the pump acts like a motor, allowing hydraulic fluid to flow from the high pressure accumulator to low pressure, accelerating the vehicle. With negative displacement, the pump acts like a generator, pushing fluid back into the high pressure accumulator and decelerating the vehicle in the process.


Implementation of Control Algorithm on Test Skid

The control algorithm is implemented on the 128-pin MotoTron controller using the MotoHawk

software, which runs in MATLAB. Simulink, is used to design the control algorithm with some additional MotoHawk tools. The model is then built and downloaded into the MotoTron board.

The displacement pump on the test skid was adjusted by moving the internal head from side to side. The middle was zero displacement, to the right was positive displacement, and to the left was negative


displacement. This head was moved by cranking a shaft in the proper direction. To move the shaft, a high-torque geared DC servomotor was purchased and coupled to the crank shaft.

The first step to controlling the displacement pump head was to measure the actual position so the feedback can compensate for any distortion. After exploring several options, it was decided to use a 20-turn, 10 kΩ potentiometer for feedback. The potentiometer was mounted on the same shaft with the DC motor and crank. This way the resistance varies linearly as the displacement pump head is changed as the shaft is cranked. To measure the potentiometer, a 5 V pin from the MotoTron controller was connected to the potentiometer and the voltage output from the potentiometer was wired to an analog input on the MotoTron controller. A high impedance pull down input pin was used after it was

discovered that a low impedance pull up input pin made the voltage non-linear due to loading. In MotoHawk, an analog input block with the correct pin selected and the output in counts 0 to 1023 (1023 = 5 V) is normalized such that full positive displacement is 1, full negative displacement is -1, and no displacement is 0. For accurate feedback, calibration is necessary.

For calibration and data logging, MotoTron has a software tool called MotoTune.

MotoTune is a software program that runs while the actual controller is active and can actively monitor any probe setup in MotoHawk, log the incoming data in real-time, and change the value of the output of any calibration block setup in MotoHawk to a user-designated value. To calibrate the feedback and ensure proper normalization, the shaft was hand-cranked to the left and right limits and the analog input count values were saved as constants called Left_Lim and Right_Lim in an m-file. These endpoints are set to -1 and 1 displacement and any value that lands between is linearly extrapolated.

Implementation of Control Algorithm on the Truck

The truck is a nearly identical setup to the test skid with a few differences. The displacement pump is adjusted using hydraulic pressure rather than a DC motor attached to a crank shaft. With no DC motor, there is no PWM chip necessary. There are two solenoid valves on either end of the rod-like

displacement pump and one is opened while the other is closed to move the displacement a particular direction. To open and close these valves, injector driver output pins are used on the MotoTron controller. This concept is fundamentally the same as the control algorithm used in the test skid controller. Another difference is the truck’s displacement pump has 3 digital outputs that are active when the displacement pump is full positive, full negative, and zero. This should allow for real-time calibration with 3 data points rather than the 2 used on the test skid. A potentiometer is also used for feedback on the truck’s displacement controller; however, it is only a half-turn potentiometer.

Section 3: Current Teams Work First Semester

Part A: Milestones

All electrical connections were tested, verified, and replaced if needed. Currently only one operator is required to drive the truck. The Simulink code for the displacement pump from the previous team was rewritten to be optimized. The team is able to track the position of the displacement pump head. Series serial data communication was established between the truck’s engine control module (ECM) and the MotoTron engine control unit (ECU). Improvements were made to the transfer case Simulink model. The MotoTron controller and the hydraulic pump can be activated without powering the truck. A


Part B: Improvements to Spring 2008 Team’s Work

Electrical Connections

Last semester’s team was rushed for time so they did not have a chance to wire the MotoTron ECU effectively. When the current team started the display of organized wires was very discouraging. The first goal for the semester was to rewire the truck in an organized manner. This included one

continuous piece of wire going from the output of the truck to the input of the MotoTron ECU with functional crimps, color coding the wires for their specific purpose, and having the correct length and gauge of wire. After this was accomplished the team could work on the ECU more efficiently.


Part C: Fall 2008 Accomplishments

Manual Switches

At the beginning of the semester the hydraulic system on the truck needed two operators. One would drive the truck and the other would perform the switching operations. The driver initially needed to build up pressure. The driver would do this by driving around the EECL parking lot while the second person looked out the back window at the small pressure gauge. The pressure gauge usually displayed the correct amount of pressure that was in the accumulator. Once there was enough pressure build-up the driver would take their foot off the gas pedal. The second operator pushed a hot key of the

computer to activate the hydraulics. While the internal combustion engine was idling the truck would accelerate with hydraulic power. The second operator had to continuously watch the amount of pressure in the accumulator because the hydraulic system does not run smoothly on low amounts of pressure. When the pressure was approaching a dangerously low level the driver would reengage the engine. The second operator would push another hot key on the computer to turn the hydraulic system off. The driver then has to put the truck in drive to rebuild up pressure. The two operators were needed because the hot keys on the computer were too small and hard to hit while the truck was jerking around.

Our goal at the beginning of the semester was to have one operator drive the truck and be able to switch between the modes. The physical design included two mechanical switches. The first switch was to activate the hydraulic system or to deactivate the hydraulic system. When the hydraulic system is activated the truck operates as a hybrid. When the hydraulic system is deactivated the truck operates normally. The second switch allowed the operator to tell the system to charge or discharge the accumulator. In order for both switches to control the system Simulink code needed to be implemented. The code reads in the inputs from the switches and then either turns on or off the hydraulic system. If the hydraulic system switch is on the on position the code then controls the


discharging and charging of the accumulator depending on the second switch position. The switches and code were implemented in the truck and work successfully. Now one person can drive the truck and the other is free to enjoy the ride or run tests without having to worry about the switching procedure.

Displacement Pump Controller

After the implementation of the two mechanical switches the truck operated as a “bang-bang” system. The “bang-bang” controller allows the driver to provide 100% charge resulting in deceleration or 100% discharge resulting in acceleration based on the position of the displacement pump head. The

“bang-bang” system obviously got its name because the switching process jerks the truck. We needed a system that could control the amount of hybrid acceleration and deceleration by limiting the amount of torque supplied by the internal combustion engine and the hydraulic pump. The displacement pump head tracking controller allows the driver to request the desired amount of charge or discharge displacement allowing a smoother transition.

We found out a couple key issues with the current configuration of the displacement of the pump and the problems associated with not enough pressure in the lines. For instance, when the pressure in the accumulator becomes depleted the pumps displacement head is unable to move due to the lack of pressure pushing against the head. This causes an error in the controller that can ramp up the error correction term to a point that can damage the displacement head. Once the pressure is regained the controller will try to compensate for the large accumulated error and slam the head to the other side which is unsafe for fast driving conditions and can severely injure the driver. In order to fix this problem we implemented a safety controller to check the pressure remaining in the accumulator and

compensate for the amount of control allowed. Once we started to get a feel for how the system operated we were able to start designing the controller that would directly correlate the throttle control with the displacement of the pump head.

The controller has two inputs and two outputs. The two inputs are the current position of the

displacement pump head and the desired position of the displacement pump head. The two outputs are two digital signals that send information to the top and bottom displacement solenoid valves which adjust the displacement pump head to arrive at the desired position.

The algorithm for the displacement pump controller starts by reading in the potentiometer feedback which determines the current position of the displacement pump head. It then reads in a user input for the desired displacement pump head position. A difference of value is then derived from the two inputs. If a positive difference occurs the bottom solenoid is turned on until the desired position of the displacement pump head is reached. If a negative difference occurs the top solenoid is turned on until the desired position of the displacement pump head is reached. In the algorithm, there are error bands placed around the desired position to take into account slight changing of the feedback values at steady state.

Using a two mode throttle pedal, we split the percentage of desired torque to -100% to 0% to 100% with 0% at an initial offset in degrees from the neutral position. This enabled us to accurately predict what the driver desired, eliminating a lot of the guess work and use of the brake pedal. From this type of controller we were able to create a controller that would relate the desired percent of torque to the available torque in the hydraulic fluid and compensated the rest with the trucks engine. A large portion of time will be to accurately depict what the driver want verses how fast we get to his desired torque. Moving the displacement head too quickly will feel like the breaks were slammed on for charging mode


or flooring it when in discharge. This is where a look up table will come in handy after we obtain data from our initial voyages. From this data we can create code that will use a hierarchy design for controlling what mode to run producing the best results. The shell for the code is in place with more information to accurately control the truck for next semester.

The controller works as desired when the vehicle is moving in a smooth and steady motion. However when conditions force the vehicle to shake violently, such as on driving on a rough surface, undesired overshoot is created in response.



The team is evaluated the issue that would cause the undesired overshoot in rough driving conditions. A possible idea for the cause of the issue is that the displacement pump head shakes violently which results in inconsistent feedback readings. It could also just be a normal behavior for the displacement pump head during rough conditions. In either case the tracking controller needs to be optimized to take these effects into consideration.


Serial Communication

In order to obtain information vital to the functioning and safety of a control system for the integrated hydraulic system in the International truck, deciphering and extraction of data from the serial data link was required module in this project. Automotive mechanics often use a diagnostic port to determine past and current parameters of the vehicle when investigating malfunctions in the operation. A wide variety of system parameters such as engine speed, oil pressure, fuel economy, battery potential, engine temperature, output torque, road speed, and total vehicle distance are transmitted over the serial data link. The number of times per second data regarding a specific parameter is transmitted, depends directly on the priority of that parameter. For example, oil temperature may be transmitted once in a given second while engine speed maybe transmitted ten times in a second. Two reasons for this prioritization are: engine speed is of greater importance to the system functionality than the oil temperature and due to the physical properties of oil or the temperature of the substance will not change quickly.

Depending on the manufacturing company, and even the model of the vehicle, different protocols are used when transmitting the serial data. Our International truck transmits data over a RS-485 cable using a J-1708 protocol. Along with the traditional structures of serial data such as start, stop and parity bit, the J-1708 protocol has a data structure specific to itself. Data pertaining to a specific parameter is preceded with a PID code. This PID is an identifier that indicates what property the data pertains to. Following the PID, data of varying lengths regarding the parameter is transmitted until a stop bit is received and data regarding a new parameter begins transmitted. It is important to take into account the bit resolution and initialization point when analyzing data. Bit resolution refers to the incremental amount in units of the parameters represented by an increase of one in the binary data. The

initialization point is an arbitrary starting value for when the binary representation is zero. Depending on the parameters, the initialization points maybe a non-zero number.


After identifying the PID that represents road speed in the data, we extracted the two bytes of serial data following each PID identifier. After extracting all data relevant to the road speed for the duration of the driving test, we converted the binary data into the standard decimal values. The final step was to multiply the collected data by the bit resolution and adding the result to the initialization point for that specific parameter. The results in the plot above agreed closely with data collected from the

speedometer for the duration of the test.

0 5 10 15 20 0 200 400

Road Speed vs

Sample Time

Road Speed


After conducting the driving tests, our team was able to verify the accuracy of the data supplied by the serial data port. Future plans involving serial data communications include first, creating code programs to efficiently extract and convert data from a wide variety of system parameters into a readable and easily verifiable text file. Secondly, developing a code of Mototron blocks that would read a variety of data into the Mototron ECU in real-time and convert this data in order that it can be used in the control algorithm for the motor and hydraulic system of the International truck.

Transfer Case

It is desired to be able to control the transfer case through MotoTron. With the current system, the position of the transfer case determines whether the truck is in hybrid mode or purely using the truck’s engine. The transfer case controller controls the transfer case motor which interfaces between the transfer case gears and the MotoTron controller. The transfer case motor has two inputs and four outputs. The two inputs can be supplied forward or reverse polarity of 12 V in order to turn the motor clockwise or counter clockwise. The four different gears/position of the transfer case are positioned approximately 20⁰ from each other. The four outputs provide a feedback that shows the angle at which the transfer case motor is currently positioned at.


The initial road block the team encountered regarding the transfer case was getting the motor to move clockwise or counter clockwise. The motor wouldn’t respond to 12V as expected. Many tests were done to determine the issue. It wasn’t clear what exactly the motor required in order to get a response. Several types of inputs were tried; constant voltage signals, pulse signals, and PWM signals. All of these test signals failed to induce a response. Then the team inquired about getting another transfer case motor from the mechanical engineering team. This solved the first problem. The motor the team was initially provided with was broken. The second roadblock is still ongoing. There are problems getting proper feedback from the four output ports of the transfer case motor. At first there was confusion between the use of pull down resistors and pull up resistors and which one the motor requires. After the team deduced from several different sources that the motor requires a pull down resistor, there was still no response from the feedback. The team is currently looking into going to a Dodge dealership to see if they can provide more information regarding the feedback system, and possibly test whether the transfer case motor is in proper working condition.


Illuminated Switch

There was a desire to operate the hydraulic system without turning on the internal combustion engine. The problem with this was the MotoTron ECU is powered by the battery of the truck. We wanted an easy transition to turn the hydraulic system on and off without turning the key on and off. An

illuminated switch was installed do the driver can easily see if the MotoTron ECU can be controlled. If the switch is illuminated, the hydraulic system will function independent of the internal combustion engine whether the ignition key is turned. This also means if the internal combustion engine is not on the power steering and other engine powered functions will not work.

Section 4: Current Teams Work Second Semester

Part A: Milestones

The second semester was spent on making improvements from last semesters work and writing the code to fully automate the system. We are now able to reliably read in the serial data that is outputted from the truck. The team also intercepted the throttle pedal signal, which is a key component of controlling the truck. The code for all the different modes of operation was completed.

Part B: Spring 2009 Accomplishments


Serial Communication

In order to assure the proper function and safety of the Mototron control system, obtaining,

understanding and decipher the data provided by the engine control unit (ECU) was a vital portion of this project.

Automotive mechanics often use a diagnostic port in vehicles to determine past and current parameters of the vehicle when investigating malfunctions in the operation. A wide variety of system parameters


such as engine speed, oil pressure, fuel economy, battery potential, engine temperature, output torque, road speed, and total vehicle distance are transmitted over the serial data link. The number of times per second data regarding a specific parameter is transmitted, depends directly on the priority of that parameter. For example, oil temperature may be transmitted once in a given second while engine speed is transmitted ten times in a second due to the parameter being of higher priority. Two reasons for this prioritization are that engine speed is of greater importance to the system functionality than the oil temperature, and due to the physical properties of oil, the temperature of the substance will not change fast enough to require such an update rate.

Depending on the manufacturing company, and even the model of the vehicle, different protocols are used when transmitting the serial data. Our International truck transmits data at a Baud rate of 9600 over a RS-485 cable using a J-1708 protocol. Along with the traditional structures of serial data such as start, stop and parity bit, the J-1708 protocol has a data structure unique to itself. Data pertaining to a specific parameter is preceded with a PID code. This PID is an identifier that indicates what property the subsequent data pertains to. Following the PID, data of varying lengths regarding the parameter is transmitted until a stop bit is received and data regarding a new parameter begins transmitted. It is important to take into account the bit resolution and initialization point when analyzing data. Bit resolution refers to the incremental amount in units of the parameters represented by an increase of one in the binary count. The initialization point is an arbitrary start value for when the binary

representation is zero. Depending on the parameters, the initialization points maybe a non-zero number.

The development of the Motohawk software that would extract the data was portioned into four modules, separating each transmitted message, verifying the accuracy, extraction of desired data, and filtering to produce reliable data.

To our advantage, there was only one ECU operating on the RS-485 communications system. Each transmission pertaining to the vehicle ECU is preceded by an indentifying MID. The software compared each character to the MID of the identifier for the International ECU. When a positive match was made, the software would save all past data received to an array and pass the data to the following module. In order to verify that the data being transmitted and received was accurate and reliable, a checksum is always the final character transmitted in a message. The next module of the program, verifies that the transmitted checksum is correct and the data contained in the message is reliable. The standard published J-1708 protocol states that the checksum consists of the 8-bit two's complement of the sum of the MID, PIDs and all data bytes in the message. When the checksum was properly validated, the trusted data was then passed to the following module of the program.

A parsing module was created that would examine each PID being transmitted in the string and extract the data regarding this parameter if the PID was of interest to the user. This task was completed by comparing each PID in the message to a list of desired PID. If the PID matches any, the index number pertaining to the location of the data in the array is saved. If the data is determined to be unwanted the


program will skip by four or six bytes, according to the specified data type published by SAE International.

In order to further minimize any possible errors in the deciphering the data, a fourth filter stage was added. This filter allowed all previously received values to be weighted greater than current value while still incorporating the new values. Ninety percent of the previous value was added with ten percent of the current value. Due to the update rate of the road speed data, the fractional delay associated with a change in the value has little effect on the real-time value provided to the Mototron controller.

Following the completion of the software, several tests were performed to verify accuracy and proper function. A plot of pedal position and serial data obtained in one test is shown in Figure 12. One can see at approximately 600 milliseconds, the engine load drops abruptly and hence the road speed decreases at a slower rate due to the inertia of the truck. The changes in the pedal positions are reflected in the percent of the engine load compared to maximum.

Figure 11: Serial Data

The J-1708 protocol published by SAE International indicates that each PID will be transmitted across the RS-485 serial interface. After success generation and testing of the software, it is interesting to note that the several PIDs such as output torque, transmission range position, etc, do not appear to be being transmitted across the serial line. Unlike stated in the SAE protocol, this may indicate that certain PIDs may need to be requested before they are transmitted over the serial link. [5]

0 10 20 30 40 50 60 70 80 90 100 1 55 109 163 217 271 325 379 433 487 541 595 649 703 757 811 865 919 973 1027 1081 1135 1189 1243 Time (mS)

RS -485 Serial Data

Road Speed (mph) Engine Load (%) Throttle Position (%)


Modes of Operation

The automation software has four modes of operation. They are: active mode, manual switch mode, limp home mode, and require restart mode.

Active Mode:

The active mode contains the control algorithm. The control algorithm controls when the hydraulic system will be activated and deactivated. There are many key components needed to accomplish this task. The components are: throttle position, the current rotations per minute (rpm) of the internal combustion engine, the current amount of torque outputted by the engine, and the amount of pressure build-up in the accumulator. The team had a hard time getting all this information which is discussed in the troubleshooting section. The throttle position, current rpm of the engine, and the current amount of torque outputted by the engine all come from the serial data, which until recently was not working correctly. There were also initial problems with being able to read in the amount of pressure in the accumulator, which is also discussed in the troubleshooting section.

All of these readings were needed to model and control the system accurately to create a smooth transition between discharging and charging. The throttle position is used to determine if the vehicle needs to accelerate or decelerate or remain at a constant speed. If the vehicle needs to accelerate the control algorithm reads in the amount of pressure in the accumulator. If there is enough pressure in the accumulator then the position of the displacement pump will be told to pivot so the compressed oil can power the drive train. If this amount of torque produced by the release of pressure is not enough to accelerate the vehicle to the desired speed then the torque of the engine needs to be added to the torque from the pressure. This is done by subtracting the torque provided by the pressure release from the desired torque, which is determined from the throttle position. The control algorithm will output a voltage signal that will tell the internal combustion engine how many rpms are required from it.

If the vehicle needs to decelerate the control algorithm will tell the displacement pump to move into the charging position. This is when the energy given off from the braking is collected into the accumulator. Pressure will continue to build-up until the vehicle comes to a complete stop or the amount of pressure reaches its maximum value. In the first case, the displacement pump head will then return to a neutral position. In the second case, a release valve will be triggered to allow the excess pressure to be



Manual Switch Mode:

Last semester the team implemented a manual switch mode of operation for the hydraulics. Manual switch mode operation has two switches; one switch controls the activation of the mode and the other switch controls the charging or discharging function of the hydraulic system. This mode was

incorporated in the complete control algorithm scheme in order to have a system that we can manually control specific conditions during the initial testing phase. Ultimately this mode will be removed once active mode is completely tested and fully operational. The following figure is the flowchart for the operation of Manual Switch Mode.


Limp Home Mode:

We have two modes to handle faults that occur within the system. The first of these modes was labeled Limp Home Mode. This mode was implemented in order to handle non-severe faults. Faults that this mode could handle include; out of range pressure, displacement sensor errors, and a stuck displacement head. There is no exact correction of any of the faults, however this mode allows the team to safely bring the vehicle to a stop or return back to the lab.

The first step the mode takes is it forces the displacement head back to neutral. Any control over the user initially had over displacement head is now ignored. This safely protects any components by preventing stored pressure from trying to move the drive shaft in a discharging or charging direction. Thus the vehicle will not drift forwards or backwards. Then a similar algorithm to the Drive-By-Wire is implemented to allow the user to have normal control of the throttle.


Require Restart Mode:

This is the second mode implemented to handle faults. Very severe faults would invoke this mode. Some of these faults would include any issues with the throttle position and severe pressure issues. During driving situations, an out of control throttle position can be very dangerous and can potentially lead to severe safety issues. The overall idea behind this mode is to leave everything in a safe neutral state where nothing can be controlled until the issues have been resolved and the system rebooted.

The first step this mode takes is it forces the displacement head back to neutral. Then it will force every signal relating to the throttle position to go to idle. This will make sure that everything is in a safe position. Once the issues have been dealt with, the system must be restarted in order to return the system to normal operation.


One of the necessary components our team needed in order to test our controller software was a basic model of the truck which integrated user feedback and simulate the hybrid components. Creating a working model of the hydraulic components on the truck was tricky, partially due to hardware

simulation restrictions. This was necessary so the team could test our new controller without breaking hardware components on the truck. When the team wanted to test a new controller design, the team would have to compile the code onto the hardware in order to simulate. The way the toolkit from MotoTron works is by using the basic components of Simulink to compile the programs down onto machine code for the ECU controllers. Because the MotoTron blocks are specific to their proprietary hardware controllers, the Simulink controls could not be simulated on a desktop computer. This formed a problem for creating a working model in Simulink because all of the variables needed to be run on the hardware components themselves and the user interface to the system were cumbersome and hard to change on the fly. The simulations were limited to real-time and could not inherit a different timing structure. This became a problem when trying to simulate multiple user events but not being able to queue up the events to test on the hardware. Even though there were many restrictions to what we can do with the MotoTron hardware, we managed to complete a basic linear feedback model of the

hydraulic system of the truck.

The team created different algorithms depending on the simulated user feedback. Four main algorithms to control the model were the actual and desired road speed, hydraulic accumulator pressure and throttle pedal position. For each of these components there are basic linear gains and offsets to allow the actual user to manipulate how quickly the model will change values and on what order of

magnitude. Below are a couple different components of the hydraulic feedback model used.



The model implemented has two different modes. The first mode allows the user to pass through particular values to the sensors to simulate single point data. The second mode uses the basic model of the vehicle to read the actuators and change the sensor outputs with given gains and offsets. The future plans for this particular model is to add dynamic components that change depending on how slowly or quickly the actuator values change. We would also like to create functions based on feedback from future data acquisition with less user interaction in order to get a model that more closely resembles the vehicles actual movement and response. Lastly, find a way to possibly simulate the MotoTron Simulink blocks on a desktop without the need for a MotoTron controller by either overriding the Simulink blocks depending on the environment or partitioning the main code where all of the proprietary MotoTron code is in one sub block of code which can be replaced with a Simulink model.

Trouble Shooting

During the past couple semesters, a majority of the teams time was spent working on over coming road blocks from the built in safeties of the truck and the incompatibility of the Mototron controller with the truck’s hardware. Many of these obstacles were hard to over come. The first roadblock the team ran into last semester was the truck does not support a common Controlled-Area Network (CAN) which was compatible with the controller hardware donated. CAN is how the team was relying on reading

information from the truck. The information we were hoping to gain was the current road speed, the engine torque, and the rotations per minute (rpm) of the transmission. The controller hardware is compatible with CAN communication and has built-in code to decode the stream of data coming from the truck, but the team was unable to use this because the truck model used the previous version of serial communication. The team finally overcame this road block close to the end of the semester. The solution was discussed in the serial communication section.

Some other minor road blocks the team had to overcome were the dashboard not working reliably and the truck battery dyeing multiple times. The dashboard has faulty wiring that randomly turns on and off the dashboard lights, speedometer, and fuel gauge indicators. A team member spent a week working on the problem and was never able to find the wire. The truck battery died multiple times due to the power consumption of the controller components consistently drawing a few amps when in


standby mode and drained the battery after a couple of days if no one drove the truck. The first time the battery died the team was not sure what was wrong with the truck so they were delayed a week while someone diagnosed the truck. The second time, the team had to charge the battery. This takes at least one hour, so more work was delayed. The team decided to run the truck whenever they were working on anything using the battery. Since then the battery has not been fully drained.

The team ran into two road blocks with the hydraulic system. They dealt with the pressure transducer and the accumulator tank. Unfortunately last semester’s team did not install the correct pressure transducer onto the truck. The pressure transducer converts the amount of pressure in the accumulator tank into a voltage that can be read into the Mototron controller. The Mototron controller can only handle a max voltage of 5 V, the pressure transducer installed on the truck outputted 10 V. This year’s team saw this and made a voltage divider for the 10 V output. Once this was in place the team could test the accumulator tank, the pressure transducer, and the controller. The readings the team collected were not correct. The reason for this was because the power supply of the pressure transducer can only be 5 V and pressure transducer was hooked to the 12 V coming from the battery. A new pressure transducer was ordered and installed correctly. The team in now able to successfully read how much pressure is in the accumulator.

One of the downfalls of the hydraulic system is that the bladder that holds the oil in the accumulator does not last very long. The bladder in the accumulator broke so the team has not been able to run any tests with their control algorithm. The vehicle’s hydraulic pipe connections did not have good seals which allowed the stored hydraulic pressure to escape and pushed the oil out of the tank and leaked over the parking lot where the truck is parked. The team is still waiting for the bladder to be repaired. The team did overcome a lot of road blocks this semester, but some the team could not over come because of the lack of time. The road block not overcome was replacing the bladder in the hydraulic accumulator. Overall, the current team would have appreciated the hardware, the controller, and the hydraulic system to work together without compatibility issues or the installation of incorrect parts, but the team did learn how to debug difficult problems and in the end the team gained life experience.

Section 4: Current and Future Automation Process

Part A: Current Status and Future Plans

The team has made sure that all the wiring in the truck is correct, all the hardware works together, and all of the individual components of the software work with the truck. This was a major accomplishment. Also, the team has successfully written a control algorithm that will pivot the displacement pump head depending on the amount of pressure in the accumulator and the position of the gas pedal.

By the time this paper is submitted the control algorithm will not have been tested on the truck due to delays in the project and the bladder being out of commission. The following week the team has reserved the airstrip where we have been doing our test runs and are planning on testing the control algorithm on the truck. Since this is the last week before finals if the control algorithm does not work then the next semester’s team will have to work out the bugs and test it. We are anticipating the control algorithm to work since we have tested it on the hardware by putting in realist inputs and monitoring the outputs.


If the control algorithm works, next semester’s team will optimize the pivoting of the displacement pump head. The reason for this would be to increase the fuel efficiency as high as possible and to smooth out the transitioning process. These are two important aspects of the system because if the hydraulic system does not increase the fuel efficiency or is a jerky ride no one will want to by the kit. Once the optimization is accomplished the team will work on the next generation system. This will be a series system. A series system is when the engine directly charges the accumulator or the mechanical energy from braking is collected in the accumulator. In the current system the only time the

accumulator is charged is when the truck is braking. The series system should be twice as efficient as the parallel system.



[1] Eaton. “Hybrid Power Systems: Hydraulic Launch Assist HLA System.” 2007. Retrieved on December 4, 2008, from

[2] Parker. Retrieved on December 4, 2008, from

[3] UPS. “Fact Sheets: UPS in Industry to Purchase Hydraulic Hybrid Vehicles.” Retrieved on December 4, 2008, from

[4] Singh, Sanjay. “Review of Urban Transportation in India.” 2005. Retrieved on December 4, 2008, from

[5] “Electronic Data Interchange Between Microcomputer Systems in Heavy-Duty Vehicle Applications.” Surface Vehicle Recommended Practice – J1587. January 1998. SAE International. July 2008.


Appendix A: Abbreviations

CO2: Carbon Dioxide

NOx: Nitrogen Oxide

UPS: United States Parcel Service ECU: Engine Control Unit

RPM: Rotations per Minute LIFO: Last in First out

BJT: Bipolar Junction Transistor DC: Direct Current

PWM: Pulse Width Modulation A2D: Analog to Digital

EECL: Engines and Energy Conservation Lab PID: Proportional-Intergral-Derivative


Appendix B: Budget

Fall Semester 2008 ECE Hydraulic Hybrid Budget

Notes Company Sum Account Balance

Start-Up Czero $50,000 $50,000

Sustaining Funds Colorado Governor’s Office

$25,000 $75,000

ECE Funding Colorado State University Electrical & Computer Engineering


$250 $75,250

Purchased Tools & Supplies

$777.49 $74,473

Purchased Tools & Supplies

$137.62 $74,335

Purchased Tools & Supplies




Related subjects :