Implementation and Testing of a Semi-Active
Damping System
Peter Nordin
Division of Fluid and Mechanical Engineering Systems
Degree Project
Department of Management and Engineering
LIU-IEI-TEK-A–07/00099–SE
Implementation and Testing of a Semi-Active
Damping System
Degree Project in Mechatronics
Department of Management and Engineering
Division of Fluid and Mechanical Engineering Systems
Linköping University
by
Peter Nordin
LIU-IEI-TEK-A–07/00099–SE
Supervisors: Anders Zachrison
IEI, Linköping University
Anders Bodin
BAE Systems Hägglunds AB
Examiner: Jonas Larsson
IEI, Linköping University
Avdelning, Institution
Division, Department
Institutionen för ekonomisk och industriell utveckling
Fluid och mekanisk systemteknik
Department of Management and Engineering
Fluid and Mechanical Engineering Systems
Datum2007-02-26 Date Språk Language Svenska/Swedish Engelska/English ⊠ Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ⊠
URL för elektronisk version http://www.ep.liu.se
ISBN
—
ISRN
LIU-IEI-TEK-A–07/00099–SE
Serietitel och serienummer
Title of series, numbering
ISSN
—
Titel
Title Implementation and Testing of a Semi-Active Damping System
Författare
Author Peter Nordin
Sammanfattning
Abstract
The purpose of this thesis is to implement and test a semi-active damping system based on a concept from an earlier thesis. The project includes implementation of mechanical, hydraulic and electronic hardware, aswell as controller software. The idea is to measure the movements of the vehicle chassis and based on these measurements set the damping torque using hydraulics. To be able to develop, test and evaluate the system, realistic input data must be available. To acquire such data, driving trials have been conducted on a variety of tracks.
The first part of the system is the sensors that measure chassis movements. Both accelerometers and a gyro has been used. To remove drift and high frequency vibrations, the signals are filtered. The suggested controller from the earlier thesis requests damping torque based on the dampers vertical velocity. When accelerom-eter signals are integrated, measurement and rounding errors causes drift in the velocity. To compensate for this, a floating average is calculated and used.
The main hydraulic component is a pressure reduction valve that controls the pressure inside the damper. Higher pressure will give higher damping torque. The reaction speed of the system is mostly depending on the hydraulic components. It is important to know the time delay from a change in the valve control signal, to when the actual pressure in the damper has been reached. Tests have shown that a large step, going from 10 Bar to 60 Bar takes approximately 46ms, and that a small step from 1 Bar to 20 Bar takes 63ms. The valve is faster when higher pressure levels are requested. In addition to the hydraulic response time the delay through the signal filters, measured to about 14ms, must be added.
The sensors are affected by vibrations. If these can be reduced, the digital filters can be made less sharp with a lower filter delay as result. It is also impor-tant to have a good control computer so that large rounding errors in the filter calculations can be avoided. This would greatly decrease drift in the integrated velocity.
Nyckelord
Abstract
The purpose of this thesis is to implement and test a semi-active damping system based on a concept from an earlier thesis. The project includes implementation of mechanical, hydraulic and electronic hardware, aswell as controller software. The idea is to measure the movements of the vehicle chassis and based on these measurements set the damping torque using hydraulics. To be able to develop, test and evaluate the system, realistic input data must be available. To acquire such data, driving trials have been conducted on a variety of tracks.
The first part of the system is the sensors that measure chassis movements. Both accelerometers and a gyro has been used. To remove drift and high frequency vibrations, the signals are filtered. The suggested controller from the earlier thesis requests damping torque based on the dampers vertical velocity. When accelerom-eter signals are integrated, measurement and rounding errors causes drift in the velocity. To compensate for this, a floating average is calculated and used.
The main hydraulic component is a pressure reduction valve that controls the pressure inside the damper. Higher pressure will give higher damping torque. The reaction speed of the system is mostly depending on the hydraulic components. It is important to know the time delay from a change in the valve control signal, to when the actual pressure in the damper has been reached. Tests have shown that a large step, going from 10 Bar to 60 Bar takes approximately 46ms, and that a small step from 1 Bar to 20 Bar takes 63ms. The valve is faster when higher pressure levels are requested. In addition to the hydraulic response time the delay through the signal filters, measured to about 14ms, must be added.
The sensors are affected by vibrations. If these can be reduced, the digital filters can be made less sharp with a lower filter delay as result. It is also important to have a good control computer so that large rounding errors in the filter calculations can be avoided. This would greatly decrease drift in the integrated velocity.
Acknowledgments
I would like to give special thank to, Joakim Emanuelsson and Johan Lundqvist for help with electronic and computer related problems, and Tore Sundqvist for measurement and testing assistance. I would also like to thank my supervisor Anders Bodin and all others who have granted me their time in order to give as-sistance in this project.
Linköping, February, 2007 Peter Nordin
Contents
1 Introduction 7 1.1 Background . . . 7 1.2 Purpose . . . 8 1.3 Presentation of Problems . . . 8 1.4 Method . . . 9 1.5 Outline . . . 9 1.6 Delimitation. . . 9 1.7 Goal . . . 9 1.8 Target Group . . . 92 Semi-Active Damping System 11 2.1 Tools and Interface . . . 11
2.1.1 Development and Testing Tools . . . 11
2.1.2 Programming . . . 12
2.1.3 Code Transfer. . . 13
2.1.4 Calibration and Interface . . . 13
2.1.5 TargetLink, DataDictionary and External Declaration . . . 13
2.1.6 Driving Trials . . . 14
2.1.7 Software Simulation . . . 16
2.2 Systems Overview . . . 17
2.3 Mechanical and Hydraulic Hardware . . . 18
2.3.1 Damper modifications . . . 18
2.3.2 Pressure Control Hydraulics. . . 19
2.3.3 Valve Plate and Hosing . . . 19
2.4 Electronic Hardware . . . 20
2.4.1 Accelerometers and Gyro . . . 20
2.4.2 Control Computer . . . 20
2.4.3 DSV . . . 22
2.4.4 Wiring and Connectors . . . 22
2.5 Damper Control Software. . . 24
2.5.1 Input Conversion . . . 25
2.5.2 Signal Filtering . . . 25
2.5.3 Integration . . . 30
2.5.4 Floating Average Drift Compensation . . . 31 ix
2.5.6 Velocity Recalculation . . . 35
2.5.7 Aurora Controller . . . 39
2.5.8 Rate Limiter, Backlash and Requested Pressure. . . 39
2.5.9 Output Conversion . . . 40
2.5.10 Interface Code . . . 41
2.6 Test Equipment. . . 43
2.6.1 Recreating the Recorded Signals . . . 44
3 Test Results and Conclusion 47 3.1 Simulation Results . . . 47
3.1.1 Drift . . . 47
3.1.2 Filter Effects on Acceleration . . . 48
3.1.3 Which is Faster, Accelerometers or Gyro? . . . 49
3.1.4 Damper Velocities at Exaggerated Bumps Track . . . 50
3.2 Test Results . . . 52
3.2.1 Hydraulics Alone . . . 52
3.2.2 Entire System Including Control Computer . . . 58
3.2.3 Recorded Tracks . . . 59
3.3 Conclusions . . . 62
3.3.1 Sensors . . . 62
3.3.2 Computer and Control Software . . . 62
3.3.3 Hydraulics . . . 63 3.3.4 Other Things . . . 64 Bibliography 67 A Recorded Signals 69 B Figures 74 C Offset Electronics 77 D Distorted Signal 79
Contents 1
List of Figures
1.1 Aurora controller requested torque based on vertical velocity . . . 8
2.1 Acceleration signal . . . 15
2.2 Gyro pitch signal . . . 16
2.3 Simulation environment . . . 16
2.4 Systems overview . . . 17
2.5 Damper modifications . . . 18
2.6 Hydraulic diagram . . . 19
2.7 Valve plate, sketch and final block . . . 20
2.8 Differential analog input . . . 21
2.9 Bode diagram for the RC filter with break frequency 60 Hz . . . . 22
2.10 Main and Aux connector on the BaseNode . . . 22
2.11 M23 12-Pole. . . 23
2.12 Gain of four different digital filters with normalised axis. . . 26
2.13 A first, second and third order butterworth filter. . . 27
2.14 Bode diagram for the accelerometer lowpass filter . . . 28
2.15 Bode diagram for the accelerometer high-pass filter . . . 28
2.16 Using 0.3 Hz HP . . . 28
2.17 Using 0.05 Hz HP . . . 28
2.18 Filter code block . . . 29
2.19 Integrator code blocks and connection to the reset system . . . 30
2.20 Velocity drift over 500 seconds . . . 31
2.21 Velocity after drift compensation . . . 31
2.22 Suddenly large drift when driving over bumps . . . 32
2.23 Smooth reset when integrator reaches overflow limit . . . 35
2.24 Axis definition in the vehicle . . . 36
2.25 Pitch velocity comparison . . . 37
2.26 Velocity to damper velocity calculation code block . . . 38
2.27 Damper velocity calculation based on ωxand ωy . . . 38
2.28 Aurora controller code block. . . 39
2.29 Torque measurement . . . 43
2.30 Pressure transducer . . . 43
2.31 Control computer and measurement equipment . . . 44
2.32 D/A converter program create with Labview . . . 45
2.33 Test equipment sensor positions, V for voltage and P for pressure. 45 3.1 Integrated velocity drift at 500 Hz . . . 47
3.2 Integrated velocity drift at 200 Hz . . . 48
3.3 Integrated velocity drift at MIL 500 Hz . . . 48
3.4 Velocity and acceleration at free fall . . . 49
3.5 Calculated damper velocity based on accelerometers and gyro. . . 50
3.6 Comparison of vertical velocity on the exaggerated bumps track. . 51
3.7 HP filter effect on partly constant signal . . . 51
3.9 Requested and measured pressure using linear scale. . . 53
3.10 Hysteresis curve for the valve . . . 53
3.11 Requested and measured pressure using a map . . . 54
3.12 Step response going from 1V to 7V in valve input. . . 54
3.13 Step response 2V amplitude in valve input. . . 55
3.14 Small steps originating from ≈ zero. . . 55
3.15 20 Bar constant pressure when pump is turned off . . . 56
3.16 40 Bar constant pressure when pump is turned off . . . 56
3.17 Leakage flow at different constant pressures . . . 57
3.18 Pressure and damping torque relation . . . 57
3.19 Pressure buildup when the vehicle is exposed to free fall . . . 58
3.20 Enlargement of the first 45ms showing the computer delay . . . 59
3.21 Pressure buildup delay at low pressures . . . 60
3.22 Pressure comparison using accelerometers . . . 60
3.23 Pressure comparison using gyro . . . 61
A.1 Measured rear sensors acceleration . . . 69
A.2 Measured front sensor acceleration . . . 70
A.3 Front left acceleration when driving on a forest road . . . 70
A.4 Front left acceleration when driving over exaggerated bumps . . . 71
A.5 Frequency spectrum, rear left sensor, reference-track . . . 71
A.6 Frequency spectrum, front left sensor, reference-track. . . 72
A.7 Frequency spectrum, gyro pitch signal, reference-track . . . 72
A.8 Frequency spectrum, front left sensor, forest road . . . 72
A.9 Frequency spectrum, front left sensor, exaggerated bumps track . . 73
B.1 Modified piston drawing . . . 75
B.2 The semi-active damping control system program . . . 76
C.1 The analogue summing op circuit . . . 77
C.2 Circuit diagram for one of the amplifier connections . . . 78
Contents 3
List of Tables
2.1 Connectors on the main port . . . 23
2.2 Connectors on the Aux port . . . 23
2.3 Pin assignment DSV . . . 23
2.4 Variables for accelerometer input conversion . . . 25
2.5 Variables for gyro signal input conversion . . . 25
2.6 Variables for the accelerometer filter . . . 29
2.7 Variables for the gyro filter . . . 29
2.8 Variables for integration . . . 30
2.9 Variables for floating average velocity . . . 34
2.10 Variables for recalculation of velocity . . . 37
2.11 Variables for Aurora controller . . . 39
2.12 Variables for rate and pressure conversion . . . 40
Abbreviations
A/D, D/A Analog to digital, or digital to analog
a2l, ASAP2 File format used to store information about variables
cal modifiable variable (calibrate able)
CAN Controler Area Network, communications interface
CCP CAN Calibration Protocol
disp displayable, (visible variable)
DSDD dSPace Data Dictionary, (store variables and definitions)
DSV Digital Smart Valve, (Valve electronics)
FIR Finite Impulse Respons, a type of digital filter IIR Infinite Implse Respons, a type of digital filter
MIL Model In the Loop
SIL Software In the Loop
Chapter 1
Introduction
Today a passive hydraulic mechanical rotation damper is being used in the vehicle. The damping torque depends on angle and angular velocity of the swing arm that the damper is attached to. In an earlier thesis [3] it has been shown through simulations that damper performance and ride comfort can be improved with a semi-active system over the passive system used today. This is achieved by using a proposed regulator called Aurora that controls the damping torque based on the chassis vertical velocity at each damper.
Aside from performance gains a new semi-active system can possibly save both money and weight. Something that is critical for the new generation of vehicles being developed.
1.1
Background
In a previous thesis [3] different semi-active damping control methods were evalu-ated in simulations using a model of the vehicle. The so called Aurora controller proved to give the best overall performance and ride comfort gains compared to the passive damper system used today. The Aurora is a modified sky-hook1controller but despite its advanced sounding name the Aurora is basically a proportional con-troller with two different proportional gains. The idea is to use a small p-gain for moderate vertical velocities and switch to a higher gain for large velocities. Large vertical velocities can be reached when the vehicle is driving over large bumps, or when jumping. It is only necessary with high damping for downwards velocity. When the vehicle hits the ground the high kinetic energy has to be absorbed by the suspension. If a very high damping torque is present this will help in slowing down the vehicle and to avoid strike-through. With parameter values proposed by [3] the controller will request damping torque based on vertical velocity according to Figure 1.1. The idea is to use this controller on every damper and use the vertical velocity at the damper location as reference signal.
1
Sky-hook means that the vehicle is thought to be hanging in the air, and thus ignoring rough ground. This means that chassis movement due to uneven ground is reduced.
−1.50 −1 −0.5 0 0.5 1 1.5 5 10 15 20 Aurora controller Vertical velocity [m/s] Damping Torque [KNm] Low gain 4 KNs High gain 17 KNs
Figure 1.1: Aurora controller requested torque based on vertical velocity The existing passive damper for the vehicle is a quite complicated block that contains many hydraulic components connected by drilled channels. The damper is a small closed hydraulic system. The actual damping comes from a multiple-disc brake. When force is applied from the side, the multiple-discs are pressed together and friction causes a torque when they rotate relative to each other. Depending on the swing arm angle a piston inside the damper moves and either pressurise or depressurise a compartment where a coil piston is pressed against the discs to cause the side force. Manufacturing this damper is expensive and complicated because of the many hydraulic components that has to be fitted inside. The hydraulic components also set surface finish requirements on the channels that combined them. When the dampers are manufactured the damper characteristics are set and not possible to change without replacing components. The vehicle is based on a modular design meaning that it can be configured for different purposes. This means that different damper settings might be desirable in different vehicle configurations. With a semi-active damper using a controller, control parameters can be adjusted easily. With a controller setting the pressure the damper itself can also be simplified. This background is based on results from thesis [3] and [4].
1.2
Purpose
The purpose of this thesis is to implement and test a semi-active damper with a control system based on the Aurora controller. Practical tests will show if sufficient performance can be reached. The hardware and software developed can be used as a base for future continued research and will help to identify difficulties and things to consider during development.
1.3
Presentation of Problems
To fulfil the purpose of this thesis, current damper hardware must be modified. Additional components might be necessary to construct. A control system software has to be developed and tested against realistic input signals. Electronic hardware
1.4 Method 9 should be selected, configured and evaluated. The type of communication between components need to be selected and appropriate wiring manufactured. Finally all parts will be put together an tested as a whole. Relevant tests that shows the combined system performance as well as the performance of individual parts should be conducted.
1.4
Method
The implementation will cover both mechanical and hydraulic hardware, computer hardware and software.
1.5
Outline
The thesis will be divided into three chapters. The first chapter will give an introduction and background. The second will cover both hardware and software system description. In the third chapter results from the final tests and conclusions will be presented. Theory, code and simulation results will be presented together in the appropriate subsections.
1.6
Delimitation
Existing dampers will be modified, no new damper will be constructed. No mathe-matical models of the vehicle or the damper will be made. No deeper comparisons with past results will be made.
1.7
Goal
The goal is to have a damper system capable of reacting and setting an appropriate damping torque within 0.1 seconds. The system must also be able to compensate for drifting signals.
1.8
Target Group
This thesis is intended for people with basic knowledge in control theory, signal processing and hydraulics.
Chapter 2
Semi-Active Damping
System
2.1
Tools and Interface
To be able to use the system efficiently for testing it must be possible to change control parameters while the system is running. It is time consuming to abort the test and reload or even recompile the control system software every time new parameter settings are to be evaluated. To evaluate the control software it is also desirable to be able to measure or log variable values from within the program. These logs are necessary for debugging and for showing what is actually happening inside the controller.
The best way of doing this is to let the controller receive new parameter settings from a remote computer and to send log data to this computer as well. The remote computer can then see to it that received log data is stored appropriately. This information exchange can either be done with a program specifically written for the task or by using a industry standard communication protocol called CCP "Can Calibration Protocol" through a CAN bus.
The purpose of the CCP protocol is to be able to calibrate systems while they are running. This will make development and prototyping faster and easier. Using the CCP protocol is ideal for the prototype semi-active system in this project.
Using the first alternative, a specifically written program, is probably more suitable at a later stage when and if the system is to be implemented in a produc-tion line vehicle and less data logging and parameter calibraproduc-tion possibilities are required. The system then only needs to interface with the main system in the vehicle. When the CCP protocol is used, a special calibration program is required.
2.1.1
Development and Testing Tools
To create the control program, compile and transfer data to the control computer and to interface with the system using the CCP protocol, different programs are used. This section will give and introduction to the development software. The
programs can be divided into two groups. Programming tools and interface tools. The first group consists of the programs used for creating the actual control system. Remaining programs are used for data transfer and interfacing.
Programing • Matlab Simulink
• dSPACE TargetLink 2.1.6 (addon to Matlab Simulink) • EDE Tasking 7.5
Interface and transfer
• A2L (ASAP2) generator, (python script) • BN load
• ATI Vision 2006
• PASO DSV
2.1.2
Programming
With Matlab Simulink and dSPACE TargetLink the control system itself is cre-ated using a graphical user interface. Blocks containing mathematical functions and operations are connected with lines to produce a signal flow. The graphical environment also offers the possibility to insert scopes into the program to view variables at certain positions in the program. After a simulation it is easy to see what has happened in the program and this makes it simpler to find problems like errors and program bugs. Simulink and TargetLink contains many useful common functions like integration, discrete filtering and table lookup. This speeds up pro-gram development as these function blocks only need to be copied from a library and not written specifically. The TargetLink addon is used to generate code from the graphical program construction. TargetLink contains special versions of the most common blocks from simulink. These blocks contain specific options for pro-duction code generation. The name and data type of variables in the generated code can be decided here. Variable value range, and if it should be saturated to avoid overflow, can also be set. One other very important setting is the fixed point number scale. Fixed point data types are used to store decimal numbers in a variable of integer data type.
After C-code has been generated with TargetLink the files are included into a EDE Tasking project. In the Tasking project several other files with c-code are also included, these contain instructions for how to use computer hardware, e.g. the A/D converter. Tasking is then used to do target specific code compilation for the control computer. The entire program is compiled into one binary image file.
2.1 Tools and Interface 13
2.1.3
Code Transfer
All interface with the control computer is done with ATI Vision. The binary file compiled from Tasking is loaded into the computer through the CAN-bus using CCP. In order to have a working CAN bus the first time a transfer is to take place a boot program has to be loaded into to computer first. There are two types of code to load into the computer, boot code and application code. The boot code is written and compiled in Tasking. It is transferred into the computer through RS2321with a program called BN Load, using bootload mode. This code is loaded in into the computer once. The application software can be replaced many times, even while the computer is running. This means that code corrections or additional functions easily can be added without having to disconnect the computer from the system it is controlling.
2.1.4
Calibration and Interface
To be able to recognise modifiable or viewable variables with Vision, a standard called ASAP2 is used. By using specific comments within the code a ASAP2 generator can recognise and generate an .a2l file including information about the variables. This file is loaded together with the binary image file into Vision. After the application program has been transferred into the computer it is possible to modify and monitor configured variables. If variables are added or modified in any way a new .a2l file has to be generated. The .a2l file is generated from c-code containing the variable declarations using the supplied a2l-generator. To declare a variable modifiable the following code is used.
#pragma c l a s s FC=CAL
const s16 v a r i a b l e ; <− D e c l a r e c a l i b r a t a b l e v a r i a b l e . #pragma c l a s s FC=CFARROM
To make it visible in Vison a special comment must be added. It can look like this. ///unit=Bar comment="Maximum pressure" conv=x/256 range=0-100. Here a conversion from what is shown on the screen or entered, to the actual value can be specified. The allowed variable range can also be set.
2.1.5
TargetLink, DataDictionary and External Declaration
In TargetLink there is something called the DataDictionary. This is a data base were all variables and fixed point scales being used can be collected. It contains information about e.g. data types, scalings and range. It is easier to find and change variables in the database then to go through the dialogs in each code block. It is also very useful if the same variable is used at several places. Changes to the variable then only need to be done in the database instead of at every block. This advantage specifically apply to the different fixed point scales. Often
1
many different variable share the same scale. By referencing to a database scale it is possible to change the scaling for all these variables at one place. TargetLink is supposed to be able to generate ASAP2 files for use with CCP tools. This function unfortunately did not work very well with the version of the program used in this project. Instead the variables that are to be visible or modifiable must be externally declared in c-code. In the data dictionary it is possible to choose if a variable is externally declared. During development it is common to change the fixed point scales. If all variables are externally declared their given value has to be modified in the c-code file every time a change is done. The scale settings in the data dictionary does not work if external declarations are used. For simulations it is easier to use non external declarations as no ASAP2 file needs to be generated. Two different database files can be used. One for simulation and another for producing code intended to go into the control computer. The variable settings in the second file should specify that selected variables are externally declare. Changes and additions must be made in both files. If no or very few changes are expected, it is easier to only use the file with external declarations. Note! not all variables need to be declared externally, only those that shall be visible or possible to modify.
In TargetLink it is possible to do both MIL (model in the loop) and SIL (software in the loop) simulation. During MIL simulation all variables are double precision floating point numbers. This mode can be used to verify that certain things work as they are supposed to, before production code options are applied. SIL simulation on the other hand is used to test the created production code including e.g. fixed point data types and their influence on the system. The code blocks in TargetLink contains options for both MIL and SIL mode. MIL variables are taken from the matlab workspace or can be specified with matlab syntax directly in the block. If the MIL variables and the SIL variables in the data dictionary are not the same an error will occur during code compilation. If variables are changed often it becomes very time consuming to do changes both in matlab and the database. A faster way to do it is to use a matlab .m script to give the variables their values. In the data dictionary the variable name can then be specified to be the same as the variable name in the .m script. Now if only the scaling is given in the dictionary the value and size will be taken from the variables on the matlab workspace. As both MIL and SIL will use the workspace variables errors and double work can now be avoided.
It would be easier to work with TargetLink if all variables could be placed in the data dictionary or be declared externally in a c-file or .m script. Using only external declaration and .m script will make simulation more troublesome if values and scales are changed often. Using only the database or a database and .m script combination will cause problems with ASAP2 generation, at least with DSDD version 1.3.6 used in this project.
2.1.6
Driving Trials
When developing the software, it is useful to have realistic acceleration data. With-out realistic data it is not possible to determine if and how good the filters and the
2.1 Tools and Interface 15 average calculations work. To acquire realistic data driving trials are conducted in a few different types of terrain. These include a standardized reference-track, exaggerated bumpy terrain and a rough terrain track. On the reference-track two different speeds are tested. An earlier thesis has shown that pitch and roll move-ments when driving over the reference-track differs depending on speed. Driving discomfort due to oscillations are greater at lower speeds. While risk for strike-through is greater at higher speed. To have somewhat comparable measurements, trials are done at 20 Km/h and 40 Km/h.
On the reference-track it is easy to maintain a somewhat constant speed but in rougher terrain this is not possible since the driver has to adapt speed to the terrain. For the exaggerated bump-track, slow, medium and high speed are used. Low speed is about 10 km/h and high is 15 - 20 km/h. Recordings while driving at maximum speed on a "forest road" are also conducted. Maximum speed means around 60 km/h.
These tests will give a variety of accelerometer signals to use in the development of the software. The sensors on the vehicle are four accelerometers, one in each corner, and a 2-axis gyro to measure pitch and roll angular velocity. By using both accelerometers and a gyro, signals from two different type of sensors can be studied. It is useful to see how the two different sensors react to noise and vibrations. Figure2.1 and Figure2.2 shows the difference between the recorded acceleration from one of the rear accelerometers and the measured angular pitch velocity from the gyro. It is obvious that the accelerometer is more sensitive to vibrations than the gyro. This is due to the fact that the gyro measures velocity instead of acceleration. For a more detailed description of the recorded signals, including frequency spectrum, see Appendix A.
Figure 2.2: Gyro pitch signal
2.1.7
Software Simulation
As mentioned earlier the software can be run in SIL (software in the loop) mode. This means that a build of the generated code is used. To give this build appro-priate input signals and measure internal variables as well as final output, it is run inside a Simulink environment. The input is read from matlab workspace vari-ables. These must be loaded with a script from the recorded .dac files. Once the simulation is run, the signals are down sampled, filtered and rescaled to emulate the effects of passing through the computer hardware before entering the program. The computer inputs are described later in2.4.2. Figure2.3shows the simulation environment. All scopes are set to save all data to workspace variables.
v_int v_compensated v_avg req_pressure gyro_recalc gyro_filt aurora_out acc_recalc acc_filt Wxy_calc Wv_damp Vv_damp Scope3 Saturation2 Saturation1 acc gyro out. LPfilt acc_recalc Gyro_recalc acc_filt Gyro_filt v_int v_avg Wxy_calc Vv_damp Wv_damp aurora_out Req_pressure TargetLink Software− in−the−loop mode SAD Out_voltage LPfilt Out1 Out2 Out3 Out4 Out5 Out6 Input 2.5 Gain5 1024/5 Gain4 12/256 Gain3 1 Gain2 1024/5 Gain1 Damper4 Damper3 Damper2 Damper1 Add
2.2 Systems Overview 17
2.2
Systems Overview
In the vehicle the current dampers are situated at wheel pairs 1, 2 and 7, this means that there are two dampers on each side in the front of the vehicle, and one on each side in the rear. The location for the new dampers will be the same. Instead of having the swing arm angle determining the damper torque, hydraulic pressure from the main hydraulic system will be used. The pressure will be controlled by a pressure reducing valve. To keep cost, weight and space consumption down, only one valve will be used for each pair of dampers in the front. To ensure that a stable high pressure is available at the input port at all times an accumulator will be connected to each valve. The control system will set the damper pressure based on the vertical velocity at each damper.
Since it is difficult to measure velocity relative to the ground directly, ac-celerometers are placed close to each damper. There will be one in each corner of the vehicle. The measured acceleration is fed into a control computer were the sig-nal is filtered and integrated into velocity. The Aurora controllers then determine the pressure in each damper based on the velocity. Signal noise, accelerometer drift and measurement uncertainties will cause the integrated velocity to drift. To handle this problem a floating average will be calculated and used for drift compensation.
2.3
Mechanical and Hydraulic Hardware
2.3.1
Damper modifications
In a semi-active version of the damper the pressure that causes the force on the disk brake is controlled and supplied from outside of the damper itself. This means that the damper can be made much less complicated. As the hydraulic components used to control the pressure are situated outside the damper all that is needed is an input channel for the hydraulic oil. Luckily there is an old version of the damper that have an input channel. It is the older type of passive damper that has a constant damping torque caused by the force from a few cup spring packages. The pressure input could be used to stiffen the vehicle by locking the dampers. Some modifications to this damper are necessary to make. The spring packages are removed and replaced with smaller compression springs similar to those that are being used in a newer version of the damper. These springs are used to keep play between the piston and the disks to a minimum. In order to keep these springs in place the piston has to be modified with small holes. The modified piston is a combination between the old one and the newer one. Figure2.5shows a cut from the drawing of the old damper and a CAD model of the modified piston. In the figure the cup spring packages can be seen to the left, the piston in the middle and the disks to the right. Appendix B includes a drawing of the piston. The compression springs have been selected to give approximately the same force as the springs in the current (more complicated) passive damper.
The input pressure will need to come from the inside of the vehicle since the hydraulic hosing is located there. A channel needs to be drilled through the bearing housing into the damper house. Fortunately the bearing housing is prepared for this. The only modification necessary to make is to change the coupling from an ISO G 1/2" to an ISO G 1/4". The compartment with disks is filled with motor oil for lubrication. The pressure compartment will be filled with hydraulic oil. It is important that the o-rings can seal the two spaces from each other so that the two oils do not mix. To ventilate the hydraulic compartment the hole above the spring packages in Figure2.5can be used.
2.3 Mechanical and Hydraulic Hardware 19
2.3.2
Pressure Control Hydraulics.
To set the pressure inside the damper a pressure reduction valve is used. One important requirement for this valve is that it must be able to control the static pressure on the output port all the way down to tank pressure. If the valve can not handle this the damper will always output a damping torque, something that is not desirable. The pressure reduction valve can only give a specific output pressure given that the input pressure is higher. To guarantee that the input always is pressurised an accumulator tank will be connected to the input port of the valve. In the vehicle the main hydraulic system pump will not be continuously running, in bench testing however, it will be. A check valve at the input port will see to it that no oil flows backwards from the accumulator if the main system pressure drops. After the pressure reduction valve a pressure relief valve will be used to limit the pressure during development and testing. Figure2.6shows the hydraulic diagram.
Pressure relief valve Accumulator
A1 Pressure reducing valve
Control signal T
P
A2
Figure 2.6: Hydraulic diagram
2.3.3
Valve Plate and Hosing
The hydraulic components need to be attached and connected to each other. For this a valve plate is needed. The block should be as small as possible and allow for some way of fastening. The material should be of the same type as all other valve plates used in the vehicle, SAPA 1711 aluminium.
The hosing for the hydraulic oil will be the same for all ports. Hose couplings will be ISO G 1/4". The return to tank will not pass through a filter as resistance would cause a higher lowest pressure in the damper preventing the system from setting zero damping torque.
Figure 2.7: Valve plate, sketch and final block
2.4
Electronic Hardware
The electronic hardware is made up by • Accelerometers / Gyro
• Control computer
• Pressure reducer electronics • Wiring
• Power supply
2.4.1
Accelerometers and Gyro
Since the test rigg will use recorded accelerometer signals no specific model is se-lected. When the signals were recorded the following accelerometers were used. Endevco 7290A-50 capable of measuring ±50 g with a sensitivity of 40 ± 2 mV/g. This sensor can measure frequencies up to 1000 Hz with an amplitude response of ±5%. Using this kind of high quality sensor guaranties a realistic measure-ment. This kind of sensor is way too expensive for use in production though. Unfortunately not much is known about the available gyro.
2.4.2
Control Computer
The computer selected for controlling the system is a Mecel BaseNode 320N. This computer unit is based on a 40 MHz 16-bit Infineon C167 micro controller and have three CAN-bus interfaces and eight analog inputs with the possibility to use four of them as outputs. The foremost reason for using this computer is that it have been used earlier at Hägglunds in various projects. Also boot code and application code for a different project already exists. This will greatly shorten the time it will take to set up and begin using the computer. Things like CCP protocol and A/D
2.4 Electronic Hardware 21 converter code is already implemented. This means that only the application code, the control software itself has to be created. Some modifications of the remaining code will also be necessary.
The BaseNode have two connectors, Main and Aux. For a complete list of what the two connectors contain see 2.4.4. The analog inputs are made up of four inverting amplifiers and four differential non inverting amplifiers according to [6]. Each input have an analog low-pass filter called an RC-link between the amplifier and A/D converter. According to [5] the transfer function for this filter is Uout = 1+jωRC1 Uin and the break frequency ω = RC1 rad/s which means that the break frequency in Hz is f = 2πRC1 . The default configuration with R = 10KΩ and C = 33nF gives a break frequency of 482 Hz. By increasing the resistance to R = 80KΩ the break frequency is changed to 60 Hz which is more suitable. Figure2.9shows the filter. The input amplifier is used to rescale the input voltage to fit the 0−+5V A/D converter with 10-bit resolution. The resolution and voltage range mean that a converter input of 5V will give the value 11111111112= 102310.
0V will give 02= 010. It is possible to change the input scale by changing resistors.
For this project resistor R33 has been removed. The resulting input scale of 1 is better adapted to the signal source used for final tests, 2.6.1 explains this equipment further. Note! Two of the inverting and two of the differential inputs can be used as analog outputs instead, refer to the [6] for more information.
Figure 2.8: Differential analog input
To output an analog signal the BaseNode is equipped with a MAX500AEWE 8-bit D/A converter. As the data sheets for some reason did not show the voltage range, it has been measured by giving 25510= 111111112as input to the converter.
−15 −10 −5 0 Magnitude (dB) System: RC Frequency (Hz): 60.1 Magnitude (dB): −3.03 100 101 102 103 104 −90 −45 0 45 90 Phase (deg)
Bode Diagram RC Filter
Frequency (Hz)
Figure 2.9: Bode diagram for the RC filter with break frequency 60 Hz
2.4.3
DSV
The pressure reduction valve is equipped with something called DSV electronics. DSV stands for Digital Smart Valve. With the DSV unit it is possible to adjust scale offset and dead band for the input signal. It is also possible to adjust dither signal, solenoid current, and ramps. With the DSV it is possible to tune the valve response to the signal being used. It can take both voltage and current as the preset value, and will then see to it that the appropriate current is applied to the solenoid in the valve. The valve with DSV, used in this test equipment do not have a built in pressure regulator. This means that it is important to know what the resulting pressure becomes depending on the input voltage.
2.4.4
Wiring and Connectors
Figure 2.10: Main and Aux connector on the BaseNode
2.4 Electronic Hardware 23 to [7] the micro controller can be loaded with a new boot program when pin 7 (RD boot) has the input logic "0". A logic "0" is obtained by connecting the pin to ground. A logic "1" is the result if the pin is NC (not connected). The connector on the valve electronics2.4.3is a M23 12-pole female plug. Note! For these tests all inputs are on the AUX connector. If all four outputs are to be used two inputs has to be moved to the main connector.
Main connector Pin nr Connection
7 Bootstrap switch, 0=boot loader mode, 1=run mode 8 Analog ground, output signal reference
9 Power supply -, also gnd for RS232 and bootstrap switch. 10 Not used, Ch4. AD-channel 13 (P5.13)
11 Not used, Ch3. AD-channel 12 (P5.12)
12 Signal+, front left damper, Ch2. AD-channel 11 (P5.11) 13 Signal+, rear left damper, Ch1. AD-channel 10 (P5.10) 14-15 RS232, for boot program loader transfer
18-19 CAN-A, connected but not used
28 Power supply +
Table 2.1: Connectors on the main port
Aux connector Pin nr Connection
1-2 CAN-C, used for CCP protocol, (Can calibration and logging) 19 Analog ground, common ground for computer and signal source. 20-21 Diff input, rear right sensor. AD-channel 15 (P5.15)
22-23 Diff input, front right sensor. AD-channel 14 (P5.14) 24-25 Diff input, front left sensor. AD-channel 9 (P5.9) 26-27 Diff input, rear left sensor. AD-channel 8 (P5.8)
Table 2.2: Connectors on the Aux port
Figure 2.11: M23 12-Pole
DSV Connector Pin Connection
1 Power supply +24VDC
2 Power supply 0V
4 Preset voltage + (Out + from computer) 5 Preset voltage - (AGND from computer) 10 Enable control, (24VDC = on, NC=off) 12 Chassis, connected but not used
2.5
Damper Control Software.
The damper control software is made up by four primary parts. • Signal filtering and integration
• Floating average calculation • Velocity recalculation • Aurora controllers
A figure showing the entire program from TargetLink is available in AppendixB. After the A/D converters in the computer have digitalised the analog signals the software takes over. The signal first pass through a digital filter that suppresses high frequency vibrations and noise. After this the acceleration is integrated into velocity. Accelerometer drift and calculation errors will make the velocity drift. By calculating an average velocity this drift can be negated. Velocity recalculation is used to move the integrated velocity from the position of the sensor to other places in the vehicle. The fourth part is the Aurora controller itself that generates the wanted damping torque. The control signal is rescaled to fit the pressure reducing valve and is then sent out to the D/A converter.
The control computer is based on a 16-bit micro controller. It can use data types larger then a 16-bit integer but calculations will then become more com-plicated and take more processor cycles to complete. The use of floating point numbers should be avoided if possible. Instead of a floating point format a fixed point format can be used. With the fixed point format, decimal numbers can be stored in a variable of integer data type. In a fixed point variable the decimal point is fixed at a certain bit. The number has a scale expressed as 2−∗ were * is a bit number. The fixed point number is best explained with an example. Fixed Point Example
If a variable of data type, unsigned short integer, is used with a scale of 2−10, the 10 lowest bits are used for the decimal part of the number and the 6 highest bits used for the integer part. 000000
| {z } Integer
. 0000000000
| {z }
Decimal
. Since this is a unsigned integer it will be able to store numbers between 0.0 and <64. The maximum value the six first bits can represent is 1111112= 6310. The last bits can represent 11111111112= 102310.
That means 1023 different decimal steps resulting in a resolution of 1
1023 = 9.7752 ·
10−4 per step. If the variable is a signed variable the range will be about -31 to <32.
By anticipating reasonable maximum and minimum values of variables a fixed point scale that offers the best possible decimal resolution can be selected. The more decimal bits the better resolution, however at the expense of range. High resolution give less rounding errors. To avoid overflow TargetLink gives the option to saturate on the max and min limits. The saturation function should be avoided if it is not necessary as it requires more computations.
2.5 Damper Control Software. 25
2.5.1
Input Conversion
The first thing that happens with the signal when it enters the control program is that it is converted from the integer number given by the A/D converter to the acceleration in g that it represents. The converter has a resolution of 10 bits and an input voltage range of 0 − 5V . This means that 5V will be represented by 11111111112= 102310. If the scale from the sensor (V/g) also is regarded the
calculation looks like this. ameas= 5 1023· 1 sensor_scale | {z } V olt_to_acc ·A/D_data (2.1)
Name Unit Data Type Scale CCP
Input: A/D_data - Int16 2−0 disp
Output: ameas [g] Int16 2−13 disp
Parameters: Volt_to_acc - UInt16 2−18 cal
Table 2.4: Variables for accelerometer input conversion
Name Unit Data Type Scale CCP
Input: A/D_data - Int16 2−0 disp
Output: gyromeas [rad/s] Int16 2−15 disp
Parameters: V olt_to_ω - Int16 2−18 cal
Table 2.5: Variables for gyro signal input conversion
2.5.2
Signal Filtering
To filter the measured accelerometer signal a digital time discrete filter and an ana-log pre-filter is used. The pre-filter is built into the anaana-log input on the BaseNode. Since the chassis movement frequency is low and vibrations and measurement noise have relatively high frequencies, low-pass filters will be used. There are many dif-ferent types of digital filters that are suitable. Since the signal contains unwanted frequency components close to those that are to be measured a sharp filter is de-sirable. This would let frequencies below the cutoff frequency to pass unaltered but suppress frequencies above.
Figure 2.122 shows four types of IIR3 low-pass filters. These are all sharp filters. The Butterworth filter has a flat pass and stop band. The others have ripples in the pass band, stop band or both. They are however slightly sharper than the Butterworth filter. Ripples in the passband are unwanted since this will distort the interesting signal. The choice stands between the Butterworth filter
2
The filters have been created with, Matlab Signal Processing Toolbox, tools.
3
0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Butterworth 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Chebyshev type 1 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Chebyshev type 2 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Elliptic
Figure 2.12: Gain of four different digital filters with normalised axis.
or the Chebyshev type 2 filter. Aside from the amplitude change the phase shift is also important. The phase delay caused by the low-pass filter results in a time delay of the signal that have passed the filter. As the goal is to have a system that can react within 0.1 seconds the time delay through the filter must be kept as low as possible. This will give more room for other unavoidable time delays in the system. The Chebyshev filter has a larger time shift then the Butterworth filter. Therefore the later will be used.
By changing the filter order the sharpness of the filter can be adjusted. Higher filter order gives a sharper filter. A sharper filter will make frequencies below the cutoff frequency less affected and frequencies above it even more suppressed. Very high order filters would be good from a amplitude suppression point of view, however, an increased order have a downside too. A higher order filter have larger phase shift than a lower order one. This means that the time delay is increased if the filter order is. There is also a filter type called FIR4 filters but according to [8] they often requires a much higher filter order than IIR filters to have the same performance. As higher filter order means higher time delay, a FIR filter should not be used.
Since a reaction time of 0.1 seconds is desirable the cutoff frequency should be higher than 10 Hz. Otherwise important signals might be filtered out. Figure2.13 shows the difference between a first, second and third order Butterworth filter with a cutoff frequency of 10 Hz.
The filter selected for implementation is of the second order. The phase delay of the third order filter is to large. There are also problems with representing the filter coefficients with the 16-bit fixed point data type. Higher order filters are more distorted by the rounding errors than lower order ones. A second order filter gives
4
2.5 Damper Control Software. 27 −15 −10 −5 0 Magnitude (dB) 100 101 102 −270 −225 −180 −135 −90 −45 0 Phase (deg) Butterworth Filters Frequency (Hz) Order: 1 Order: 2 Order: 3
Figure 2.13: A first, second and third order butterworth filter.
acceptable results while a third order one does not. To optimise data type usage the filters have been created with the Matlab Filter Design & Analysis Toolbox together with the fixed point toolbox. This tool will give the filter coefficients together with the most optimal scale for use with a certain bit-width, in this case 16-bits. The low-pass filter used in the program has a magnitude and phase curve as shown in Figure2.14. The cutoff frequency has been set to 15 Hz.
High-Pass Filter
The accelerometers and the gyro both have a slow drift and a more or less constant offset on their output signal. The offset on the accelerometer signal will look like a constant acceleration which in turn will cause a continuously increasing velocity in the integration. To avoid this the offset has to be removed. This is best done with a high-pass filter. This filter works in the opposite way to the low-pass filter described earlier. It lets frequencies above the cutoff frequency pass and blocks those below. The result is that the constant offset and the slowly changing drift of the signal is removed. For this a Butterworth filter is also used. The accelerometer high-pass filter is shown in Figure2.15
The same low-pass filter is used for both accelerometers and gyro but the high-pass filter is not the same. The break frequency is lowered for the gyro. Figure2.16shows what happens with the gyro signal when the same HP filter as for the accelerometers is being used. This filter has a break frequency of 0.3 Hz. Figure 2.17Shows the same signal with a high-pass break frequency of 0.05 Hz. The higher break frequency seem to distort the signal in the gyro. It is necessary for the accelerometer signal though. The accelerometer drift is higher and change more rapidly than in the gyro.
−15 −10 −5 0 Magnitude (dB) System: LP Frequency (Hz): 14.9 Magnitude (dB): −3.02 10−1 100 101 102 103 −180 −135 −90 −45 0 Phase (deg)
Bode Diagram LowPass Filter
Frequency (Hz)
Figure 2.14: Bode diagram for the accelerometer lowpass filter
−15 −10 −5 0 Magnitude (dB) System: HP Frequency (Hz): 0.301 Magnitude (dB): −3.02 10−2 10−1 100 101 0 45 90 Phase (deg)
Bode Diagram HighPass Filter
Frequency (Hz)
Figure 2.15: Bode diagram for the accelerometer high-pass filter
30 35 40 45 −0.3 −0.2 −0.1 0 0.1 0.2 0.3
Bad Filtered Gyro Pitch Signal
Time [s]
Angular pitch velocity [rad/s]
Unfiltered Filtered Figure 2.16: Using 0.3 Hz HP 30 35 40 45 −0.3 −0.2 −0.1 0 0.1 0.2 0.3
Better Filtered Gyro Pitch Signal
Time [s]
Angular pitch velocity [rad/s]
Unfiltered Filtered
2.5 Damper Control Software. 29 The accelerometer filter code block is shown in Figure2.18, the gyro filter looks the same, but only contain two signals, pitch and roll.
2 LPfilt 1 a_filt LPDen500(z) LPNum500(z) Lowpass Filter3 LPDen500(z) LPNum500(z) Lowpass Filter2 LPDen500(z) LPNum500(z) Lowpass Filter1 LPDen500(z) LPNum500(z) Lowpass Filter HPDen500(z) HPNum500(z) Highpass3 HPDen500(z) HPNum500(z) Highpass2 HPDen500(z) HPNum500(z) Highpass1 HPDen500(z) HPNum500(z) Highpass01 1 a
Figure 2.18: Filter code block
Name Unit Data Type Scale CCP
Input: ameas [g] Int16 2−13 disp
Output: af ilt [g] Int16 2−13 disp
Parameters: LPNum500 - Int16 2−20
-LPDen500 - Int16 2−14
-HPNum500 - Int16 2−15
-HPDen500 - Int16 2−14
-Table 2.6: Variables for the accelerometer filter
Name Unit Data Type Scale CCP
Input: gyromeas [g] Int16 2−15 disp
Output: gyrof ilt [g] Int16 2−15 disp
Parameters: LPNum500 - Int16 2−20
-LPDen500 - Int16 2−14
-NumHP500Gyro - Int16 2−15
-DenHP500Gyro - Int16 2−14
2.5.3
Integration
In the integration block the filtered accelerometer signals are integrated into ve-locity. The integrators have a reset input that make it possible to avoid integrator overflow or saturation. The integrator blocks implement time discrete integration and the appropriate sample time has to be specified. Due to limits in the data type range the integrated value risks overflow if it gets to high. To avoid overflow the integrators are saturated at 30 m/s. Normally vertical velocities of that magnitude will never be reached, but measurement and calculation errors will cause drift in the integration. How this problem is solved is explained in2.5.4and 2.5.5. The integrator limits, as well as the sample time is hard coded into these blocks. It will not be possible, or necessary, to change these parameters without recompiling the program. 2 Saturation 1 V_int 1 z Unit Delay Saturation1 OutPort1 OutPort InPort2 InPort z−1 T Discrete−Time Integrator4 z−1 T Discrete−Time Integrator3 z−1 T Discrete−Time Integrator2 z−1 T Discrete−Time Integrator1 |u| Abs 2 in.2 1 in.
Figure 2.19: Integrator code blocks and connection to the reset system
Name Unit Data Type Scale CCP
Input: af il [m/s2] Int16 2−12
-vlast [m/s] Int16 2−10
-Output: vint [m/s] Int16 2−10 disp
sat_warning [logic] UInt8 2−0
-Parameters: - - - -
2.5 Damper Control Software. 31
2.5.4
Floating Average Drift Compensation
Because of sensor drift, losses in the digitalisation of the signals and rounding errors due to the fixed point numbers and data type, the filtered acceleration signal will contain errors. When the signal is integrated into velocity, these errors will affect the resulting velocity. Output from the integrator will drift. If a floating average velocity is calculated, it is possible to compensate for this drift. The average velocity will act as a floating zero velocity reference around which the real vertical velocity changes. Figure2.20shows the drifting velocity and the floating average based on five second old values. By subtracting the average value from the integrator output the influence of drift is removed, as shown in Figure2.21.
0 100 200 300 400 500 −3 −2 −1 0 1 Integration drift Time [s] Velocity [m/s] Integrated Average
Figure 2.20: Velocity drift over 500 seconds
0 100 200 300 400 500 −2 −1 0 1 2
Velocity compensated for drift
Time [s]
Velocity [m/s]
Since the average is based on old data it will lag behind the real average. The drift can be low or high depending on how the input signal looks. The error in the drift compensated velocity caused by the lag will vary depending on how large the drift is. If the drift make the velocity constantly increase, there will be a constant error due to the lag. Faster constantly increasing drift gives a larger constant error. Large drift seem to happen in areas of sudden movement, like when driving over bumps. When driving on flat terrain the drift is lower unless vibrations are very high. Figure 2.22 shows both these cases. If the time on which to base the average is increased sudden changes will become more visible. If the time is decreased the average will follow changes more quickly. During simulations it has been found that a time of five seconds is suitable. This might seem like a short time, but because the drift can change quit rapidly it is necessary to keep it short if unnecessary damping torque should be avoided.
80 90 100 110 120 130 140 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8
Drift at bumpy parts of track
Time [s]
Velocity [m/s]
Integrated Average
Figure 2.22: Suddenly large drift when driving over bumps
The floating average block is also connected to the same reset system as the integrators. The average must be reset at the same time as the integrators to avoid a result that make it seem as if the chassis would have very high vertical velocities.
2.5 Damper Control Software. 33 The floating average block has been written with the following c-code.
/∗ f x p _ o u t p u t _ b e g i n ∗/ i f ( warning == 1 ){ avg_value = 0 ; the_sum = 0 ; f o r ( i = 0 ; i <= avg_length −1; i ++) o ld_v a lue s [ i ] = 0 ; } e l s e i f ( ( c o u n t e r % avg_skip ) == 0 ){ inde x = c o u n t e r / avg_skip ;
the_sum = the_sum − ( int ) o ld_v a lue s [ inde x ] ; o ld_v a lue s [ inde x ] = input ;
the_sum = the_sum + ( int ) input ;
avg_value = the_sum / ( int ) avg_length ; }
output = ( short int ) avg_value ; /∗ fxp_output_end ∗/
/∗ fx p_u pdat e_begi n ∗/ c o u n t e r++;
i f ( c o u n t e r > counter_max ) c o u n t e r = 0 ;
/∗ fxp_update_end ∗/
If the reset warning flag has been raised the average value is reset to zero. If not, the code checks if it is time for a new calculation. It is possible to set how often new values should be calculated, this can help reduce memory requirements. All values from the last set number of seconds are stored in an array. The more frequently the calculations are made the larger the array gets. Instead of summarising all of the array elements every time the code runs the sum is stored in a separate variable. Each time a new average is to be calculated the current velocity value is added to the sum and the oldest value stored in the array is subtracted. This will increase calculation speed significantly. The parameters are not declared in the code itself but instead inside the TargetLink custom code block.
• avg_lengthdetermines the length of the array to store old values in. • avg_skipis the number of times to skip between each new calculation. • counter_maxrepresent the number of seconds to base the calculation on.
Example Parameter Calculation
If the calculation is based on five seconds old values and the program is running 500 times each second the counter_max parameter should be 5 · 500 = 2500. If 100 samples are skipped between calculations the average will be updated 5 times a second. The array should then have to be 5 · 5 = 25 elements long. One has to be added to this length to make room for an extra calculation every time the counter is reset to zero, the modulo operator is the cause of this. This means that avg_length will be 26. If fewer samples are skipped the output average velocity curve will be smoother, more skips will make it more jagged but allow for fewer calculations and a smaller data array.
Name Unit Data Type Scale CCP
Input: vint [m/s] Int16 2−10 disp
sat_warning [logic] UInt8 2−0
-Output: vavg [m/s] Int16 2−10 disp
Parameters: avg_length - Uint8 2−0
-avg_skip - Uint16 2−0
-counter_max - UInt16 2−0
-Table 2.9: Variables for floating average velocity
2.5.5
Anti Saturation
The variable that stores the integrated value in the integrators have a limited data range just as all other variables. Depending on the number of bits and fixed point scale there is a certain maximum and minimum value it can store before overflow occurs. The integrators are set to saturate their output to avoid overflow. A saturated output is not good either though. If the velocity value has drifted all the way to the saturation limit, velocity changes above the limit will have no effect. To avoid this problem an anti saturation system will reset both the integrators and the average calculations. The trigger will be the saturation warning outputs from the integrators. When a reset occurs, the average value is set to zero and the integrator value is set to the difference between integrator and average in the last time step. This means that even if the velocity would be in a top or bottom of an oscillation when the reset happens the integration will continue as if nothing has happened with the difference that it is now integrating around zero again. Figure 2.23 shows this. The saturation limit has been decreased to ±2 so that the event can occur more easily. As the integrated value reaches -2 the average is reset to zero and the integrator reset to the last difference between integrated and average velocity. The smooth result can be seen in the line named difference. The reset is not visible in the resulting signal on which the output pressure is based.
2.5 Damper Control Software. 35 47.8 48 48.2 48.4 48.6 48.8 −2 −1.5 −1 −0.5 0 0.5 Integrator reset Time [s] Velocity [m/s] Integrated Average Difference
Figure 2.23: Smooth reset when integrator reaches overflow limit
2.5.6
Velocity Recalculation
The velocity recalculation blocks uses rigid body kinematics to move the velocity from the accelerometer positions into other positions in the vehicle. The results from the earlier thesis [3] gave appropriate parameter values for the Aurora con-trollers. These were based on the fact that the simulated velocity was measured at the position of the dampers. To be able to use the same values and perhaps compare results the velocities must be measured at the same place. Placement of the accelerometers is also a reason for the recalculation. With this option the ac-celerometers can be moved around without having to change controller parameters that depend on were the sensors are placed.
The calculations are based on the equation (2.2) from [1] ~
VB= ~VA+ ~ω × ~rB/A (2.2)
The accelerometers only measure acceleration in one axis. An approximation is made were the velocities in the two axis not measured and rotation around the Z axis according to Figure2.24are neglected. (2.2) can be rewritten as
V bx V by V bz = ? ? V az + ωx ωy 0 × RB/A_x RB/A_y RB/A_z (2.3) (2.3) expands to V bx−? V by−? V bz−V az = ωy·RB/A_z −ωx·RB/A_z ωx·RB/A_y−ωy·RB/A_x (2.4)
The first two rows in (2.4) are neglected and the last row gives an expression for determining angular velocities from the integrated accelerometer signals. If this
Figure 2.24: Axis definition in the vehicle
expression is used to describe the velocity relation between the two rear corners and the rear left and front left corner, the following two equations gives the angular velocities. ωx= Vc−Va+ ωy·RC/A_x RC/A_y (2.5) ωy= Vb−Va+ ωx·RB/A_y −RB/A_x (2.6) If the rear sensors are both placed on the x-axis the distance RB/A_y = 0. ωy is then easily calculated with (2.6), and the result can be used in (2.5). This is the case for the tests done in this project. The equations implemented in the recalculation subsystem are (2.5) and (2.7) a simplified version of (2.6) .
ωy=
Vb−Va −RB/A_x
(2.7) If the sensors are not placed on the same axis (2.8) which can be derived from combining (2.5) with (2.6) must be used instead of (2.7).
ωy=
(Va−Vb) · RC/A_y+ (Vc−Va) · RB/A_y RB/A_x·RC/A_y−RC/A_x·RB/A_y
(2.8) To validate the calculation of the angular pitch velocity based on accelerometer readings a comparison with measured values from the gyro is done. This is shown in Figure 2.25. Comparing roll velocity also gives the same good result. The comparison is based on recorded data from the reference-track at 20 Km/h. Note! If the validation would be based on data from the track with exaggerated bumps the result would not be so good,3.1.4gives an explanation to this.
After the two angular velocities have been calculated they are used with the third row of (2.4) the vertical velocity of any point in the vehicle body can be cal-culated. Va is the velocity of the base point from which all distances are measured and Vb can be replaced by the velocity that needs to be calculated.
2.5 Damper Control Software. 37 80 85 90 95 100 105 110 115 120 −0.3 −0.2 −0.1 0 0.1 0.2 0.3
Calculated pitch velocity compared to meassured
Time [s]
Angular pitch velocity
Calculated Measured
Figure 2.25: Pitch velocity comparison
There are two recalculation blocks. One of them, shown in Figure 2.27 is connected to the measured gyro signals and thus do not need to calculate the angular velocities. After these blocks a switch is used to select which signal the controllers should use as input. Accelerometer- or gyro-based.
Name Unit Data Type Scale CCP
Input: vcomp [m/s] Int16 2−10 disp
Gyrof ilt [rad/s] Int16 2−15 disp
Output: vdamp [m/s] Int16 2−10 disp
W toVdamp [m/s] Int16 2−10 disp
Parameters: sensor_pos [m] Int16 2−10
-damper_pos [m] Int16 2−10
-acc_or_gyro [logic] Uint8 2−0 cal
2 Wxy_calc 1 V_damp Base_point set_sensor_pos_const Base_point set_damper_pos_const sensor_pos_const sensor_pos_const_Read sensor_pos_const sensor_pos_const damp_pos_const damp_pos_const Va Vb Rb/a_x Wy_calc Wy Vc Va Rc/a_x Rc/a_y Wy_calc Wx_calc Wx V_in Wxy V_damp V_damp_calc Terminator3 Terminator2 Terminator1 Terminator OutPort1 OutPort Mux Mux5 Mux Mux4 Mux Mux3 Mux Mux2 Mux Mux1 Mux Mux Multiport Switch InPort1 InPort Demux Demux5 Demux Demux4 Demux Demux3 Demux Demux2 Demux Demux1 Demux Demux 0 Constant2 2 Base_point 1 V_in
Figure 2.26: Velocity to damper velocity calculation code block
1 V_damp V_in Wx Wy Rx Ry V_out Subsystem3 V_in Wx Wy Rx Ry V_out Subsystem2 V_in Wx Wy Rx Ry V_out Subsystem1 V_in Wx Wy Rx Ry V_out Subsystem OutPort1 Mux Mux5 InPort3 InPort2 Demux Demux7 Demux Demux6 damp_pos_const
Data Store Read1 2 Wxy
1 V_in
