Polygon

Polygon is a platform for tests involving moving objects. It was made especially for vehicle dynamic testing and advanced driver assistance systems - ADAS, which increases safety in the traffic. Polygon provides a visual representation of measurements in the three-dimensional virtual space and easy tools for geometric measurements between multiple static or movable objects. Due to it's flexibility it's not only used in Automotive, but also Marine, Heavy machinery, ...

Polygon is a platform for tests involving moving objects. It was made especially for vehicle dynamic testing and advanced driver assistance systems - ADAS, which increases safety in the traffic. Polygon provides a visual representation of measurements in the three-dimensional virtual space. It also provides easy tools for geometric measurements between multiple static or movable objects. Polygon visualization and outputs can be calculated during the measurements or after in offline mode. Due to it's flexibility it's not only used in Automotive, but also Marine, Heavy machinery, ...

Polygon works as a Dewesoft X plugin. To install it, please copy Polygon.dll to the Addons folder of Dewesoft X Software. When this is done open the Dewesoft X software, go to Settings/Extensions and click on the plus button. This will open an extension manager. The Polygon plugin should appear in the extension manager list, where you have to enable it to make it work. If the plugin is successfully enabled it will appear in the extension list. If you don’t find the plugin in the extension manager click refresh the list in the extension settings.

Extension settings, no plugins installed. After clicking the plus button extension manager appears

Now you can use the polygon plugin inside Dewesoft X

Polygon plugin is now enabled in Dewesoft X

Optional plugin: Vehicle Simulation

If you want to test Polygon setups before use or want to learn how to use the Polygon plugin offline there is an additional Vehicle Simulation plugin available (VehicleSimulation.dll library). Installation process is the same as with the Polygon plugin. Vehicle simulation plugin automatically adds longitude, latitude and heading channels that can be used to move vehicles in the Polygon environment. The added channels can be controlled with keyboard arrows or with joystick movement. 

Polygon and VehicleSimulation plugins enabled

Polygon setup view

Under channel setup click on the Polygon button in the main toolbar. Polygon setup contains four sections. On the left top is the object list with all of the objects (vehicles, cones, gates, lines…) needed for measurement and their basic properties like name, color, show/hide option. Under that is the object property section with detailed properties for selected object. Some properties like moving characteristics are similar for all objects and others are object type dependent, like dimensions for vehicle, position for cones, width for lines and routes. On the bottom left is the output list, where all the polygon outputs like distances, angles, gate cross triggers… can be defined. Outputs automatically become new data channels. On the right side of the display there is a polygon 3D preview with view angle settings.

To see the polygon on the measure screen just put Polygon3D component on it and connect it to the Polygon visual group. If there is just one visual group suitable for Polygon3D visual component then it will be automatically assigned.

Polygon offers six different types of objects. Each of them has specific properties, behavior and calculation options:

  • Vehicle,
  • Simple object,
  • Line,
  • Route,
  • Circle,
  • Travel radius.

Object table

Settings which define how object moves are common for all objects. It’s normal for a vehicle to move and for route to be fixed, but there can be exceptions so any object can be fixed or moving. There are actually three options. Object can be Moving, Fixed or Moving with. Fixed object is fixed to the ground and X and Y are relative positions regarding to the origin (they represent the coordinates in the fixed coordinate system). Moving objects needs Latitude, Longitude and Heading channels to be assigned to them. In this case X and Y coordinates define shift from the Latitude, Longitude and Heading value (they represent coordinates in the moving coordinate system). Third option “Moving with” is similar to Moving, but here some other moving object is set as reference instead of Latitude, Longitude and Heading channel.

When the value of a trigger channel reaches the specified condition the object will stay on its place and further changes of Latitude, Longitude and Heading from the master object won’t change its position. If object moves with another object it will also freeze when master object freezes.

Vehicle

Vehicle is usually the first object we need. It’s normally a moving object, with Latitude, Longitude and Heading channels from GPS, DS-IMU, ADMA or some other device. Length and Width should also be defined if we want to calculate distances from the edges of the vehicle. There are also X and Y coordinates which represent the shift of the vehicle center from the point given by Latitude and Longitude (usually GPS antenna position). If the antenna is at the back then X should be positive (vehicle shifted forward), if it is on the left Y should be positive (vehicle shifted right).

Vehicle property settings


Specifying offsets from GNSS antenna to vehicle center

Settings for vehicle size can be moved out of the setup and out of the setup file. This can be used in cases when the same setup is used with different vehicles or when those settings should be set in Data header (on start when Sequencer opens it for example). If there is entry with Unique ID VehicleLength and VehicleWidth in Data header then it will be fixed to those two values and disabled in setup (will be still shown, but disabled).

Simple object

Simple object is a single point in the polygon, visually represented with a traffic cone. It’s normally fixed object, but can also be moving. If it is fixed then X and Y determine position on fixed coordinate system, if it is moving then X and Y determine its position in the moving coordinate system. So the Simple object can be cone in Lane change test, microphone in Pass-by noise test, but it can also represent any custom interest point inside or outside of the vehicle (or other moving object), which we can use to calculate distances to.

Simple object definition


Line

Line is defined with two points. It’s also normally fixed object, but can also be moving. The order of points is important, line direction is defined as a direction from first to the second point. Depending in the side on which the measured object lays the calculated distance is either positive or negative. If it is on the right then distance will be positive and if it is on the left then it will be negative.
The width is also important. Not just for visualization, but also for distance calculation if the distance from the edge is calculated. Line can for example represent the straight lane in Lane departure test or Lane change test, but it also has one additional function. It can also act as a crossing trigger (more about that in output section).

Route

Route is predefined path (track, road...). It can be made out of lines and curves. It can be imported from file or defined manually. If we define it manually we have four elements we can use:

  • Straight – straight line in meters. The direction of straight is the direction in which previous element ends.
  • Curve – curve with constant radius in meters and specified arc angle. It starts where previous element ends and goes right if the arc angle is positive or left if its negative.
  • Line to – straight line from point where previous element ends to point (X, Y)
  • Curve to  – a curve with constant radius from point where previous element ends to point (X, Y), the radius is automatically defined with the direction of the previous element ending.

We can see a simple route defined with all the possible elements found in settings. Route starts (where the car is) with a 40 meter straight in the x direction. Straight is followed by a corner with 10 meter radius and 180 degree arc angle in the left. The next straight is defined with ending coordinates. The final corner is defined with the end coordinates, we can see from coordinates that it has a radius of 10 meters and has an arc angle of 180 degrees.

Route visualization (vehicle is positioned on the start)

Complex routes are normally imported. We can record a route with Dewesoft X software, export it to the GoogleEarth .kml format and import it in Polygon. Imported routes can be additionally modified. If we don’t have an origin defined before the route import will set it automatically to the route start. Origin direction (x coordinate) is going to be the same as the start direction of the route.

Import from kml format, imported route in the background

Defined route used for different calculations. Distance from center or edge of the route to the vehicle for example, distance from route start, heading deviation of the vehicle compared to the route. Route position can be either fixed or moving.

Routes are defined by the central path and have a constant width that can be changed in the polygon. If the actual track has large variations in the width we can import each edge of the track as a route on it own.

Circle

A full circle that is defined with center, radius and line width. It can be assigned as fixed or as a moving object. It always forms a full circle (if just one part of the circle is needed a route curve should be used instead).

Circle setup

Circle can for example represent a circular lane. The calculated distance between an object and a circle is positive if the object is outside of the circle and negative if it is inside of the circle. The calculated distance is the shortest distance from a circular lane to the object.

If an angle between the circle and the vehicle heading is calculated it represents vehicle’s heading deviation from a circle. If it is zero vehicle heading is the same as a circular lane direction, it is positive if the vehicle points outward of the circle and negative if vehicle heading points inward

Travel radius

Travel radius shows predicted path of the vehicle if steering wheel stays in the same position and all other conditions don't change. It can only be set as »Moving with« the only applicable reference object is a vehicle. Travel radius is calculated from vehicle path in the specified time-frame. The time-frame can be specified from 0.5 to 5 seconds. Travel radius can only be set up with the "Moving with" setting, the master object has to be a vehicle.

The real power of travel radius is shown when it gets frozen on some point. Then the deviations of the real vehicle travel compared to the predicted one can be calculated.

It is used for example in FuSi (Functional safety) tests where first steady drive is performed to get the predicted path (in that stage the travel radius gets frozen) then an error is injected into the vehicle control system and the result of that error can be then measured with distance and angle deviation.

It can also be used in Brake tests to measure lateral deviations from ideal braking line or braking curve if test is performed in curve.

Width is important when we calculate distances to the edges of the travel radius. It is also used for visualization. Calculated distance between an object and travel radius (circle formed by travel radius) is positive if object lays outside of the travel radius and negative if it lays inside of the travel radius. If an angle between the travel radius and the vehicle is calculated it represents vehicle’s heading deviation from the travel radius. If it is positive vehicle's heading points outward of the travel radius and negative if vehicle's heading points inward.

Vehicle with visualized travel radius

Coordinate systems

Fixed and moving coordinate systems

The environment has one fixed coordinate system that is defined in the environment origin.
The position of each static object is defined in the fixed coordinate system. Each independent moving object has its own local coordinate system that is moving with the object. If object motion is dependent on another moving object (“Moving with” setting) the dependent object’s position is defined in the local coordinate system of the independent moving object.

Units in polygon are meters for lengths and degrees for angles. Longitude, latitude and heading are also in degrees.

Origin

Origin settings

This settings define the origin (zero point) and orientation of the fixed coordinate system. Fixed objects in the polygon environment are defined in the fixed coordinate system, their position changes if we redefine the origin. Origin can be defined in two ways, with GNSS position and heading or with two GNSS positions (from one antenna). The first way is fast but not that accurate, the second one consumes a bit more time but the accuracy is far greater.

SETUP WITH CURRENT POSITION AND HEADING

GNSS position and heading is needed for this set up. The GNSS data has to define a movement of a polygon vehicle. In the origin setup we use this vehicle object to set the origin from objects current position and heading. Fixed coordinate system positions and aligns itself according to the object's GNSS coordinates become a zero point of the fixed coordinate system, X direction of the fixed coordinate system aligns itself wit the GNSS heading at the moment of clicking.

 

SETUP WITH TWO POINTS

GNSS position from one movable antenna is needed, data has to be connected to a vehicle type object in the polygon environment. For the origin definition two reference points on the test area have to be chosen. Reference points should be as far apart as it is feasible on the test site. This reference points have to be added on the modeled test track in polygon as simple objects (you can also choose existing cones as reference points). Vehicle object with GNSS data connected to it has to be chosen as the object with which the origin is going to be set. To set the point 1 we move the GNSS antenna on the position of the first reference point on our test area and press the button 'Set point 1'. The same has to be done to set up the point 2.

 

ORIGIN SETUP WITH IMPORTED ROUTE

Origin can also be set with a route imported in the polygon environment. If prior to import origin hasn't been set the route import will automatically set it. The origin zero point is going to be located in the route start point with the origin direction (X axis of fixed coordinate system) pointed in the route start direction. Origin position can always be reset and redefined.

Origin has to be defined accurately to ensure that objects positions in the polygon environment corresponds to the position on the real world test track. Two mistakes can be made during origin setup: wrong definition of origin zero point or wrong definition of origin orientation.

Wrong definition of origin zero point can happen when we position the GNSS antenna is in the wrong position on the test track that doesn't match the position of our modeled environment. Errors from this mistake are constant throughout the test area (constant offsets between objects on the real test site and objects modeled in polygon). This errors can be noticed with comparison of GNSS antenna position on the real test track compared to the position of it (object connected to it) in the polygon environment.

Error in origin orientation is made when GNSS heading isn't aligned with the X axis orientation of the real test site (origin set up with current position and heading), or with positioning error in the two point definition. Positional errors increase with the distance from the origin, small errors in orientation definition can produce large positional errors away from the origin. Therefore it is recommended to use two point origin definition when positional accuracy of the test area is needed (examples: slalom, lane change, pass-by noise).

Positional error in Y direction caused by heading error.

Polygon outputs are defined in the output table each specified output becomes a new data channel in the measurement.

Output table where all polygon outputs are specified

Each output is defined by:

  • Output type (distance, angle, cross trigger…),
  • Two objects (fixed or moving) and object interests points (center of the car, edge of the route,...),
  • Sign definition (regular, absolute or opposite).

The order of objects is important.  General rule is that the first object defines the coordinate system in which the result is calculated . For example if Distance X from vehicle A to vehicle B is calculated then the result will be in vehicle A coordinate system if vehicle A is first object and in vehicle B coordinate system if vehicle B is the first object.

There are also some rules where one object has to be always first. If distance from line, route, circle or travel radius to vehicle is calculated the vehicle should always be a second object. Again the result will be calculated according to first object and its interest. If we calculate the distance from an edge the result will be zero if the other object in the measurement is on the edge, positive if it’s inside the lane and negative if it’s outside. If we are interested in the distance from the center (for example route center) then the general rule is that objects position on the right gives positive distance and left gives negative distance. But there is also another rule for circular objects (circle and travel radius when it is not straight). If an object is outside of the circle the distance is positive, if it is inside the calculated distance is negative. There are similar rules for angles. In general clockwise is positive, but with circular objects pointing outwards is positive and pointing inwards is negative.

All this rules maybe look confusing but they have sense in practice. Theoretically the distance should always be positive, but in real word measurements it is good to know if the car is on the left or right side of the road, in or out the lane …

Not all combinations of object types and calculations are supported. If calculation is not supported then a red message “Not supported” will appear in the value column of the output table.

Output measurement references

Each object has its references (points or lines) that are used for output distance and angle calculations. All available options are shown in dropdown table when object is already selected and you click on the interest property in the table. Vehicle for example has few for distance and gate crossing trigger (center, all four edges, front and rear bumper) and one for angle (heading). Simple object which represents a single point has just center for Distance calculations. Line, route, circle and travel radius which can represent lanes in different shapes have center and edge for Distance calculations and direction for angle.


Route has also interest point called start, which can be used to calculate position of the vehicle on the route (measured on center over the length of the route – see picture).

Distance along route visualization

Custom references

If an interest point which is not predefined needs to be measured we can simply define it with an addition of a reference object that is moving with the object of interest. For example if we want to add a measurement point to a vehicle we should create a new simple object that moves with a vehicle. Then we calculate the distances from the moving simple object to the object of interest.

Output table, output type buttons

There are seven types of outputs (distance, distance X, distance Y, angle and gate cross trigger). Each has its own add button in the output table.

  • Distance gives a distance between two objects. They can both be moving or one can be fixed. All types of objects are supported for distance calculation, but there are few rules which were already explained about which object should be first, meaning of positive negative result and so on.
  • X and Y distance calculate longitudinal and lateral distance looking from the first object. They can be calculated between vehicles and simple objects (fixed or moving). If X and Y position of some object on the fixed coordinate system is required then first put a simple object in center (fixed object at position x=0, y=0) and then calculate X and Y distance from that center object to the moving object.
  •  Angle calculates heading deviation between two objects. It can be calculated between two vehicles or Line, Route, Circle or Travel radius and Vehicle (vehicle should always be second object). Like already mentioned in general clockwise is positive, but with circular objects heading vector pointing outwards is positive and inwards is negative.
  • Gate cross trigger changes its value from zero to one and back to zero again when moving object crosses the line. First object must always be a line (representing the gate) and the second object must be a vehicle or a simple object (custom interest point).
  • Time outputs relative time from previous time reset in seconds and resets the timer. One of the objects in the measurement has to be a line. Output is changed when the other specified object (vehicle, simple object…) crosses the line center. One line with time setting can be used to record lap times on a looped track.
  • Time reset resets the relative timer and outputs the absolute time from the start of measurement in seconds. One of the objects in the measurement has to be a line. Output is changed when the other specified object (vehicle, simple object…) crosses the line center. Normally this setting is used on start lines of non-looped tracks (acceleration runs, brake tests…).
  • Radius outputs the specified travel radius value in meters. It uses only the specified travel radius for the object of measurement. It can be set to output either radius or inverse radius. Inverse radius is used when we want to avoid the large values of radius when the moving object path comes close to a straight line.

Visual settings are the same in setup and measure module but they don’t influence each other. Visualization settings do not influence the measurement.

Camera position

  • Manual means that view angle can be adjusted to any position manually. It can be translated with right mouse button, rotated with left mouse button and zoomed in and out with mouse wheel or pressing both mouse buttons and moving the mouse up and down.
  • Attach to car view can also be set with mouse (move, rotate, zoom). Similar to manual but with one big difference that camera will move with the vehicle (first vehicle on the list if there are more than one). Camera will move with the vehicle but will not rotate with it.
  • Follow car view can also be set with mouse (move up and down and zoom). In this case the view will follow the car and also rotate with the car. By default the camera will be at the back of the car following it like in driving simulation games. It’s suitable for driving assistance when following virtual routes.


Vehicle presentation

Vehicle can be visualized with a 3D model (Vehicle) or as an exact size rectangle on the ground (Exact sized box).

Visualization in the measurement module

Polygon can be used to measure lateral and heading deviations on braking. Braking lane has to be defined (polygon line or route). If tests are repeated on the same test lane braking lane should be fixed. If we are testing in an open area without the real brake lane defined we can choose a moving brake lane that is set up to freezes on trigger (brake pedal actuation, threshold deceleration…). For brake tests in a curve a travel radius which freezes on trigger can be used.

Polygon setup

View in measurement module 

Brake test polygon setup consists of two objects, vehicle and it's travel radius. Travel radius is set to freeze on trigger. Event count of brake test math is used for lane freeze. When brake test starts its Event count goes to 2, travel radius freezes. Two polygon outputs calculate lateral deviation (distance from lane center to vehicle center) and heading deviation (angle between lane direction and vehicle heading).

We need two objects for lane departure test, lane and vehicle. Lane can be simple line, circle or more complex route (like this S in the example). Lane will be fixed object placed to the ground with origin set. When this is done few outputs need to be defined. Distances from route center to vehicle center, route edges to car outer corner points, vehicle heading deviation from route. 

The XY recorder on the screen shows the distances from route edges to vehicle corner edges over the route distance. 

There are two 3D polygon visual components on the same measurement screen with different viewing angles. 

If an actual lane doesn’t have a constant width two routes should be used, one on the outer and one on the inner edge. 

Lane change test consists of three lanes: enter, leave and shifted lane. They can be represented with lines precisely positioned in the polygon. In reality cones would be placed on the test surface to mark lanes, but they do not need to be implemented in polygon. Lane edges can do their job.

For average speed calculation we also need start and finish gate. In polygon terminology this would be two lines and two Gate Cross outputs, which can then be used as start and stop trigger in statistics to calculate average speed. Calculation can also be triggered with car X and Y position.

Lane change polygon setup

Measurement view

Polygon plugin can now provide exact position of the car during the Lane change test. Distances from shifted lane edges to car edges are calculated. This distances can be used to evaluate if the test was done properly, or if it can be done faster, more precise and closer to the cones.

There are many types of functional safety (FuSi) tests. Straight line and steady state cornering tests are simpler, but there are also tests with more complex predefined maneuvers like Dog-track test. For straight line and steady state cornering tests we just need a vehicle and its travel radius. Travel radius will represent the predicted vehicle path in normal conditions (without error injected). Due to the steady nature of simpler tests the predicted path from the travel radius is going to be fairly accurate. At the moment when an error is injected in the car electronic control system the predicted vehicle path (travel radius) is frozen. Vehicle lateral and angle deviations are than calculated using the frozen travel radius as a reference.

If a predefined maneuver has to be driven before error is injected the route of the maneuver can be predefined (manual route creation, route recording and import). Route can be either positioned fixed on the polygon (in setup) or moving with a vehicle with a freeze on trigger function. Freeze can be triggered with a button, speed threshold… The polygon view can from then on be used as driver assistance. From here on the procedures and analysis is the same as with the simpler tests.

FuSi setup, route with a predefined maneuver that freezes when vehicle's velocity goes over 50 km/h.

Measurement view

This website uses cookies to ensure you get the best experience on our website. Learn more