tag文件生成问题

[ShangfengShi]

使用tool下的generate_tag对示例数据重新生成对应的tag（SPP），会出现卡死的情况？

[chichengcn]

generate_tag配套了两个yaml配置文件，一个为single.yaml，另一个为master_and_client.yaml。你的问题描述不太清晰，我不太清楚你遇到的问题具体是什么，但我想或许你使用master_and_client.yaml进行tag生成，能够解决你所说的问题。

具体来说，tag文件是用来控制回放时序的，它的格式为时间戳+bin文件指针，其中，时间戳指明了响应bin文件对应位置的记录时间。这里的时间戳使用的是相对时间，因此，如果单独对某个bin文件生成tag，而不建立该文件与其他bin文件的tag的对应关系的话，回放的时间实际上是错位的。这种情况下，在回放时，会从tag中时间戳显示最早的位置开始回放，而由于时间错位，其他文件在此时并不会被同步回放。由于某些传感器（如GNSS）需要多个bin文件的数据流都存在的情况下才可以开始算法解算（如只有rover.bin但没有ephemeris.bin的时候，并不能解算），因此，tag错乱时，估计其可能不会正常运行。

因此，我们为generate_tag提供了master_and_client.yaml配置文件，即以一个文件的tag为基准（master），去生成其他文件的tag（client），以建立对应关系，建议选择一组数据中频率最高的bin数据作为master，比如在我们的数据集中，建议选择imu.bin为master。以我们的数据集为例，由于imu.bin已存在tag，所以可以直接使用master_and_client.yaml对其他文件的tag进行生成，如果imu.bin没有对应的tag文件，则应先使用single.yaml对imu.bin进行tag生成，而后使用master_and_client.yaml以imu.bin为master对其他文件进行tag生成。

[oldfish163]

池博士，您好！
具体问题是这样的：我在公开数据集1.1（即3月20日的开阔地段数据）中删去了GNSS rover和ephemeris的tag文件，按照上述的方法以imu.bin的tag文件作为master，将rover.bin和ephemeris.bin分别作为client生成各自的tag文件，以重新生成的文件去运行SPP_TC模式，得到以下提示且一直无法解算，下面是相关的配置文件

tag的配置文件：

SPP_TC的配置文件（只做了路径和时间的修改）：
`stream:
streamers:

• streamer:
  tag: str_gnss_rov_file
  output_tags: [fmt_gnss_rov]
  type: file
  path: /home/jh/gici-open-master/data/test/0320/gnss_rover.bin
• streamer:
  tag: str_gnss_eph
  output_tags: [fmt_gnss_eph]
  type: file
  path: /home/jh/gici-open-master/data/test/0320/gnss_ephemeris.bin
• streamer:
  tag: str_imu
  output_tags: [fmt_imu]
  type: file
  path: /home/jh/gici-open-master/data/test/0320/imu.bin
  loop_duration: 0.001
• streamer:
  tag: str_dcb_file
  output_tags: [fmt_dcb_file]
  type: file
  path: /home/jh/gici-open-master/option/CAS0MGXRAP_20221580000_01D_01D_DCB.BSX
  enable_time_tag: false
• streamer:
  tag: str_solution_file
  input_tags: [fmt_solution_file]
  type: file
  path: /home/jh/gici-open-master/output/spptest_tc_solution.txt
  enable_time_tag: false

formators:

• formator:
  io: input
  tag: fmt_gnss_rov
  type: gnss-raw
  sub_type: tersus
• formator:
  io: input
  tag: fmt_gnss_eph
  type: gnss-rtcm-3
  start_time: 2023.03.20
• formator:
  io: input
  tag: fmt_dcb_file
  type: dcb-file
• formator:
  io: input
  tag: fmt_imu
  type: imu-pack
• formator:
  io: output
  tag: fmt_solution_file
  type: nmea
  use_esa: true
  use_esd: true
  talker_id: GP

replay:
enable: true
speed: 1.0
start_offset: 0.0

estimate:

• estimator:
  tag: est_gnss_imu_tc
  type: spp_imu_tc
  input_tags: [fmt_gnss_rov, fmt_gnss_eph, fmt_dcb_file, fmt_imu]
  fmt_gnss_rov_roles: [rover]
  fmt_gnss_eph_roles: [ephemeris]
  fmt_dcb_file_roles: [code_bias]
  fmt_imu_roles: [major]
  output_tags: [fmt_solution_file]

  output_align_tag: fmt_imu
  output_downsample_rate: 40
  compute_covariance: false
  spp_imu_tc_options:
  max_window_length: 3
  spp_options:
  gnss_estimator_base_options:
  gnss_common:
  min_elevation: 12.0
  min_SNR: [35.0, 30.0]
  use_outlier_rejection: true
  max_pesudorange_error: 10.0
  imu_estimator_base_options:
  imu_parameters:
  sigma_bg: 1.0e-3
  sigma_ba: 1.0e-2
  sigma_g_c: 2.6700e-04
  sigma_a_c: 0.0112
  sigma_gw_c: 2.0881e-06
  sigma_aw_c: 2.7361e-04
  body_to_imu_rotation: [-90.0, -90.0, 0.0]
  body_to_imu_rotation_std: 5.0
  car_motion: true
  car_motion_min_velocity: 3.0
  car_motion_max_anguler_velocity: 5.0
  estimator_base_options:
  max_iteration: 5
  num_threads: 4
  max_solver_time: 0.05
  verbose_output: true
  solver_type: dense_normal_cholesky
  trust_region_strategy_type: levenberg_marquardt
  gnss_imu_initializer_options:
  max_iteration: 30
  num_threads: 4
  max_solver_time: 0.5
  gnss_extrinsics: [-0.029, 0.354, -0.042]
  gnss_extrinsics_initial_std: [0.0, 0.0, 0.0]
  time_window_length_slow_motion: 0.05
  time_window_length_dynamic_motion: 0.5
  min_acceleration: 0.5

logging:
enable: true
min_log_level: 0
log_to_stderr: true
file_directory: `

[chichengcn]

我这边也复现了这个问题，因为tool文件夹下的工具均为粗略开发，所以难免会存在一些bug。你所提到的问题是generate_tag在生成星历文件的tag时时序错误导致的，与其他类型的数据不同的是，星历数据的时间戳并不是一秒一秒增加的，而是几十分钟~几小时更新一次时间戳，并且改时间戳可以用于前后几十分钟~几小时的观测数据，因此为所谓类型的星历文件数据打上合适的回放时间是比较困难的，我们当时写代码的时候只是针对urbannav数据集中的星历写的。

我正在尝试解决星历的tag生成问题，此外，我也在撰写不基于tag的事后处理数据流模式，以在某些工作流中替代目前的仿实时回放模式。我会在所有相关代码都上传后再关闭这个issue。

[oldfish163]

感谢池博的回答，另外您提到关于unstable版本中更新的读取rinex的接口，用urbannav数据做过测试。请问一下是具体如何测试的，如果只进行gnss定位（如spp）此时是否直接以观测文件为master生成tag，按照回放机制进行回放（我尝试了此种方式发现还是一直等待星历的情况）？

[chichengcn]

关于urbannav的问题，请参考issue #50。

[chichengcn]

已上传不依赖于tag回放的post-file回放机制代码到unstable分支，该模式具有如下特点：

1. post-file回放模式为标准事后处理模式，该模式采用单线程处理，会自动完成文件时间戳同步，并按照时间先后顺序进行阻塞处理，不会因为计算机性能问题产生pending。

2. 增加FileReaderBase基类，并实现了若干子类，以使得用户可以绕开数据流的方式进行文件读取，从而适配更多的文件形式。用户可以通过实现load函数，以增加其他文件格式的读取。

3. 增加burst_load选项和机制，以使得某些文件的数据可以在开始回放时被全部读入，并存储于内存中待使用，目前已实现对GNSS星历文件的burst读取和使用。

已配套在option文件夹上传配置示例以使用上述回放模式，相关使用文档将在其更新到稳定版本时进行更新。