BFF Motion Driver v3 - Short User Guide

Previous    Contents     Next


14. The "Generic" Motion Driver

The "Generic" BFF 6DOF motion driver is a version which is not tied to any specific flight or racing sim, but is instead driven by user supplied vehicle motion data. This data can come from any source the user wishes - UDP protocol is used to communicate the vehicle motion data to the Generic motion driver.

IMPORTANT: this is BETA software and may contain bugs - please use with care!


Download the driver zip package from the links on Section 1. Installation of the motion driver is mainly the same as the other versions - see section 2. There are no specific flight or racing sim interface steps - just download and unzip the software into a dedicated folder.


The software operation is mainly as described in Section 3 Operation.

When running the Generic Motion Driver will listen for UDP data on the Port and IP Address specified in the .bff config file. You must write your own application to send valid motion data. The data format is shown below.

WARNING - Improperly formatted vehicle motion data is very likely to produce erratic motion cue output from the driver - you must thoroughly test your UDP data "sender" application before connecting the motion driver output to a live motion platform. At the very least use the cue progress bars and the scoping facilities to check that the motion cues are as expected and well behaved before using them in a live platform.

Remember you can use the Drive and Hold hot-keys or hot-buttons which are defined in your .bff cue configuration file in addition to the GUI drive and hold buttons.

UDP Data Format:

The Generic motion driver expects vehicle motion data in 48 byte packets sent by UDP to the Port and IP Address specified in the .bff config file (parameters PortS and IPAddress).

The 48 byte packet format is:

Byte Offset Name Type Description
0 Packet Time Stamp - Seconds Float Each data packet MUST have its own time stamp - unit seconds.
This is used by the driver to identify each new packet and together with the flow of new packets is used to determine when the data is paused or interrupted.
The time stamp is also displayed on the GUI and is useful when checking the flow of data to the driver.
4 Forward Velocity - m/s Float Not used in the main motion cue algorithms, but is used for runway "effects" and is displayed on the GUI.
8 Vertical Accel - G's Float Vehicle local vertical acceleration in G's (ie m/s^2 / 9.81).
+ve upwards through vehicle roof.

if Byte 40, UDP_Mode = 1 this is Act 1 position in +/-1.0 range.

if Byte 40, UDP_Mode = 2 this is Pitch DOF position in +/-1.0 range.

12 Forward Accel - G's Float Vehicle local forward acceleration.
+ve to vehicle's front.

if Byte 40, UDP_Mode = 1 this is Act 2 position in +/-1.0 range.

if Byte 40, UDP_Mode = 2 this is Roll DOF position in +/-1.0 range.

16 Lateral Accel - G's Float Vehicle local lateral acceleration.
+ve to vehicle's right.

if Byte 40, UDP_Mode = 1 this is Act 3 position in +/-1.0 range.

if Byte 40, UDP_Mode = 2 this is Heave DOF position in +/-1.0 range.

      IMPORTANT the local vehicle acceleration vectors must represent an absolute acceleration - they must include the effect of gravitational acceleration. For example if the vehicle is upright, level and stationary the vertical acceleration would be +1G, not zero (ie to be "stationary" the vehicle is actually accelerating upwards at 1G wrt the earth's gravitational field).
This is mainly because the algorithm is interested in the force effects of the vehicle acceleration on the pilot/driver in order to calculate representative force cues; not so much on the external appearance of acceleration and speed. 
20 Pitch Angle - degs Float Vehicle pitch angle, +ve nose up

if Byte 40, UDP_Mode = 1 this is Act 4 position in +/-1.0 range.

if Byte 40, UDP_Mode = 2 this is Surge DOF position in +/-1.0 range.

24 Roll Angle - degs Float Vehicle Roll (bank) angle, +ve bank to right

if Byte 40, UDP_Mode = 1 this is Act 5 position in +/-1.0 range.

if Byte 40, UDP_Mode = 2 this is Sway DOF position in +/-1.0 range.

28 Heading - degs Float Vehicle Heading angle, 0 Deg = North, 90 Deg = East
Optional - not currently needed for cue algorithm.

if Byte 40, UDP_Mode = 1 this is Act 6 position in +/-1.0 range.

if Byte 40, UDP_Mode = 2 this is Yaw DOF position in +/-1.0 range.

32 Yaw Velocity - rad/s Float Vehicle yaw velocity, +ve yaw to the right.
36 On Ground Indicator Float = 1 on ground, = 0 in air
40 UDP Data Send Mode
UChar = 0 - Floats 8 to 28 above are Accel and Angle Data as described.
....then for Generic Driver V3.5 and later
= 1 - Floats 8 to 28 are DOF Position Data
= 2 - Floats 8 to 28 are Actuator position Data
= 3 - Send to Park

(Corrected Jan '21, values 1 & 2 were reversed previously)

IMPORTANT: if values 1 or 2 are used the float values above MUST be altered to reflect the required Actuator or DOF positions in range +/-1.0.

The UDP_Mode setting allows apps to send actuator or DOF position demand data to the Generic Driver which will bypass the internal cue development algorithms. The position data should be in the range +/-1.0 where 1.0 is full scale actuator deflection or DOF displacement as appropriate.

41 - 47 Spare bytes   For future use....

Float = 32 bit (4 byte) floating point number
UChar = 8 bit (1 byte) unsigned integer

The frequency of data packets should typically be about 50Hz for a reasonable motion cue smoothness. However the refresh rate of the motion driver processing and output can be varied using .bff configuration file parameter MD_Delay. By reducing MD_Delay the driver will process faster and will be able to pick up new data packets at higher rates.

You should experiment to obtain processing rates to suit your application. If the data packets arrive faster than the motion driver can process them it will simply drop unused packets.

The Disp_Data button on the GUI can be use to display the incoming UDP data.

The Generic motion driver will check the magnitude of the resultant horizontal linear acceleration of the vehicle, and if the vehicle is decelerating faster than 3G's it will assume a crash has occurred and send the cues to their hold/park positions. Other than this the driver makes no checks on the UDP data sent to it - your sender application must therefore fully control the flow of data sent to the motion driver. This is especially important during start-up and shut down operations of your data source, or of other situations when the integrity of the data is compromised. For example during crash situations, or user menu interactions which interrupt the normal flow of a flight or racing simulation.

Always remember the consequences of passing erratic vehicle motion data through to the motion cues when those cues are being used to drive a real motion platform - you MUST fully control the quality and flow of data.  

For full terms and conditions relating to the use of this software please see here.


Test Sender Application:

The download zip package contains a test "Sender" application which can be used to confirm UDP comms with the generic driver. The Sender application will pull position data from the x, y & z axes of the joystick specified in the Sender.cfg file and use this to set vehicle linear accelerations. It will then send them (together with other fixed data) to the generic driver using correctly formatted UDP packets. If UDP comms are active the data will appear at the motion driver....

The port and IP address settings for the sender should be made in the Sender.cfg file.

This is intended for checking UDP comms only - DO NOT use this facility to control a real motion platform.


If you find any bugs or strange behaviours in the beta version then please let me know.


Previous    Contents     Next

Copyright 2010-21 BFF Design Ltd All Rights Reserved.