LiDAR self-calibration stays at 0% / Not Accepted with Hesai AT128P (custom lidar, spoofed as VELO_VLS128)

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Hi everyone,

I am opening a shorter follow-up of https://forums.developer.nvidia.com/t/lidar-self-calibration-with-custom-lidar-calibration-stays-at-0-not-accepted/361520/7 because I still could not resolve this issue.

I am using DRIVE OS 6.0.10 and adapted the original DriveWorks LiDAR self-calibration sample for a custom Hesai AT128P.

What works:

  • the sample runs
  • ICP produces plausible relative poses
  • CAN-only egomotion produces plausible motion
  • dwCalibrationEngine_addLidarPose(…) and dwCalibrationEngine_addLidarPointCloud(…) are called every sweep
  • no explicit DriveWorks error is thrown during calibration runtime

What does NOT work:

  • calibration status stays at: State: Not Accepted (0.00%)
  • lidar position correction stays 0 / rotation stays identity
  • updated lidar-to-rig transform remains equal to the nominal transform

Main differences vs. the original NVIDIA sample:

  1. original sample uses IMU-based egomotion, mine currently uses CAN-only egomotion:
    DW_EGOMOTION_ODOMETRY
  2. Hesai lidar type is not supported by the calibration module, so I spoof the lidar properties for calibration:
    deviceString = “VELO_VLS128”
  3. I manually overwrite the calibration lidar properties to values matching AT128P single return @ 10 Hz:
    • spinFrequency = 10.0
    • numberOfRows = 128
    • packetsPerSecond = 6000
    • packetsPerSpin = 600
    • pointsPerSecond = 1536000
    • pointsPerSpin = 153600

So I am not sure whether the calibration routine expects the actual per-sweep point count to match pointsPerSpin much more closely.

Example runtime output:

----------Sweep: 92----------
Getting egomotion transform between time 1767810975869854 (current) and 1767810975769887 (prev) (Difference: 99967)
poseAtoB Translation [x,y,z]: 0.179061338305, 0.000031024683, 0.000000000000

Adding current ICP pose to calibration engine:
  1.000000000000  0.000295144826  0.000234345949  0.182218134403
 -0.000295420032  0.999999344349  0.001175169717 -0.005197581835
 -0.000233998944 -0.001175238984  0.999999344349  0.005856796168
  0.000000000000  0.000000000000  0.000000000000  1.000000000000

Adding Ego-Motion pose to calibration engine:
  0.999999940395 -0.000346565619  0.000000000000  0.179061338305
  0.000346565619  0.999999940395 -0.000000000000  0.000031024683
  0.000000000000  0.000000000000  1.000000000000  0.000000000000
  0.000000000000  0.000000000000  0.000000000000  1.000000000000

Adding 80000 Lidar points to calibration engine.

Updated Lidar to Rig Transformation (4x4 matrix):
1.000000000000 0.000000000000 0.000000000000 3.577500104904
0.000000000000 1.000000000000 0.000000000000 0.000000000000
0.000000000000 0.000000000000 1.000000000000 0.584500014782
0.000000000000 0.000000000000 0.000000000000 1.000000000000

speedESC: 1.788888931274 m/s, frontSteeringAngle: 0.005188816693 rad, translation magnitude: 0.179061338305 m

My concrete questions are:

  1. Is DriveWorks LiDAR self-calibration expected to work at all with a Hesai AT128P when the lidar is only spoofed to the official supported types?

  2. Does the calibration routine internally assume scan geometry / model behavior of the spoofed supported lidar, so that a hybrid solid-state lidar like AT128P cannot progress even if initialization succeeds?

At this point I am less concerned about calibration quality and more about why the routine never leaves 0% / Not Accepted at all.

I can provide the modified sample code and additional logs if needed.

Thanks a lot.

5

Dear @Jis ,
yes – the routine assumes the spoofed lidar’s geometry and behavior so AT128P cannot progress even after initialization Succeeded with spoofed parameters.

6

Dear @SivaRamaKrishnaNV ,
thanks for your answer. Do you know if there is a way to make my adapted calibration sample work with our lidar?

8

No. it requires to add it as supported calibration device which requires changes in module to generate new shared libraries.