When creating a vehicle, one of the first things you need to establish is the origins and coordinate systems. This is the seed from which the rest of the vehicle grows from and it’s always best to know which direction is up.
Further complications can arise when you’ve got multiple coordinate systems for subsystems used within a vehicle. It is important to know how they are orientated relative to your vehicle system or you may start having engines upside down or transmissions back to front.
Definitions of origin and coordinate system
Origins
What is an origin? The origin is the location at which x, y and z are all zero ({0,0,0}).
But where is the origin? Annoyingly the origin can be anywhere. It is an “arbitrary” point agreed by the designers/engineers. Arbitrary only because the same vehicle can be created from any origin and in any coordinate system.
The examples in the VeSyMA libraries have the origin at the mid point between the front 2 wheel centres as shown below:
Figure 1: VeSyMA vehicle origin and coordinate system highlighted in yellow
But this will most likely differ from any data coming from a different source. Origins can be anywhere, inside, outside, above or below the vehicle.
Coordinate Systems
Once you know the origin, it’s then time to think about the coordinate system. Again, this is usually decided by the designers/engineers that are providing the data.
The coordinate system is orientation in terms of x, y and z relative to the vehicle, as in which axis goes in which direction; normally defined as {x, y, z} in terms of the directions of the vehicle.
For example ISO uses {Forwards, Leftwards, Upwards} as shown above, whereas SAE uses {Forwards, Rightwards, Downwards} and there are lots more variations than those two.
In the VeSyMA vehicle templates, there is the vehicleXYZ block in the top left hand corner of the diagram layer that defines the coordinate system. As shown below, this allows users to define the orientation of the vehicle.
Figure 2: vehicleXYZ in a vehicle model
Using origins and coordinate systems
Now the origin and coordinate system is defined, the vehicle can be built. But unfortunately there is normally more to consider before simulating vehicles.
Using multiple origins and coordinate systems together
It is rare that every part of the vehicle is relative to the same origin and in the same coordinate system. And you’ll likely need to at the very least move one subsystem to work in another.
For example, it is common that the engine is designed from a local origin and along the x axis. This means that the origin and coordinate system needs to be translated and probably rotated to get the sub-systems into the correct location.
This normally means that you’ll need to define the origin of one in the other and then know how to rotate one coordinate system to match the other. Continuing the example, in VeSyMA you’d need to know the position of the engine origin relative to and resolved in the suspensions/vehicle origin and coordinate system.
In VeSyMA this can be done using the Coordinates Blocks and connectors that are outlined in this blog post about multibody orientation.
Position of Sensors and Measurement
It is always worth considering sensors, measurement and how the orientation and position of the sensors can greatly affect your results.
If you place the sensors of a vehicle at the origin, then that may produce surprising results when looking at what they measure. Consider having an extreme origin 2 car lengths behind the rear axle; when turning to the left the sensor would start moving to the right. This would cause the measured lateral acceleration not to represent the expected lateral acceleration of the vehicle.
When looking at the data within the controlBus then you’ll see that most of the variables are described by the direction rather than the axis. For example, chassisBus.longitudinalVelocity rather than v_x as this removes confusion in regards to axis, and sign convention.
Drivers
This is also very important when considering closed loop driver models. In the VeSyMA library they are expecting to have measurements relative to the VeSyMA origin. This means that if the driver has stopped “above” a chosen line across the road then the front wheels are on that line.
The example below demonstrates this where on the right the driver is 2m further forward than where it thinks it is, so stops short of the line.
Figure 3: Right and Wrong Driver Origin.
This problem is made worse when considering a lateral control. If a driver model thinks it’s 2m further forward than it is, then it will turn in sooner and cut the corner. But worse than that because the driver is further forward, the lateral change from small steering inputs will be greatly exaggerated. This will cause the driver to do very odd things and probably be very unstable.
Initialisation and interacting with the world
Using the vehicleXYZ, as mentioned above, is imperative to ensuring that the vehicle interacts with the world correctly. You need to specify the orientations or the vehicle and road may be in incorrect orientations.
The vehicle orientation is local to the vehicle, but the world uses ISO {Forwards, Leftwards, Upwards}. This means that looking at chassisFrame.r_0, which is the world position, is also in ISO.
Conclusions
Like them or not origins and coordinate systems are a pivotal part of creating any system, including vehicles. Annoyingly there is no “correct” way that everyone uses. But you NEED to know them before you even start to put your vehicle together or it’s going to make it very difficult and probably lead to incorrect results.
I always recommend using animation to your advantage. Getting origins and especially orientations wrong can be more obvious in an animation than looking at data.
Written by: David Briant – Project Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion
