Active Suspension: Kinematics and Control Part 2

The previous article in this series detailed the principles behind our suspension modelling and the way in which we will go about designing the system. The development of the system is intended to be a two-year project, with much of the preliminary work done this year before a system is designed from the outset for competition in 2017.

Over the last few months, in parallel with the design of a passive system for 2016 competition, we have built up the model. This has helped us to validate the design and validate the model simultaneously; this year’s geometry is a comprehensive set of coordinates that can be used for testing.

The development of the model has presented some interesting challenges, and one in particular is how to actually define the motion of the suspension. There are many linkages which all need to move synchronously and as a result the motion is nonlinear, with components of rotation, translation, and occasionally twist in the parts.

We also have a very cool way of integrating the system with our CAD work to streamline the design process.

We can see an output of how the system looks as it moves.
We can see an output of how the system looks as it moves.

Dynamic Suspension Model

The custom dynamic model has been developed and refined to represent the movement of the suspension. Understanding the way that the suspension linkages move in tandem is key to controlling this movement. In particular, the motion of the push/pull rod in response to vertical suspension travel needs to be known.

The sensors for the suspension will be mounted on the pull rod or rocker. If we are to properly control the vertical position of the wheel, we need to know how the vertical position is related to the push/pull rod travel. We also need to know how to work the system in reverse, so that the actuator can be positioned or forced as required.

The dynamic model is the first step towards a full implementation of a kinematic model, which we can use to specify the forces required in the actuator. There are two main ways in which a system can be developed, and each has its own benefits. We are using a bespoke model programmed in C#, which will allow event based and functional programming as required.

Vector Model

The first option for implementing a model to investigate how the suspension travels is to define the position of a single point, and solve all of the contact constraints in the system as this point moves. Since we are interested in the motion as the suspension travels up and down, it makes sense to move the contact patch in the first instance.

All of the points in the car are defined using XYZ coordinates, which means it is trivial to generate and manipulate vectors in the suspension. If the vectors defining all of the points are used correctly, it is possible to calculate centres of rotation and motion paths.

The contact patch is rigidly fixed to the upright, so the motion conducted by the contact patch will match the motion of the upright. The most common way of implementing this motion constraint is to rotate all parts by a very small angle around the same axis. It can be shown that this maintains the shape and internal dimensions of the system.

The axis of rotation is determined as the axis normal to the forced direction of motion of two components. For a double wishbone setup, the axis of rotation is equivalent to the instant centre of rotation in the system.

Once the upright has been moved in this way, we need to find the new position of the steering, pull rod, rocker, and spring. These are all implemented in a similar way. The constraints are the fixed link lengths of the steering arm and pull rod, and their corresponding fixed ends. Once the position of the upright axis is defined, the steering arm upright end can only move on a circular path around the upright. It can also only move on a sphere, centred at the end of the steering rack.

Resolving these two constraints gives only two points in space that the upright pickup can be located. We find the location of the point which is closest to its previous location, representing a smooth motion, and then rotate the upright around its axis until the steering pickup point meets the required location.

Code used to find the location of the steering pickup on the upright. It finds the intersection of a sphere and a circle.
Code used to find the location of the steering pickup on the upright. It finds the intersection of a sphere and a circle.

The pull rod is similar – the rocker pickup point can only move on a sphere centred at its pickup point on the lower wishbone, and a circle around the centre of the rocker mounting on the chassis. Between these two points, we can find the location that it must have moved to, and rotate the rocker until the points match. Once rocker rotation is known, the spring length can be calculated, and the position of any active actuator can be determined.

Once all of these relations are defined, it is comparatively easy to run a sweep from the contact patch end and find the positions of the actuator, but just as easy to run the sweep in reverse, as we require.

If the system is event based, so that any change to a coordinate forces update of all of the other relevant systems, it becomes very easy to implement steering, bumps, and move towards a kinematic model which evaluates suspension travel in response to forces.

Equation Driven Model

The second method is to encode all of the above constraints, on fixed positions and link lengths, into a single function which defines the way that each point responds to motion of another. This equation is re-evaluated for each point every time the system is moved.

The motion of all of the points on the upright is governed by the intersection of their possible motion paths, as before. However, rather than solving all of the constraints as the parts move, and adjusting the positions accordingly, the equations handle the positioning, which makes each individual move more computationally efficient.

It is also trivial to adapt the equations to deal with forces if necessary, because the geometry and travel is already in place. This may simplify later stages of the calculations and programming.

More in-depth studies could be conducted, or more iterations run in each sweep, to reduce the accumulation of positional errors. However, it is not possible to reverse this method as easily as the vector method. It is a trade-off based on what we expect the system to do, and the resources that will be available to complete the tasks.

SUFST Suspension Model

I chose to implement a vector-type method in the SUFST suspension model. This means it can cover all forms of steering sweep, suspension travel, and active suspension modelling if necessary. The kinematic analysis will have to be handled separately and at a later time.

This is not to say that the equation driven model is inherently worse, because it is very effective for certain scenarios. The choice for our model is based on the most effective system for our particular situation and design brief.

The reference points used on the front corner of the suspension wireframe model.
The reference points used on the front corner of the suspension wireframe model.

CAD Integration

One of the neatest parts of this model is the integration of the suspension geometry with

our SolidWorks models. In a couple of clicks, we can export the coordinates of the suspension geometry from our CAD wireframe model and import them into the suspension model. We can sample a design iteration in around a minute, allowing us to run through multiple design changes very quickly if necessary. For optimising things like the Ackermann steering, rocker motion ratios, and dynamic camber change – all of which can be assessed through the suspension model – this is a very valuable tool.

It is done through the use of VBA macros in the SolidWorks program, and the location of reference points on the critical suspension nodes in the sketch. The macro scans for a specified reference points in the suspension setup, and measures their location relative to the origin to get the XYZ position. This is written to a csv file, along with an identifier for the point.

The coordinates can be exported on separate lines

Or they can have additional information specified, with the XYZ coordinates tabulated.
Or they can have additional information specified, with the XYZ coordinates tabulated.

The coordinates can be exported on separate lines

 

 

 

The C# program can read these csv files and load the coordinates directly into its model, overwriting any coordinates it had stored but maintaining other system parameters and settings. Since no calculations are performed in the system until we specifically move a part, there is no need to regenerate equations at this point – configurations can be freely swapped to investigate the effects of each.

The macro has been written in such a way that the output of the file can be modified very easily. We can set the coordinates to be output in just about any format, which means they can be imported directly into any program – Adams, other proprietary systems, our own system, Microsoft Excel, etc. – as and when we need them. The use of simple macros in this way has massively streamlined our design process and will prove useful for future years designs too.

Further Development

The next steps will focus on implementing an actuator into the system, and quantifying the relationship between actuator position and wheel travel. This is likely to be non-trivial due to a variable motion ratio as the rocker rotates.

Load transfer through the system will also be investigated to see how the actuators affect load transfer and peak load on components.

We are also in the build phase of the 2016 passive system – parts have been sent to manufacture ready for assembly at the same time as the chassis – and updates on that will follow soon.

Active Suspension: Kinematics and Control Part 2

Leave a comment