Collect Urban Dataset for Autoware and Autoware Labs

ataparlar commented 1 month ago

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] 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.

ataparlar commented 1 month ago

The route as planned as in the below image:

ataparlar commented 1 month ago

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: avrasya_tunnel

Bridge: galata_bridge

General: general

ataparlar commented 1 month ago

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: route_2

We have tested the newly collected data with LIO-SAM and it works just fine. Here is a demonstration of the tunnel data: Screenshot from 2024-05-23 16-00-58 Screenshot from 2024-05-23 15-16-23

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 commented 1 month ago

@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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

@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 commented 4 weeks ago

@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 commented 4 weeks ago

@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 commented 3 weeks ago

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 commented 3 weeks ago

@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 commented 3 weeks ago

@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 commented 3 weeks ago

@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 commented 3 weeks ago

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

ataparlar commented 3 weeks ago

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

n-patiphon commented 3 weeks ago

@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 commented 3 weeks ago

@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 commented 3 weeks ago

@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.