3-Space Sensor Wireless 2.4GHz User`s Manual | 3. Description of the 3-Space Sensor
3. Description of the 3-Space Sensor
3.1 Orientation Estimation
The primary purpose of the 3-Space Sensor is to estimate orientation. In order to understand how to handle this estimation and use it in a meaningful way, there are a few concepts about the sensor that should be understood. The following sections describe these concepts.
3.1.1 Component Sensors
The 3-Space Sensor estimates orientation by combining the data it gets from three types of sensors: a gyroscope, an accelerometer, and a compass. A few things you should know about each of these sensors:
Accelerometer: This sensor measures the acceleration due to gravity, as well as any other accelerations that occur. Because of this, this sensor is at its best when the 3-Space Sensor is sitting still. Most jitter seen as the orientation of the sensor changes is due to shaking causing perturbations in the accelerometer readings. To account for this, by default, when the 3-Space Sensor is being moved, the gyroscope becomes more trusted(becomes a greater part of the orientation estimate), and the accelerometer becomes less trusted.
Gyroscope: This sensor measures angular motion. It has no ability to give any absolute orientation information like the accelerometer or compass, and so is most useful for correcting the orientation during sensor motion. Its role during these times becomes vital, though, as the accelerometer readings can become unreliable during motion.
Compass: This sensor measures magnetic direction. The readings from the compass and accelerometer are used together to form the absolute component of orientation, which is used to correct any short term changes the gyroscope makes. Its readings are much more stable than those of the accelerometer, but it can be adversely affected by any ferrous metal or magnetic objects. When the accelerometer is less trusted, the compass is treated in the same way so as to avoid updates to orientation based on partial absolute information.
3.1.2 Scale, Bias, and Cross-Axis Effect
The readings taken from each component sensor are not in a readily usable form. The compass and accelerometer readings are not unit vectors, and the gyroscope readings aren't yet in radians per second. To convert them to these forms, scale and bias must be taken into account. Scale is how much larger the range of data read from the component sensor is than the range of data should be when it is converted. For example, if the compass were to give readings in the range of -500 to 500 on the x axis, but we would like it to be in the range of -1 to 1, the scale would be 500. Bias is how far the center of the data readings is from 0. If another compass read from -200 to 900 on the x axis, the bias would be
350, and the scale would be 550. The last parameter used in turning this component sensor data into usable data is cross-axis effect. This is the tendency for a little bit of data on one axis of a sensor to get mixed up with the other two.
This is an effect experienced by the accelerometer and compass. There are 6 numbers for each of these, one to indicate how much each axis is affected by each other axis. Values for these are generally in the range of 1 to 10%. These parameters are applied in the following order:
1) Bias is subtracted from each axis
2) The three axes are treated as a vector and multiplied by a matrix representing scale and cross-axis parameters
Factory calibration provides default values for these parameters for the accelerometer and compass, and users should probably never need to change these values. To determine these parameters for the gyroscope, you must calibrate it.
Read the Quick Start guide or the 3-Space Suite manual for more information on how to do this.
3.1.3 Component Sensor Data Types
Component sensor data is presented by the 3-Space Sensor in three different stages and is readily accessible via certain protocol commands.
Raw Sensor Data: This refers to data that is read directly from each of the component sensors before any additional processing has occurred. This kind of data is well-suited for users who wish to perform their own calibration routines as well as applications where precise analysis of motion is not extremely critical. Raw data commands are listed in Section 4.4.5, “Raw Data Commands” and span commands 0x40 through 0x43.
Example: In the
2G range, a raw accelerometer vector might look like (144, -25904, 744). This would indicate a force that is mostly in a downward direction.
Corrected Sensor Data: This refers to 'raw' data that has been biased and scaled to represent real-world units, using the steps as described in Section 3.1.2, “Scale, Bias and Cross-Axis Effect”. There is an additional scaling that occurs, which further alters the data reading based on each component sensor's device-specific values. This scaling provides the real-world equivalents for read data. For the accelerometer, these values are in units of g-forces, for the magnetometer, these values are in units of gauss, and for the gyroscope, these values are in units or radians/sec. This kind of data is well-suited for users who wish to accurately track the motion of objects in 3D space or measure the strength and direction of magnetic fields. Corrected data commands are listed in Section 4.4.3, “Corrected Data Commands” and span commands 0x25 through 0x28.
Example: In the
2G range, the same raw accelerometer vector from before, when corrected, might look like (.004, -.791, .023). Note that these values are in units of g, and would indicate that at the moment of the sample, the sensor is accelerating mostly downwards at a rate of 7.75 meters per second squared.
Normalized Sensor Data: This refers to 'corrected' data that has been geometrically normalized. For the accelerometer and magnetometer, all normalized sensor readings are unit-vectors and as such, have lengths of
1. For the gyroscope, these is no difference between 'corrected' and 'normalized' data. This kind of data is wellsuited for users who are only interested in the direction of acceleration or magnetic fields. Normalized data commands are listed in Section 4.4.2, “Normalized Data Commands” and span commands 0x20 through 0x23.
Example: The corrected accelerometer vector from before, when normalized, would look like (0.05,
-0.998, 0.011). Note that the magnitude information is lost, and only the direction of the acceleration remains.
3.1.4 Additional Calibration
The 3-Space Sensor provides multiple calibration modes that can improve performance at the cost of additional setup and calibration routines. For more information on setting these additional modes, please refer to command 169.
Bias Mode: Applies default range scaling to raw data readings. Also applies a bias offset to raw data, the values of which are taken from the provided calibration parameters command. (See section 4.3.7 for more information)
Bias / Scale Mode: The default calibration mode. Applies default range scaling to raw data readings. Also applies a bias offset to the raw data as well as an additional scale matrix. Uses the matrix and vector portions from the provided calibration parameters command.
Ortho-Calibration Mode: A more advanced calibration mode that requires initial setup steps (Please refer to the 3-Space Suite Quick Start Guide for information on how to supply ortho-calibration data) . Uses 24 orthogonal data points to provide accelerometer and compass correction factors for enhanced orientation accuracy.
3.1.5 Reference Vectors
In order to get an absolute estimation of orientation from the accelerometer and compass, the sensor needs a reference vector for each to compare to the data read from it. The most obvious choice for these are the standard direction of gravity(down) and the standard direction of magnetic force(north), respectively. However, the sensor does provide several different modes for determining which reference vector to use:
Single Manual: Uses 2 reference vectors it is given as the reference vectors for the accelerometer and compass.
Single Auto: When the sensor powers on or is put into this mode, it calculates gravity and north and uses those calculated vectors as the reference vectors.
Single Auto Continual: The same as Single Auto, but the calculation happens constantly. This can account for some shifts in magnetic force due to nearby objects or change of location, and also can help to cope with the instability of the accelerometer.
Multiple: Uses a set of reference vectors from which the best are picked each cycle to form a single, final reference vector. This mode has the ability to compensate for certain errors in the orientation. In this mode the sensor will have a slightly slower update rate, but will provide greater accuracy. For information on how to set up this mode, see the Quick Start guide or the 3-Space Suite manual.
3.1.6 Orientation Filtering
The 3-Space Sensor provides several different modes for providing orientation estimation. Note also that IMU data collection rate is bound to the update rate of the filter. For more information on setting these additional modes, please refer to command 123.
Kalman Filter: The default filter mode. Normalized sensor data and reference vectors are fed into the Kalman filter, which uses statistical techniques to optimally combine the data into a final orientation reading. Provides the highest-accuracy orientation at the lowest performance.
Alternating Kalman Filter: Uses the same Kalman filter as before, but skips every other update step. Slightly less accurate than the Kalman filter, but faster.
Complementary Filter: Fuses low-pass filtered accelerometer/compass data with high-pass filtered gyroscope data to provide an orientation estimate. Less accurate than any Kalman filtering techniques, but provides significantly higher performance.
Quaternion Gradient Descent Filter: Utilizes gradient descent techniques to avoid the high computational overhead of Kalman-based filters. Provides high performance and high accuracy. Does not use reference vectors or confidence/rho values, thus it sacrifices some customization for performance.
IMU Mode: Performs no orientation filtering, but allows IMU data to be read at the maximum update rate of
3.1.7 Reference Orientation/Taring
Given the results of the Kalman filter, the sensor can make a good estimation of orientation, but it will likely be offset from the actual orientation of the device by a constant angle until it has been given a reference orientation. This reference orientation tells the sensor where you would like its zero orientation to be. The sensor will always consider the zero orientation to be the orientation in which the plug is facing towards you and top(the side with buttons on it) facing up. The sensor must be given a reference orientation that represents the orientation of the sensor when it is in the position in which you consider the plug to be towards you and the buttons up. The act of giving it this reference orientation to the sensor is called taring, just as some scales have a tare button which can be pressed to tell the scale that nothing is on it and it should read zero. For instructions on doing this, refer to the Quick Start guide or 3-Space Suite manual.
3.1.8 Other Estimation Parameters
The 3-Space Sensor offers a few other parameters to filter the orientation estimate. Please note that these only affect the final orientation and not the readings of individual component sensors.
Oversampling: Oversampling causes the sensor to take extra readings from each of the component sensors and average them before using them to estimate orientation. This can reduce noise, but also causes each cycle to take longer proportional to how many extra samples are being taken.
Running Average: The final orientation estimate can be put through a running average, which will make the estimate smoother at the cost of introducing a small delay between physical motion and the sensor's estimation of that motion.
Rho Values: As mentioned earlier, by default the accelerometer and compass are trusted less than the gyros when the sensor is in motion. Rho values are the mechanism that handles the concept of trust. They involve parameters, one for the accelerometer and one for the compass, that indicate how much these component sensors are to be trusted relative to the gyroscope. A lower value for the parameter means more trust. The default mode for this is “confidence mode”, where the rho value chooses between a minimum and maximum value based on how much the sensor is moving. The other option is to have a single, static rho value.
Obtaining data about orientation from the sensor or giving values for any of its settings is done through the sensor's communication protocol. The protocol can be used through either the USB port or wireless interface, using the 3-Space
Wireless Dongle. A complete description of how to use this protocol is given in section 4 of this document. Also, you may instead use the 3-Space Suite, which provides a graphical method to do the same. To learn how to use this, read the
3-Space Suite manual.
3.2.1 Wired Streaming Mode
The default mode of communication for the 3-Space Sensor is a call and response paradigm wherein you send a command and then receive a response. The sensor also features a streaming mode where it can be instructed to periodically send back the response from a command automatically, without any further communication from the host.
To activate the streaming mode, use the following steps:
1) Set up the streaming to call the commands you want data from. First, figure out which commands you want data from. The following commands are valid for streaming:
0(0x00), Read tared orientation as quaternion
1(0x01), Read tared orientation as euler angles
2(0x02), Read tared orientation as rotation matrix
3(0x03), Read tared orientation as axis angle
4(0x04), Read tared orientation as two vector
5(0x05), Read difference quaternion
6(0x06), Read untared orientation as quaternion
7(0x07), Read untared orientation as euler angles
8(0x08), Read untared orientation as rotation matrix
9(0x09), Read untared orientation as axis angle
10(0x0a), Read untared orientation as two vector
11(0x0b), Read tared two vector in sensor frame
12(0x0c), Read untared two vector in sensor frame
32(0x20), Read all normalized component sensor data
33(0x21), Read normalized gyroscope vector
34(0x22), Read normalized accelerometer vector
35(0x23), Read normalized compass vector
37(0x25), Read all corrected component sensor data
38(0x26), Read corrected gyroscope vector
39(0x27), Read corrected accelerometer vector
40(0x28), Read corrected compass vector
41(0x29), Read corrected linear acceleration
43(0x2B) Read temperature C
44(0x2C), Read temperature F
45(0x2D), Read confidence factor
64(0x40), Read all raw component sensor data
65(0x41), Read raw gyroscope vector
66(0x42), Read raw accelerometer vector
67(0x43), Read raw compass vector
201(0xc9), Read battery voltage
202(0xca), Read battery percentage
203(0xcb), Read battery status
250(0xfa), Read button state
255(0xff), No command
There are 8 streaming slots available for use, and each one can hold one of these commands. These slots can be set using command 80(0x50), with the parameters being the 8 command bytes corresponding to each slot.
Unused slots should be filled with 0xff so that they will output nothing.
Please note: The total amount of data the 8 slots can return at once is 256 bytes. If the resulting data exceeds
this, the set streaming slots command will fail.
2) Set up the streaming interval, duration, and start delay. These parameters control the timing of the streaming session. They can be set using command 82(0x52). All times are to be given in microseconds. They control the streaming as follows:
Interval determines how often the streaming session will output data from the requested commands. For example, an interval of 1000000 will output data once a second. An interval of 0 will output data as quickly as possible. The interval will be clamped to 1000 if the user attempts to set it in the range 1 – 1000.
Duration determines how long the streaming session will run for. For example, a duration of 5000000 indicates the session should stop after 5 seconds. A duration of 4294967295 (0xFFFFFFFF) means that the session will run indefinitely until a stop streaming command is explicitly issued.
Start Delay determines how long the sensor should wait after a start command is issued to actually begin streaming. For example, a start delay 200000 means the session will start after 200 milliseconds.
3) Begin the streaming session. This can be done using command 85(0x55). Once started, the session will run until the duration has elapsed, or until the stop command, 86(0x56) has been called. Please note that only binary data is supported. While streaming sessions can be started with ascii commands, only binary data will be returned. Also note that if the sensor is sending large amounts of data the host doesn't have time to handle, this can cause buffer overflows in some communication drivers, leading to slowdowns and loss of data integrity. If the firmware detects that the buffer has overflowed, the asynchronous session will be stopped. If this occurs, this is a sure sign that either the streaming interval is set too low, the program is not working fast enough to handle the amount of data or both.
For more information on all these commands, see the Streaming Commands section in the command chart near the end of this document.
3.2.2 Wireless Streaming Mode
Wireless streaming communication is initiated in a similar manner as wired streaming, with the primary difference being that commands are sent to the 3-Space Dongle via a USB connection, where they are then forwarded to the 3-Space
Wireless Sensor. The Start Streaming command will use the same output communication interface as the received command's input interface. In other words, a command received over a USB connection will result in streaming data output over the USB connection and a command received wirelessly via the dongle will result in all streaming data output over the wireless connection to be received by the dongle.
Unlike wired streaming sessions, wireless streaming supports two separate modes. There is an automatic streaming mode that behaves similarly to wired streaming sessions, where all data that is received is output immediately. There is also a manual flush mode that stores received data in internal buffers specific to each dongle's logical ID. This can be useful for communicating with multiple sensors. This also ensures that no data is lost due to communication driver buffer overflows, since the volume of wireless traffic can be substantially higher with up to 15 different sensors. More information on Manual Streaming Mode can be found in the next section.
Please note that while the maximum wired packet size is 256, wireless streaming enforces a limit of 96 bytes per sensor.
Attempting to set streaming slots to include more return data than this will result in a failure code. Also note that the dongle itself is incapable of streaming data.
3.2.3 Wireless Streaming Manual Mode
By default, the dongle is configured to not automatically output received streamed data. This means that received streaming data must be 'released' via command 180 (Single manual flush) or 181 (Bulk manual flush). The main difference between the two is that command 180 is designed to accept a logical ID as an argument, meaning that it will only manually flush for one device. Command 181, on the other hand, will flush all data that is currently pending.
The format of data returned by command 181 is different from typical commands. Once the command has been called, data will be output in the following format (note that data in square brackets is optionally returned):
<Two-byte bitfield>[Response Header 0][Data for sensor 0] … [Response Header N][Data for sensor N]
The initial two-byte bitfield represents the sensors that have new data, where the lowest bit corresponds to sensor 0, and the next highest bit refers to sensor 14. Each time the command is called, all bits will be reset to 0, thus it is possible to read a zero-value for each byte in the bitfield if it is read at a time when no new data has been received. Note also that old data can be overwritten by new data if it is not read quickly enough.
3.3 Input Device Emulation
3.3.1 Axes and Buttons
The 3-Space Sensor has the ability to act as a joystick and/or mouse when plugged in through USB. Both of these are defined in the same way, as a collection of axes and buttons. Axes are input elements that can take on a range of values, whereas buttons can only either be on or off. On a joystick, the stick part would be represented as 2 axes, and all the physical buttons on it as buttons. The 3-Space Sensor has no physical joystick and only 2 physical buttons, so there are a number of options to use properties of the orientation data as axes and buttons. Each input device on the 3-Space
Sensor has 2 axes and 8 buttons. For more information on setting these up, see the 3-Space Suite manual. All communication for these input devices is done through the standard USB HID(Human Interface Device) protocol.
As far as a modern operating system is concerned, a joystick is any random collection of axes and buttons that isn't a mouse or keyboard. Joysticks are mostly used for games, but can also be used for simulation, robot controls, or other applications. The 3-Space Sensor, as a joystick, should appear just like any other joystick to an operating system that supports USB HID(which most do).
When acting as a mouse, the 3-Space Sensor will take control of the system's mouse cursor, meaning if the mouse portion is not properly calibrated, using it could easily leave you in a situation in which you are unable to control the mouse cursor at all. In cases like this, unplugging the 3-Space Sensor will restore the mouse to normal operation, and unless the mouse enabled setting was saved to the sensor's memory, plugging it back in should restore normal operation.
Using the default mouse settings, caution should be exercised in making sure the orientation estimate is properly calibrated before turning on the mouse. For help with this, see the Quick Start guide.
The mouse defaults to being in Absolute mode, which means that the data it gives is meant to represent a specific position on screen, rather than an offset from the last position. This can be changed to Relative mode, where the data represents an offset. In this mode, the data which would have indicated the edges of the screen in Absolute mode will now represent the mouse moving as quickly as it can in the direction of that edge of the screen. For more information, see command 251 in section 4.3.7, or the 3-Space Suite manual.
3.3.4 Wireless Joystick/Mouse
The 3-Space Dongle can be set up to receive joystick and mouse data from a 3-Space Sensor wirelessly and present this data to the computer via a USB interface. This is accomplished by supplying the logical ID of the wireless device that will act as the mouse/joystick. Commands 240 and 241 are used to enable the wireless joystick and mouse respectively.
When either of these commands are invoked, the chosen wireless sensor will immediately begin transmitting the requested HID data to the dongle. The update rate at which this information is received is determined by command 215.
Additionally, HID information may be sent synchronously or asynchronously from the wireless sensor to the dongle.
Command 217 allows the user to set the desired mode. Synchronous HID mode is the default mode, in which the dongle automatically asks for the requested data first. This mode enjoys a high rate of reliability and it is quite easy to interlace regular protocol commands with HID data transmission/reception. This mode is slower, however, than asynchronous mode, since information must both be requested and received. Asynchronous mode, on the other hand, forces the sensor to automatically send HID information without being asked to do so by the dongle. This allows for much higher update rates, at the expense of reliability due to the increased number of wireless transmissions and potential collisions. It is recommended to use this mode only if you will be using the 3-Space Sensor only as an HID joystick or mouse at the given time.
3.4 Sensor Settings
3.4.1 Committing Settings
Changes made to the 3-Space Sensor will not be saved unless they are committed. This allows you to make changes to the sensor and easily revert it to its previous state by resetting the chip. For instructions on how to commit your changes, see the Quick Start guide or 3-Space Suite manual. Any changes relating to the multiple reference vector mode are an exception to this rule, as all these changes are saved immediately.
3.4.2 Committing Wireless Settings
In addition to committing sensor settings, there are also settings specific to wireless devices. In order to commit these settings, command 197 must be used. Note that committing the default settings will have no effect on wireless settings, while committing wireless settings will not change the default settings. A list of wireless settings for the sensor can be found in table 3.4.6 and a list of wireless settings for the dongle can be found in table 3.4.7.
3.4.3 Natural Axes
The natural axes of the 3-Space Sensor are as follows:
The positive X-axis points out of the right hand side of the sensor, which is the side that is facing right when the buttons face upward and plug faces towards you.
The positive Y-axis points out of the top of the sensor, the side with the buttons.
The positive Z-axis points out of the front of the sensor, the side opposite the plug.
Bear in mind the difference between natural axes and the axes that are used in protocol data. While they are by default the same, they can be remapped so that, for example, data axis Y could contain data from natural axis X. This allows users to work with data in a reference frame they are familiar with. See section 2.8 for a diagram of the natural axes.
3.4.4 Sensor General Settings
Accelerometer Rho Value
Compass Rho Value
Determine how trusted the accelerometer is
Determine how trusted the compass is
Determines the scale, bias, and cross-axis parameters for the accelerometer
Confidence Mode, 5 to 100
Confidence Mode, 5 to 100
Accelerometer Reference Vector Determines which vector the accelerometer should read in order for the sensor's untared orientation to be the identity orientation.
Compass Reference Vector Dertemines which vector the compass should read in order for the sensor's untared orientation to be the identity orientation.
Reference Vector Mode
Determines whether the gyroscope is enabled or not
Determines how orientation is filtered.
Determines the scale, bias, and cross-axis parameters for the compass Factory calibrated
Determines the scale, bias and cross-axis parameters for the gyroscope Factory calibrated
Determines whether the compass is enabled or not
Determines whether the accelerometer is enabled or not
Determines how reference vectors are calculated for orientation estimation.
Determines the default composition order of euler angles returned by the sensor.
Determines how raw sensor data is transformed into normalized data
Determines what natural axis direction each data axis faces
Determines how many samples the sensor takes per cycle
0, 1, 0
0, 0, 1 (Default mode is to re-calculate this vector on startup)
1 (Single automatic)
+X, +Y, +Z
1 from each component sensor
Running Average Percentage
Desired Update Rate
Determines how heavy of a running average to run on the final orientation
Determines how long each cycle should take(ideally)
Determines how the accelerometer and compass reference vectors are determined
Determines the speed of RS232 communication
Determines how fast the CPU will run
0(no running average)
RS232 Baud Rate
Button Gyro Disable Length
Determines the RGB color of the LED
Determines whether the LED mode is static or not.
Determines whether the joystick is enabled or not
Determines whether the mouse is enabled or not
Determines how many cycles the gyro is ignored after a button is pressed
Multi Reference Weight Power Determines what power each multi reference vector weight is raised to 10
Multi Reference Cell Divisions Determines how many cells the multi reference lookup table is divided into per axis
Multi Reference Nearby Vectors Determines how many nearby vectors each multi reference lookup table cell stores
Wired Response Header Bitfield Determines what kind of data is prepended to response data.
Streaming Slots Determines which commands are executed during a streaming session.
255, 255, 255, 255, 255, 255, 255, 255
Streaming Timing Dertemines the streaming interval, duration and delay.
10000, 4294967295, 0
3.4.5 Dongle General Settings
Desired Update Rate
Determines how long each cycle should take(ideally)
Determines the RGB color of the LED
Determines whether the LED mode is static or not.
Wired Response Header Bitfield Determines what kind of data is prepended to response data. 0
3.4.6 Sensor Wireless Settings
Determines the panID of this sensor.
Determines the address of this sensor.
Determines the channel of this sensor.
3.4.7 Dongle Wireless Settings
Logical ID Table
Determines the panID of this dongle.
Determines the address of this dongle.
Determines the channel of this dongle.
Determines the mapping between logical ID and addresses.
Joystick Logical ID
Determines number of retries dongle will attempt on failed transaction
Determines the logical ID of the device that will act as the joystick, or -1 if there is no joystick desired.
Factory determined (cannot be set, only read)
Factory determined (cannot be set, only read)
Array of 15 unsigned 16-bit integers, values initialized to 0
Mouse Logical ID
HID Update Rate
HID Asynchronous Mode
Streaming Flush Mode
Wireless Response Header
Determines the logical ID of the device that will act as the mouse, or -1 if there is no mouse desired.
Update rate for requesting joystick/mouse information, in milliseconds.
Determines whether joystick/mouse data transmission is asynchronous.
Determines whether or not asynchronously requested data is automatically flushed or whether it must be requested via a dongle command.
Determines what kind of data is prepended to wireless response data.Wireless Response Header Bitfield
15 (67 hz)
0 (Auto flush off)
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project