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!
Installation:
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.
Operation:
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
(UDP_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
|
