Collect Urban Dataset for Autoware and Autoware Labs

[ataparlar]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

An urban dataset needs to be collected which includes tunnel and bridges. For Autoware’s new planned feature LOAM Based Localization, we need extreme test environments like tunnels and bridges.

Hesai Pandar XT32 LiDAR and Applanix POS LVX GNSS/INS will be used for data collection.

Purpose

Collecting and generating needed data for Autoware’s components.

Possible approaches

Using a Mobile Mapping System for collecting LiDAR ang GNSS/INS data.

Definition of done

• Collect the time matched LiDAR and GNSS/INS data via PPS and GPRMC signals.
• Generate a point cloud with those data.

Update

2024-07-03

• Point clouds are generated and shared with the community.
  • https://drive.google.com/drive/folders/1vJ7vM_KX5djFCJsMQCzaQTlc6Z3MgpIE?usp=drive_link
• Dynamic Object Removal not implemented yet.

2024-07-09

• Same data processed by @n-patiphon.
  • You can find the related topics here: https://github.com/orgs/autowarefoundation/discussions/4940#discussioncomment-9953500

[ataparlar]

The route as planned as in the below image:

[ataparlar]

The data is collected but we are not able to work with this dataset with LIO-SAM. We have a little time difference between GNSS/INS data and LiDAR data.
If we use only LiDAR data for mapping purpose, we cannot complete the mapping of the whole area. So, this is not suitable.

We are checking the sensors for one more data collection work. The route will be the same. I will keep here posted.

Here are the images of LIO-SAM export broken point clouds:

Tunnel:

Bridge:

General:

[ataparlar]

Hi everyone.
We have completed one more data collection session as we planned due to the broken ros2 bag data. Here is the route of this data collection on the map:

We have tested the newly collected data with LIO-SAM and it works just fine. Here is a demonstration of the tunnel data:

The collected data link is attached below as a Google Drive link:

• https://drive.google.com/drive/folders/1AMwgr3zK4SRIWswMuPt2IOBFrpB_hp-T?usp=drive_link

We will create highly precise point clouds with those data. I will keep updating.

@n-patiphon you can use this data for Map IV Engine as you discussed with @armaganarsln .
The sensors are Applanix POS LVX and Hesai XT32.

[n-patiphon]

@ataparlar Thank you. I will take a look later when I have a chance. In the mean time, which driver did you use to capture heisai packets?

[ataparlar]

@n-patiphon We used this one provided by Hesai: https://github.com/HesaiTechnology/HesaiLidar_ROS_2.0

I am looking forward for your response. Thank you.

[ataparlar]

Also, in last Software WG Meeting, @mertyavuz41 shared the point cloud map of the same route in the figures. @mertyavuz41 can you please share the raw data of the point cloud map with @n-patiphon, so that we can make a comparison on the different data with MapIV Engine and create a benchmark.

[mertyavuz41]

Hi,

Here the raw rosbag file of generated point cloud, but the link will be available for 12 hours;

https://flowride-ros-bags.s3.eu-west-1.amazonaws.com/LOCINT/MAPPING_BAGS/istanbul_mapping_carlitto.bag?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIA5RICVTSQZHVFIC3V%2F20240530%2Feu-west-1%2Fs3%2Faws4_request&X-Amz-Date=20240530T104620Z&X-Amz-Expires=43200&X-Amz-Signature=e1dded6ca35a59100ecca10f2731ad44eb60eaf40f3810179bbe01f922254bac&X-Amz-SignedHeaders=host&x-id=GetObject

PCD:
https://netorgft4229778-my.sharepoint.com/:u:/g/personal/mert_adastec_com/EVmLdZoUZRRPnGwhozF4dH0BdhFLwvtGxIyKhrF4Nr3QPg?e=I68GWx

Note:
The bag file collected high speed(50 - 85 km/h) so the PCD may involves kind of ghosting errors.

[n-patiphon]

@mertyavuz41 Thank you for sharing!
@ataparlar Just to confirm which one is the correct data? Also, it would be great to have actual packets and not the PointCloud2 along with the calibration between LiDAR, GNSS, IMU. Do you guys already have that on hand?

[mertyavuz41]

@n-patiphon, sorry we didn't gather data lidar packets format. However, I can provide calibration between LiDAR and GNSS. The IMU already integrated inside to GNSS sensor. The /novatel/oem7/odom message provides many information with all field of message, you can directly use it.

GNSS - Lidar Carlitto: x, y, z, yaw, pitch, roll;
-1.24764 0.079204 0.0823642 3.10731 3.1249 3.13566

The calibration z value is not correct due to lack of z-axis motion. The haphazardly measurement on that axis is 1.012(lidar to gnss).

[n-patiphon]

@mertyavuz41 Thank you so much. That helps a lot.

Just to confirm. The data you shared is different than what @ataparlar shared right?

[n-patiphon]

@ataparlar I will share the results I presented soon. Let me clean up the files and figure out where to upload (company policy).

I have another question. Do you have any other data that you collected? For example, raw data from Polsv (without post-process) and CAN if you have it. Not post-process odometry but actual noisy CAN from the vehicle.

[ataparlar]

Hi @n-patiphon,
We don't have CAN data. We have the raw GNSS/INS data in "T04" format which Applanix uses. I can provide that if you are able to process that data. Or I can provide a .txt which contains all the GNSS/INS data line by line.

Additionally, the data that I shared and @mertyavuz41 shared are different. They don't have any relation. Only, the routes are the same.

[n-patiphon]

@ataparlar I think Odometry is from Polsv too right? If you could provide the raw data that would be great. Txt would be easier to handler if they have correct timestamps

[ataparlar]

@n-patiphon Yes the odometry from POS LVX. I will publish the data as txt. Can you tell what kind of timestamps do you require? Is UTC time in seconds ok?

[n-patiphon]

@ataparlar I will finally convert it back to rosbag so I will need some way to match this timestamp with the rosbag timestamp. As long as they’re the same it should be fine. Unix time in seconds would be easiest to deal with.

[n-patiphon]

@ataparlar Of course if you can provide it in rosbag format that would speed things up a lot

[ataparlar]

@n-patiphon I'll look into it and keep posted here. I'll do my best :)

[n-patiphon]

@ataparlar Thank you so much 👍 Just want to confirm. The raw data I want would be GNSS, IMU, and ODOM “before” being processed and not the post-process solution. I’m not sure if you can get that from Polsv but please keep me posted.

[ataparlar]

@n-patiphon yes I can. However, we can't export directly the UTC time in seconds. Instead of that, we are exporting seconds from the start of the day. Additionally, we give the mission date so that you can find the UTC time. I'll send you a github link as a sample to do it.

I want to remind that, the below topics have the same data that you want in ros2 bag format:

• /applanix/lvx_client/gnss/fix - NavSatFix msg
• /applanix/lvx_client/imu_raw - Imu msg
• /applanix/lvx_client/odom - Odometry msg

The only difference is the Odometry msg which is not the global pose. It is a local pose but you can take the first NavSatFix msg as an origin and add them to each other to find a global pose. I think this is a more simple way to use the data instead of converting the txt into ros2 bag format.

[ataparlar]

@n-patiphon I put the raw gnss data txt files into the raw_gnss_data_txt directory in the below link. There is a missing txt file which is the first one because the raw GNSS data is corrupted somehow.

• https://drive.google.com/drive/folders/1AMwgr3zK4SRIWswMuPt2IOBFrpB_hp-T?usp=drive_link

And the below link shows an example usage the time in those txt files.

• https://github.com/ataparlar/loam-mapper/blob/master/src/transform_provider.cpp#L32

[ataparlar]

Hi everyone,

I am generating the point cloud maps right now. Here is some preview with loam_mapper:

Tunnel dataset:

Bridge dataset:

I'll publish full cloud links in MGRS projection with a drive link.

[n-patiphon]

Mapping results of this dataset will also be shared here.
https://github.com/orgs/autowarefoundation/discussions/4940

[ataparlar]

Here are the exported point clouds:

https://drive.google.com/drive/folders/1vJ7vM_KX5djFCJsMQCzaQTlc6Z3MgpIE?usp=drive_link

Only the first part could not exported. Because somehow the collected raw GNSS data is corrupted. I added the route image to the directory.

We must mention that the point clouds include noises due to the dynamic objects. We are working on removing the dynamic objects right now and I'll let you know about this issue later.

The below image shows the top view of the point clouds:

[n-patiphon]

@ataparlar @armaganarsln @mertyavuz41 I shared the point cloud results in https://github.com/orgs/autowarefoundation/discussions/4940#discussioncomment-9953500

Please note that I didn't check all the data one by one, so please let me know if there's something wrong with the data.

[ataparlar]

Hi everyone,

We have collected the final data and processed it. A ROS2 bag and raw GNSS/INS+LiDAR data are collected for mapping and localization test purposes.

---

The link below contains the full point cloud, corner and surface point cloud.

• https://drive.google.com/drive/folders/1vJ7vM_KX5djFCJsMQCzaQTlc6Z3MgpIE?usp=drive_link
• Generated point clouds converted into MGRS projection. They are in the 35TPF zone. And also they are downsampled with 0.2 meters voxels.
• Zipped files contain the separated clouds.

---

The link below contains the ROS2 bag file.

• https://drive.google.com/drive/folders/1z0DyJgCOB8syB9miG9vL786bdEEA-QXr?usp=drive_link
• Please consider that the odom topic in the rosbag starts from the starting point of the GNSS/INS ROS2 driver. Not from the MGRS origin. Additionally, the same odom demonstrates the difference from the starting point with the data collected with GNSS/INS. It is not related to wheel odometry.
• Please consider that the GNSS/INS sensor gives the position of the base_link which is the center of two rear wheels.
• The sensors are connected each other with PPS cable and time information saved with GPRMC message.

Applanix POS LVX used as the GNSS/INS and Hesai XT32 used as LiDAR sensor. For data collection, the original Hesai ROS2 driver is used.

---

The link below contains the feature-matched raw GNSS/INS data (as txt) and LiDAR data (as PCAP)

• https://drive.google.com/drive/folders/1CDp4YJOYND8SFZvFBZOlPnkS-i1kGlCr?usp=drive_link
• Please consider dividing the PCAP file into pieces with editcap.
• GNSS/INS data is post-processed and feature-matched.
• GNSS/INS data is in NED (north-east-down) coordinates. Please consider this using related columns in GNSS/INS txt data.
  • The axes GNSS/INS in raw data according to the car's direction:
    • X -> forward
    • Y -> right
    • Z -> down
  • The axes LiDAR in raw data according to the car's direction:
    • X -> backward
    • Y -> right
    • Z -> up
• GNSS/INS - LiDAR calibration parameters are added to the link for related coordinate systems.
• PCAP data has LiDAR points and GPRMC messages for time sync. Hesai XT32 manual can be examined for parsing the data.
  • The data is collected in Strongest mode for LiDAR.

---

The calibration parameters between sensors in ROS2 axes:

• GNSS/INS to LiDAR:
  • X: 0.9 meters
  • Y: -0.01 meters
  • Z: 1.295 meters
  • roll: -0.30633 degrees
  • pitch: 1.05589 degrees
  • yaw: 179.61125 degrees

---

If you have any questions about the dataset or implementation, you can reach me anytime.

Here are some images: