[Rock-dev] IMU Sensor - Incorporation of sensor noise values

[Javier Hidalgo Carrió]

Dear rocks,

I am currently thinking how to incorporate errors in measurement given 
by an IMU. The easiest seems to add data members to the IMUSensor data 
type, like:

/** Velocity Random Walk raw accelerometer noise */
base::Vector3d vrw;

but I am not fully sure from the rock perspective:

The issue is that all inertial sensors have at least two typical types 
of errors:
(1) (Angular or Velocity) Random walk (ARW or VRW) -> affected by white 
noise
(2) Bias instability
And many times also (3) Rate Random Walk (RRW) and some times many more 
like temp variation.... but at least those two mentioned above.

These error coefficients (coeff.) will affect your measurement  
uncertainty which is an input to your filter algorithm.
These coeff. are constant for a particular IMU/sensor while the 
uncertainty is not. That means that for example if our gyro has an ARW 
of 6 deg/sqrt(hr) at the sampling time is 100Hz (0.01sec) the 
uncertainty (std. deviation) is 1deg/sec, but at the sampling time 10 Hz 
(0.1sec) would be 0.31deg/sec and at 1Hz would be 0.1deg/sec. Low pass 
filtering.

The question is where to write  these values.  Imaging the following case:

IMUdriver(100Hz) -> LowPassFilter(10Hz) -> SensorFusion(10Hz) ->

In one case, the input and output ports for the low pass filter 
component  (LowPassFilter) are IMUSensor type.
Both ports have the same ARW but different frequencies, which means 
different std. dev. in the samples for a probabilistic form like Kalman 
Filter.

One solution will be, let's change the output port of the LowPassFilter 
to a RigidBodyState and fill the uncertainty matrices. This is another 
possibility, but in that case we will loss information, imaging that we 
have a RRW noise (this noise did not change by the lowpassfilter) in our 
IMUSensor and we want to incorporate this in our next component model 
(the SensorFusion). With the RigidBodyState output we will not have this 
sensor error coeff... and is good because it is not a sensor.

Other possibility would be to write the values in the .orogen files of a 
orogen_component but in this way the component has the error information 
and no the IMUSensor. That entail change the .orogen file depending on 
the sensor input.

Another possibility is to read it from a config file, in this case, how 
I should do it?

Any suggestion?

Thank you,

Javi