Skip to content

Testcode parameters

tkazik edited this page Nov 8, 2021 · 5 revisions

Parameter files for additional test codes

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.

Noise Drift Handler

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.

Parameters

  • 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 in type_noise_mean and standard deviation given by type_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 by type_probability_outlier. In addition, one can use type_group_size to define how many consecutive measurements should be outliers, in case an outlier is created. The default value is 1. 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 and type_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 parameter type_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.

Input and Output

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.

Rovio divergence handler

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.

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 is True 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.

Input and Output

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.

Position to error handler

The pos_to_error handler computes the error of the state estimate online given a ground truth.

Parameters

  • /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: If estimate_tf is False this gives the translation from data frame to ground truth frame as a vector [x, y, z]
  • /pos_to_error/quaternion: If estimate_tf is False this gives the translation from data frame to ground truth frame as a quaternion [w, x, y, z]
  • /pos_to_error/ninit_points: If estimate_tf is True 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.

Input and Output

The pos_to_error handler code has 3 in- and outputs:

  • pos_to_error/datainput
  • pos_to_error/truthinput
  • pos_to_error/output