[adataset tool] Why is the z of pose set to 0 in converting KITTI dataset to Apollo record?

[boyang9602]

Hi,

I wonder why the pose's z is set to 0 when converting the KITTI dataset to the Apollo record. The KITTI dataset contains latitude, longitude, and altitude. Is it possible to calculate the z value? Thanks!

https://github.com/ApolloAuto/apollo/blob/d46f19207cdd6fbc809b562d6fe929b77df9fb4a/modules/tools/adataset/adataset/kitti/kitti.py#L115

[daohu527]

Apollo's planning module does not take the Z value into account yet, so we temporarily remove the Z value here to avoid the problem of map overlap on DreamView.

[boyang9602]

Thank you for the clarification! I am doing some testing work regarding the MSF-based localization. The LiDAR map in Apollo MSF localization requires the pose in x, y, z, q.w, q.x, q.y, q.z. So I am wondering what the z value should be. Is it just the altitude?

[boyang9602]

By the way, if Apollo's planning does not take the z value into account, will it work properly on an overpass where the roads are stacked?

[boyang9602]

So I think z should be height_wgs84 based on code snippets below.

https://github.com/ApolloAuto/apollo/blob/3fbb8938dc517dc03e4f490dea562be21d8d01bb/modules/common_msgs/sensor_msgs/gnss_best_pose.proto#L76-L79 https://github.com/ApolloAuto/apollo/blob/3fbb8938dc517dc03e4f490dea562be21d8d01bb/modules/localization/msf/local_integ/measure_republish_process.cc#L412-L415 https://github.com/ApolloAuto/apollo/blob/3fbb8938dc517dc03e4f490dea562be21d8d01bb/modules/localization/msf/local_integ/localization_integ_impl.cc#L328-L335

Below is the the structure of gnss_pos

/**@brief the position struct including longitude, latitude and height. */
struct Position {
  Position(): longitude(0.0), latitude(0.0), height(0.0) {}
  double longitude;
  double latitude;
  double height;
};

[boyang9602]

OXTS RT3000 V3 uses wgs84 for latitude and longitude as described, while altitude could be referenced to the geoid (default) or ellipsoid in the user manual:

From the Global Coordinate System tab you can choose which reference datum to output latitude and longitude relative to. The default system and the standard for GPS is the WGS 84 datum. Note: Currently outputs will only reference datums other than WGS 84 in post- processing. Real-time outputs will still be referenced to WGS 84 even if another option is selected. The Altitude reference can be compared to either ellipsoidal or geoidal height. If Ellipsoid is selected, the altitude will be output with respect to the reference ellipsoid selected in the coordinate datum section. If Geoid (receiver default) is selected, the altitude will be relative to the geoid used in the GNSS receivers. A Custom geoid file can be used for local variations. To download supported geoid files, go to http://support.oxts.com/local-geoid-files. The UGF file must be saved in C:\Users\username\Documents\OXTS\Shared\Custom geoid files. Once the file is downloaded and saved in this location, it can be selected from the dropdown box. A constant offset to the specified altitude reference can be applied by checking the Set offset box typing in a value into the cell.

For Apollo, https://github.com/ApolloAuto/apollo/blob/3fbb8938dc517dc03e4f490dea562be21d8d01bb/modules/common_msgs/sensor_msgs/gnss_best_pose.proto#L76-L79 I think height_wgs84 refers to the ellipsoid, height_msl refers to the geoid, and undulation is the geoid height (diff between ellipsoid and geoid), so height_msl is the diff between height_wgs and undulation.

However, KITTI's paper did not mention the configuration of the GPS/IMU device. If it uses the default setting, the altitude is referenced to the geoid, i.e., height_msl, otherwise, it is height_wgs.

Also, the devkit provided by KITTI uses the altitude directly for converting OXTS data to pose.

  % translation vector
  [t(1,1) t(2,1)] = latlonToMercator(oxts{i}(1),oxts{i}(2),scale);
  t(3,1) = oxts{i}(3);

OXTS RT3000 user manual: https://www.oxts.com/wp-content/uploads/2024/02/OxTS-RT500-RT3000-Manual-240215.pdf