On-sensor processing of Sensor Fusion data
We've had success with implementing on-sensor data processing. We could implement rather complex data processor chains that worked reliably, without a hitch — as long as we didn't try to use some data processors on sensor fusion data signals.
Example stream of data from RSS(raw accelerometer signal), moving the sensor around randomly:
0.8592529
0.92108154
1.355957
2.1344604
2.8235474
2.854309
2.619751
2.414917
2.376587
2.3988647
2.3880615
2.2908936
2.4415283
As expected, the RSS data processor's input is a CartesianFloat, and its output is a floating point number: the length of the 3D input vector.
However, here's an example stream of data from RSS(sensor fusion linear acceleration signal), moving the sensor around randomly:
(x: 6.7e-42, y: 0.0, z: 0.0)
(x: 4.313e-42, y: 0.0, z: 0.0)
(x: 6.952e-42, y: 0.0, z: 0.0)
(x: 7.678e-42, y: 0.0, z: 0.0)
(x: 8.814e-42, y: 0.0, z: 0.0)
(x: 6.596e-42, y: 0.0, z: 0.0)
(x: 6.477e-42, y: 0.0, z: 0.0)
(x: 4.919e-42, y: 0.0, z: 0.0)
(x: 5.765e-42, y: 0.0, z: 0.0)
(x: 7.245e-42, y: 0.0, z: 0.0)
(x: 4.94e-42, y: 0.0, z: 0.0)
(x: 6.21e-42, y: 0.0, z: 0.0)
(x: 8.6e-42, y: 0.0, z: 0.0)
(x: 1.704e-42, y: 0.0, z: 0.0)
(x: 8.89e-42, y: 0.0, z: 0.0)
(x: 8.9e-42, y: 0.0, z: 0.0)
(x: 8.186e-42, y: 0.0, z: 0.0)
(x: 7.695e-42, y: 0.0, z: 0.0)
(x: 8.511e-42, y: 0.0, z: 0.0)
(x: 7.308e-42, y: 0.0, z: 0.0)
...
The first surprise is that the same RSS data processor now produces a CartesianFloat output. The second is that no matter what we do with the sensor, its output is always almost zero, even though the linear acceleration of the sensor definitely wasn't zero during the test.)
The same thing happens with the sensor fusion gravity vector signal.
Those data processors that just let the data through without modification (e.g. passthrough) seem to work. Those that process the data don't.
Is there a reason for the sensor fusion signals not being usable as input for some data processors, or is it a bug?
Model: MetaMotion R
Model number: 5
Firmware: 1.4.4
Hardware: 0.4, 0.3
Comments
I'm not sure why this is a surprise: RSS converts a vectored input into a scalar, which is what was observed with the raw accelerometer data.
Sensor fusion data is not supported with processors that transform the data.
Yes
CartesianFloatis a term used for a 3D vector with x, y, z components in the SDK. It is surprising to see it as the output type of the RSS data processor.I see. Thank you for the info.
The issue here is that the sensor fusion module outputs floating point values natively in the firmware, but the data processor is only implemented to deal with fixed point or integer values. This means you can't manipulate the data on device with the current set of filters (you can pass it through as you noted since it just blindly passes the bits).
I'll update this thread if we end up adding this feature, but in the meantime the SDK should raise an error when trying to do this to make it clear this isn't supported.
I see. Thanks for the explanation!