-
Notifications
You must be signed in to change notification settings - Fork 437
Testcode parameters
This page briefly explains the parameters of the 3 codes used for testing purposes. The parameters of MSF are explained on the Parameter files page. Note that these codes are not needed in order for the system to work and are only useful for testing purposes. On Setup for GPS and ROVIO the steps to include these codes are denoted with a "*". Sample parameter files are available here.
The noise drift handler code currently supports 4 in- and output types: pose, position, transform and NavSatFix. They all have very similar parameters. Below the parameters will only be listed once, where the type should be replaced by the corresponding message type. In addition one will have to prepend /noise_drift_handler/
to all parameters i.e. type_noise_mean
should be replaced /noise_drift_handler/pose_noise_mean
for pose messages.
- Noise parameters: The noise in the measurements can be controlled using 3 parameters. The first
type_use_noise
is a boolean that simply enables or disables noise addition. When disabled no noise is added to measurements. When enabled the code adds Gaussian noise with mean defined intype_noise_mean
and standard deviation given bytype_noise_number_stddeviations
. - Outlier parameters: The creation of outliers can be enabled or disabled using the parameter
type_create_outlier
. When enabled an outlier is created with probability given bytype_probability_outlier
. In addition, one can usetype_group_size
to define how many consecutive measurements should be outliers, in case an outlier is created. The default value is1
. Outliers are simply created by adding zero-mean Gaussian noise with a very high standard deviation. - Divergence parameters: This code can also be used to simulate a diverging sensor at a fixed time using
type_diverge_fixed_time
True
andtype_diverge_frame
to define the number of the measurement where the sensor should start diverging. Alternatively, the sensor can diverge with a probability given by [what?]. The parametertype_diverge_length
gives the number of measurements for which the sensor should diverge.
IMPORTANT NOTE: When using this code for divergence only the input to MSF is corrupted and while MSF believes the sensor is diverging it is not in reality, meaning that once measurements are not corrupted anymore the sensor will work as intended again independent of the sensor. To actually make sensors diverge see the Rovio divergence handler below.
The noise drift handler has a total of 8 in- and outputs:
noise_drift_handler/pose_input
noise_drift_handler/transform_input
noise_drift_handler/pose_output
noise_drift_handler/position_input
noise_drift_handler/position_output
noise_drift_handler/gps_input
noise_drift_handler/gps_output
noise_drift_handler/events
transform_input
is converted to pose_input
, that's why it has no corresponding transform_output
. events
outputs a vector if a measurement starts or stops diverging. See the code for a detailed description.
This code corrupts input to ROVIO to make it diverge. While this is specifically tuned for ROVIO and will only work for ROVIO as is, a similar approach can probably be taken for different sensors. The idea of the code is to corrupt the IMU input of ROVIO which will cause this to diverge. Different from the approach described above, ROVIO does not recover by itself, that's why it is interesting to look at sensor recovery in this case (see Parameter files). There are only a few parameters.
-
/rovio_divergence_handler/use_fixed_time
: This boolean parameter defines whether ROVIO should diverge at a fixed frame (True) or with a certain probability (False) -
/rovio_divergence_handler/divergence_start_frame
: In case the above parameter isTrue
this specifies the number of measurements after which ROVIO should start diverging. Note that it typically takes some measurements until the effect becomes apparent. -
/rovio_divergence_handler/probability_divergence
: If ROVIO should diverge with a certain probability, this can be defined using this parameter. -
/rovio_divergence_handler/divergence_group_size
: This parameter specifies the number of consecutive IMU measurements that should be corrupted. Usually, around 20 is sufficient to make ROVIO diverge.
Rovio divergence handler has 7 in- and outputs:
rovio_divergence_handler/cam0_input
rovio_divergence_handler/imu0_output
rovio_divergence_handler/cam0_input
rovio_divergence_handler/cam0_output
rovio_divergence_handler/imu1_input
rovio_divergence_handler/cam1_output
rovio_divergence_handler/events
events
outputs a vector if a measurement starts or stops diverging. See the code for a detailed description.
The pos_to_error
handler computes the error of the state estimate online given a ground truth.
-
/pos_to_error/data_type
: This parameter is a string that defines the type of the estimate. For now, only "msf" is supported. -
/pos_to_error/truth_type
: Similar to the previous parameter this one is used to define the truth type. For now "vicon" and "leica" are supported. -
/pos_to_error/estimate_tf
: This boolean parameter defines whether the transform between the state estimate and the ground truth frame should be estimated or not. If it's not being estimated it has to be given as a parameter. -
/pos_to_error/translation
: Ifestimate_tf
isFalse
this gives the translation from data frame to ground truth frame as a vector [x, y, z] -
/pos_to_error/quaternion
: Ifestimate_tf
isFalse
this gives the translation from data frame to ground truth frame as a quaternion [w, x, y, z] -
/pos_to_error/ninit_points
: Ifestimate_tf
isTrue
this defines the number of points that are used to estimate the transform. The higher this number the more precise the estimate will be. However, the error estimate while estimating the transform is not meaningful.
The pos_to_error
handler code has 3 in- and outputs:
pos_to_error/datainput
pos_to_error/truthinput
pos_to_error/output