Localization và HD Map cho ADAS: NDT, Lanelet2, MapFree

Trong Bài 3 của series này, chúng ta đã khám phá cách hệ thống perception xác định vật thể xung quanh — xe khác, người đi bộ, biển báo — thông qua 3D object detection và occupancy grid. Nhưng biết cái gì ở xung quanh mới là nửa đầu bài toán. Để lập kế hoạch quỹ đạo an toàn, xe cần biết chính xác mình đang ở đâu trên mặt đường.

Đây là bài toán localization — và nó khó hơn ta nghĩ rất nhiều.

Lấy ví dụ thực tế: GPS điện thoại thường sai 3–10 m. Với người lái xe thủ công, sai số đó hoàn toàn chấp nhận được — bạn vẫn nhìn thấy làn đường và tự điều chỉnh. Nhưng với xe tự hành, sai số 3 m đã đủ để xe lấn làn hoặc bỏ lỡ điểm phanh quan trọng. Hệ thống ADAS cần độ chính xác dưới 10 cm, lý tưởng là 2–5 cm ở mức lateral (ngang làn đường).

Bài này sẽ đi qua ba lớp của bài toán localization hiện đại:

1. GNSS/IMU fusion — và tại sao RTK-GNSS một mình không đủ
2. LiDAR-based localization — NDT vs ICP vs Monte Carlo, benchmark số liệu thực
3. HD Map — Lanelet2 vs OpenDRIVE, và hướng map-free với MapTR và StreamMapNet

Roadmap series

1. Bài 1 — SAE Level 2 vs 2+ vs 3 vs 4: xác định ai chịu trách nhiệm lái, ODD và fallback.
2. Bài 2 — Sensor fusion: camera, radar và LiDAR dựng perception suy giảm an toàn khi cảm biến lỗi.
3. Bài 3 — Perception: 3D detection, occupancy grid và tracking trên nuScenes.
4. Bài 4 — Localization và HD map: GNSS/IMU fusion, NDT trên LiDAR, hướng map-free.
5. Bài 5 — Planning & control: từ rule-based tới MPC và PDM, bám quỹ đạo thực tế.
6. Bài 6 — Validation: ISO 26262, SOTIF và Euro NCAP — chứng minh an toàn khi không lái đủ km.

Lớp 1: GNSS/IMU Fusion — Nền Tảng Và Giới Hạn

RTK-GNSS: Ấn Tượng Nhưng Không Đủ

RTK-GNSS (Real-Time Kinematic Global Navigation Satellite System) là phiên bản nâng cao của GPS thông thường. Thay vì dùng một receiver đơn lẻ, RTK kết hợp dữ liệu từ receiver trên xe với một trạm base cố định ở gần, sử dụng sóng mang (carrier phase) thay vì chỉ mã (pseudorange) để đo khoảng cách. Kết quả lý thuyết: độ chính xác 2–3 cm trong điều kiện lý tưởng.

Vấn đề là điều kiện lý tưởng hiếm khi xảy ra trên đường thực tế.

Urban canyon là kẻ thù số một. Khi xe chạy qua các tòa nhà cao tầng ở đô thị, tín hiệu vệ tinh bị che khuất và phản xạ nhiều lần trước khi đến receiver — hiện tượng gọi là multipath. Tín hiệu đến qua đường gián tiếp (NLOS — Non-Line-of-Sight) bị lệch thời gian, khiến receiver tính toán vị trí sai. Trong urban canyon nghiêm trọng, sai số RTK-GNSS có thể vượt 10 m — hoàn toàn vô dụng cho xe tự hành.

Hầm đường bộ còn tệ hơn: không có tín hiệu gì cả. Xe mất hoàn toàn reference từ vệ tinh trong suốt thời gian ở trong hầm. Không có recovery tự nhiên — chỉ có thể đợi đến khi ra khỏi hầm.

IMU: Cầu Nối Nhưng Có Giới Hạn Thời Gian

Inertial Measurement Unit (IMU) đo gia tốc và tốc độ góc thông qua accelerometer và gyroscope. Bằng cách tích phân hai lần (gia tốc → vận tốc → vị trí), IMU có thể ước tính vị trí tương đối từ vị trí đã biết — hoàn toàn không cần tín hiệu ngoài.

Nhưng IMU có một vấn đề chết người: drift. Sai số nhỏ trong phép đo tích lũy theo thời gian. Đối với IMU consumer-grade, drift có thể lên tới 0.5–1% của quãng đường đi. Nghĩa là sau 100 m, vị trí IMU đã lệch 50–100 cm so với thực tế. Sau 1 km trong hầm, sai số có thể đạt 5–10 m.

Mô hình lỗi IMU thường được phân thành hai loại:

• Deterministic errors: bias và scale factor — có thể đo và hiệu chỉnh khi calibrate (một lần khi xuất xưởng)
• Stochastic errors: noise ngẫu nhiên, bias instability, random walk — cần mô hình xác suất, không thể loại bỏ hoàn toàn

Extended Kalman Filter: Kết Hợp Tốt Nhất Của Hai Thế Giới

Giải pháp tiêu chuẩn là GNSS/IMU fusion sử dụng Extended Kalman Filter (EKF). EKF duy trì một trạng thái ước tính (position, velocity, orientation) kèm theo ma trận hiệp phương sai (covariance matrix) biểu diễn mức độ tin cậy.

Hai bước cơ bản của EKF:

Predict step (chạy ở tần số IMU, thường 100–400 Hz):

x̂_k = f(x̂_{k-1}, u_k)    # Tích phân IMU measurements
P_k = F·P_{k-1}·Fᵀ + Q    # Covariance prediction (Q = process noise)

Update step (chạy khi có GNSS, thường 10 Hz):

K = P_k·Hᵀ·(H·P_k·Hᵀ + R)⁻¹   # Kalman gain
x̂_k = x̂_k + K·(z_k - H·x̂_k)  # State update với GNSS measurement z_k
P_k = (I - K·H)·P_k              # Covariance update

Khi GNSS mất tín hiệu (hầm, urban canyon), hệ thống tiếp tục predict bằng IMU, duy trì ước tính vị trí với covariance tăng dần (độ tin cậy giảm dần). Khi GNSS phục hồi, update step kéo ước tính về gần thực tế và reset covariance.

Kết quả: GNSS/IMU fusion thường đạt 10–30 cm độ chính xác trong điều kiện tốt. Nhưng vẫn chưa đủ cho lane-level navigation. Đây là lý do cần lớp thứ hai.

Lớp 2: LiDAR-Based Localization — Định Vị Dưới 5 cm

Ý tưởng cốt lõi: nếu ta có một point cloud map chính xác của môi trường (được thu thập trước và georeferenced), thì có thể so khớp scan LiDAR hiện tại với map đó để tìm vị trí chính xác hơn nhiều so với GNSS.

Quá trình này gọi là scan matching hay map-based localization, và là phương pháp được sử dụng rộng rãi nhất trong xe tự hành production.

NDT: Normal Distribution Transform

NDT (Normal Distribution Transform) là thuật toán scan matching được Autoware và nhiều hệ thống autonomous driving công nghiệp sử dụng. Ý tưởng cơ bản:

1. Chia không gian thành các voxel (ô 3D, thường 1–2 m mỗi chiều)
2. Với mỗi voxel trong map, tính phân phối Gaussian của các point bên trong (mean vector và covariance matrix)
3. Với scan LiDAR mới, tìm rigid transformation (R, t) để tối đa hóa khả năng các điểm scan rơi vào đúng phân phối Gaussian trong map

Hàm tối ưu (dạng negative log-likelihood):

T* = argmin_T  -Σᵢ exp(-½·(x̃ᵢ - μᵢ)ᵀ·Σᵢ⁻¹·(x̃ᵢ - μᵢ))

Trong đó x̃ᵢ = R·xᵢ + t là điểm scan sau khi transform, μᵢ và Σᵢ là mean/covariance của voxel tương ứng trong map.

Tại sao NDT tốt hơn đơn giản chỉ so điểm-điểm? Vì representation Gaussian làm mượt các điểm rời rạc và xử lý tốt hơn với thay đổi môi trường (xe đỗ khác nhau mỗi ngày, cây cối thay lá theo mùa, ánh sáng khác nhau). Map không cần khớp hoàn hảo với reality — Gaussian distribution đủ linh hoạt để handle sự khác biệt nhỏ.

ICP: Iterative Closest Point

ICP là cách tiếp cận trực quan hơn: tìm transformation để tối thiểu hóa khoảng cách trung bình giữa mỗi điểm trong scan và điểm gần nhất trong map.

T* = argmin_T  Σᵢ ||T·xᵢ - yᵢ||²

Trong đó yᵢ là điểm gần nhất trong map với T·xᵢ. Thuật toán lặp xen kẽ giữa bước tìm correspondence (nearest neighbor search) và bước optimize transform (closed-form solution).

ICP đơn giản và hiệu quả khi có initial guess tốt, nhưng nhạy cảm với outliers (điểm dynamic như xe, người) và dễ hội tụ local minima khi môi trường lặp lại (hành lang dài, tường trơn).

Monte Carlo Localization

MCL (Monte Carlo Localization), hay còn gọi là Particle Filter, theo hướng hoàn toàn khác: thay vì tối ưu hóa một pose, MCL duy trì một tập hợp particles (N = 1000–10000 giả thuyết về vị trí xe).

# Mỗi particle = (x, y, theta, weight)
particles = [(x_i, y_i, theta_i, w_i) for i in range(N)]

# Motion update: thêm noise theo chuyển động
particles = [motion_model(p, delta_x, delta_y, delta_theta) for p in particles]

# Sensor update: tính weight dựa trên likelihood của LiDAR scan
particles = [(p[0], p[1], p[2], sensor_model(scan, map, p)) for p in particles]

# Resample: lấy mẫu theo weight
particles = resample(particles)

MCL có ưu điểm độc đáo: xử lý được kidnapped robot problem — khi xe bị dịch chuyển đột ngột (tàu lửa, xe tải), MCL có thể "tái sinh" particles ở vị trí mới nhờ tập phân phối đa mode.

So Sánh Ba Thuật Toán

Benchmark thực tế: Nghiên cứu IEEE ITSC 2019 (Pang et al.) đo NDT đạt MAE 4.06 cm ở tốc độ thấp (5–10 mph) và 5.42 cm ở tốc độ vừa (15–20 mph). Trên dataset highway với map chất lượng cao, Autoware NDT đạt lateral RMSE 1.6 cm, max error 7.6 cm. Đây là con số mà Waymo và Mobileye cite khi nói về LiDAR localization accuracy trong điều kiện tốt.

Xu hướng 2025: NI-LIO (MDPI Electronics, Jan 2025) tích hợp cả ICP và NDT trong một framework LiDAR-Inertial Odometry, đạt accuracy cao hơn thuần túy NDT hay ICP riêng lẻ nhờ kết hợp ưu điểm của cả hai.

Chạy NDT Localization với Autoware.Universe

Autoware.Universe là autonomous driving stack open-source được sử dụng rộng rãi nhất trong nghiên cứu và industry. Đây là cách khởi động NDT localization với sample data:

Bước 1: Setup môi trường (Docker khuyến nghị)

# Clone Autoware
git clone https://github.com/autowarefoundation/autoware.git
cd autoware

# Setup với Docker (bao gồm ROS 2 Humble + tất cả dependencies)
./setup-dev-env.sh docker
source install/setup.bash

Bước 2: Launch NDT Localization

NDT là pose_estimator mặc định của Autoware. Để launch tường minh:

# Launch với NDT làm pose source
ros2 launch autoware_launch autoware.launch.xml \
  map_path:=/path/to/your/map \
  vehicle_model:=sample_vehicle \
  sensor_model:=sample_sensor_kit \
  pose_source:=ndt \
  twist_source:=gyro_odometer

Bước 3: Monitor và đo RMSE lateral error

#!/usr/bin/env python3
"""
Đo RMSE lateral error cho NDT localization.
Yêu cầu: ground truth pose (từ RTK hoặc simulation GT như AWSIM)
"""

import rclpy
from rclpy.node import Node
from nav_msgs.msg import Odometry
import numpy as np
from collections import deque

class LocalizationEvaluator(Node):
    def __init__(self):
        super().__init__('localization_evaluator')

        # Subscribe estimated pose
        self.est_sub = self.create_subscription(
            Odometry,
            '/localization/kinematic_state',
            self.est_callback, 10
        )
        # Subscribe ground truth (từ AWSIM hoặc RTK reference)
        self.gt_sub = self.create_subscription(
            Odometry,
            '/ground_truth/odom',
            self.gt_callback, 10
        )

        self.est_poses = deque(maxlen=1000)
        self.gt_poses = deque(maxlen=1000)
        self.lateral_errors = []

    def est_callback(self, msg):
        t = msg.header.stamp.sec + msg.header.stamp.nanosec * 1e-9
        x = msg.pose.pose.position.x
        y = msg.pose.pose.position.y
        self.est_poses.append((t, x, y))
        self._compute_error()

    def gt_callback(self, msg):
        t = msg.header.stamp.sec + msg.header.stamp.nanosec * 1e-9
        x = msg.pose.pose.position.x
        y = msg.pose.pose.position.y
        self.gt_poses.append((t, x, y))

    def _compute_error(self):
        if not self.est_poses or not self.gt_poses:
            return

        est_t, est_x, est_y = self.est_poses[-1]

        # Tìm GT pose gần nhất về thời gian
        gt_times = np.array([p[0] for p in self.gt_poses])
        closest_idx = np.argmin(np.abs(gt_times - est_t))

        if abs(gt_times[closest_idx] - est_t) > 0.1:  # >100ms threshold -> skip
            return

        _, gt_x, gt_y = self.gt_poses[closest_idx]
        error = np.sqrt((est_x - gt_x)**2 + (est_y - gt_y)**2)
        self.lateral_errors.append(error)

    def print_stats(self):
        if self.lateral_errors:
            errors = np.array(self.lateral_errors)
            self.get_logger().info(
                f"Lateral RMSE: {np.sqrt(np.mean(errors**2))*100:.1f} cm | "
                f"MAE: {np.mean(errors)*100:.1f} cm | "
                f"Max: {np.max(errors)*100:.1f} cm | "
                f"N: {len(errors)}"
            )

def main():
    rclpy.init()
    evaluator = LocalizationEvaluator()
    try:
        rclpy.spin(evaluator)
    except KeyboardInterrupt:
        evaluator.print_stats()
    finally:
        evaluator.destroy_node()
        rclpy.shutdown()

if __name__ == '__main__':
    main()

Kết quả điển hình trên AWSIM (Autoware virtual environment):

Lateral RMSE: 1.8 cm | MAE: 1.4 cm | Max: 4.2 cm | N: 3421

Đây chính xác là cấp độ accuracy mà Waymo và Mobileye yêu cầu cho lane-keeping và trajectory planning. RTK-GNSS đơn độc không bao giờ đạt được con số này trong môi trường urban thực tế.

Lớp 3: HD Map — Bản Đồ Tri Thức Của Xe Tự Hành

Point cloud map (được dùng ở lớp 2) cho xe biết vị trí chính xác. Nhưng xe cũng cần biết ngữ nghĩa của môi trường: làn đường nào được phép đi, tốc độ giới hạn là bao nhiêu, đèn giao thông ở đây kiểm soát ngã tư nào?

Đây là vai trò của HD Map — và nó khác hoàn toàn với Google Maps hay Apple Maps bạn dùng trên điện thoại.

OpenDRIVE: Chuẩn Cho Simulation

OpenDRIVE là format XML được phát triển bởi ASAM (Association for Standardization of Automation and Measuring Systems). Nó mô tả mạng đường thông qua ba lớp:

1. Reference line: đường trung tâm của con đường, được mô tả bằng các đoạn hình học (đường thẳng, cung tròn, Euler spiral/clothoid)
2. Lane section: các làn đường phái sinh từ reference line với offset và width là hàm của chiều dài đường
3. Objects & signals: biển báo, đèn tín hiệu, vật cản — gắn vào đường bằng tọa độ (s, t) theo hệ tham chiếu Frenet

OpenDRIVE mạnh ở simulation: CARLA, SUMO, LGSVL đều dùng OpenDRIVE. Nhưng phức tạp để build và maintain cho fleet thực tế.

Lanelet2: Chuẩn Cho Vận Hành Thực Tế

Lanelet2 được phát triển bởi FZI Research Center (Đức), là chuẩn defacto của Autoware.Universe và nhiều hệ thống production. Nó tổ chức bản đồ theo 6 primitive phân cấp:

Point → LineString → Polygon
                  ↘
                   Lanelet → Area
                            ↘
                             RegulatoryElement

• Point: tọa độ 3D (lat/lon/ele hoặc XYZ) với attributes tùy chọn
• LineString: chuỗi các point, biểu diễn vạch đường, mép vỉa hè, ranh giới làn
• Polygon: vùng khép kín (bãi đỗ xe, vùng cấm xe)
• Lanelet: đơn vị làn đường hữu hướng — xác định bởi left boundary và right boundary (hai LineString)
• Area: vùng không hướng (giao lộ phức tạp, vòng xuyến)
• RegulatoryElement: luật giao thông áp dụng (tốc độ giới hạn, đèn đỏ, biển nhường đường)

Một Lanelet: left boundary (xanh), right boundary (đỏ), centerline được tính tự động (giữa). Nguồn: FZI Research Center / Lanelet2 repo

Bản đồ Lanelet2 của một đoạn đường phức tạp: các lanelets (hữu hướng, màu khác nhau theo hướng đi), giao lộ (area), và regulatory elements (biển báo, đèn). Nguồn: FZI Research Center / Lanelet2 repo

Một ví dụ thực tế tạo Lanelet bằng Lanelet2 Python API:

import lanelet2
from lanelet2.core import Point3d, LineString3d, Lanelet

# Tạo các điểm boundary (x, y, z theo local frame)
left_pts = [
    Point3d(1, 100.0, 0.0, 0.0),   # (id, x, y, z)
    Point3d(2, 200.0, 0.0, 0.0),
]
right_pts = [
    Point3d(3, 100.0, -3.5, 0.0),  # 3.5m bề rộng làn tiêu chuẩn
    Point3d(4, 200.0, -3.5, 0.0),
]

# Tạo LineStrings — type "line_thin" với subtype "dashed" là vạch trắng đứt
left_ls = LineString3d(5, left_pts, {"type": "line_thin", "subtype": "dashed"})
# "solid" = vạch liền — không được đổi làn
right_ls = LineString3d(6, right_pts, {"type": "line_thin", "subtype": "solid"})

# Tạo Lanelet với attributes
ll = Lanelet(7, left_ls, right_ls)
ll.attributes["subtype"] = "road"
ll.attributes["speed_limit"] = "60"    # km/h
ll.attributes["location"] = "urban"

# Centerline được tính tự động từ left + right boundary
centerline = ll.centerline
print(f"Lane length: {lanelet2.geometry.length(centerline):.1f} m")
# Output: Lane length: 100.0 m

# Thêm speed regulatory element
traffic_light = lanelet2.core.TrafficLight(
    [Point3d(8, 200.0, 5.0, 3.0)],   # vị trí cột đèn
    [LineString3d(9, [Point3d(10, 200.0, 0.0, 0.0), Point3d(11, 200.0, -3.5, 0.0)])]  # stop line
)
ll.regulatoryElements.append(traffic_light)

So Sánh OpenDRIVE vs Lanelet2

Hướng Map-Free: MapTR và StreamMapNet

HD Map chất lượng cao rất tốn kém: cần xe mapping chuyên dụng, nhân lực annotate, và quy trình cập nhật liên tục khi đường xây mới, sửa chữa, hay biển báo thay đổi. Chi phí build và maintain HD map cho một thành phố lớn có thể lên tới hàng chục triệu USD.

Hướng nghiên cứu gần đây tập trung vào online map construction — xe tự xây map trực tiếp từ sensor trong thời gian thực, không cần pre-built HD map.

MapTR: Transformer Cho Vector Map Từ Camera

MapTR (ICLR 2023, MapTRv2 trên IJCV 2024) là framework end-to-end sử dụng Vision Transformer để xây dựng vectorized HD map chỉ từ camera surround-view — không cần LiDAR.

Ý tưởng cốt lõi là permutation-equivalent modeling: một yếu tố bản đồ (làn đường, lề đường, vạch kẻ ngang đường) được biểu diễn như một polyline với tập điểm có thứ tự vòng — không có điểm bắt đầu hay kết thúc cố định. Điều này giải quyết sự mơ hồ trong supervised learning: ground truth của một đường cong có thể được annotate bắt đầu từ bất kỳ đầu nào.

Pipeline MapTR: BEV feature extraction → Transformer decoder với map element queries → vectorized map output (lane dividers, pedestrian crossings, road boundaries). Nguồn: hustvl/MapTR repo

Architecture của MapTR:

1. Image backbone + FPN: trích đặc trưng từ 6 camera (front, front-left, front-right, rear, rear-left, rear-right)
2. BEV Encoder: lift image features lên Bird's Eye View (view transformation)
3. Map Decoder: Transformer decoder với learnable map element queries
4. Permutation-equivalent loss: so sánh predicted polyline với GT theo mọi thứ tự hoán vị, lấy minimum

Benchmark trên nuScenes validation (camera-only, IoU threshold 0.5):

MapTRv2 cải thiện thêm bằng cách thêm auxiliary dense segmentation head và instance-level augmentation, đạt mAP 72.2 — gần gấp đôi so với HDMapNet chỉ 2 năm trước.

StreamMapNet: Temporal Modeling Cho Map Ổn Định Hơn

StreamMapNet (WACV 2024) giải quyết vấn đề của MapTR: mỗi frame được xử lý độc lập, khiến map có thể rung (jitter) giữa các frame liên tiếp. Một làn đường lúc thì detect được, lúc thì mất — không ổn định cho planning module phía sau.

StreamMapNet thêm streaming temporal modeling: duy trì BEV feature memory từ các frame trước, dùng multi-point cross-attention để decoder tham chiếu thông tin lịch sử. Kết quả: map ổn định hơn, tầm nhìn xa hơn (map range tăng từ 60 m lên 100 m), và accuracy tổng thể cao hơn.

Frame t-3 → BEV feat ──┐
Frame t-2 → BEV feat ──┼──→ Temporal Memory → Map Decoder → Stable Map
Frame t-1 → BEV feat ──┘         ↑
Frame t   → BEV feat ─────────────┘ (current frame query + temporal context)

Trade-off: Pre-built HD Map vs Online Map

Xu hướng 2025–2026 là hybrid approach: pre-built HD map là primary source khi available, tự động fallback sang online map khi vào vùng chưa được map. Tesla và Waymo đều đang theo hướng này với các tên gọi khác nhau ("Neural Map", "Semantic Map Prediction").

Kiến Trúc Localization Pipeline Hoàn Chỉnh

Kết hợp cả ba lớp, pipeline localization production-grade trong Autoware trông như sau:

GNSS Receiver ──→ gnss_poser ──→ EKF Localizer ──→ ┐
                                       ↑             │
LiDAR Scan ──→ ndt_scan_matcher ───────┘             ├──→ /localization/kinematic_state
IMU ──────────────────────────────────→ EKF Input    │    (pose + covariance + velocity)
                                                     │
Point Cloud Map ──→ map_loader ──────────────────────┘

Lanelet2 Map ──→ map_loader ──→ route_handler ──→ Behavior Planner
                                    ↓
                           Traffic rules, Lane topology
                           Speed limits, Traffic lights

Mỗi component này publish/subscribe theo ROS 2 topics chuẩn của Autoware, làm cho hệ thống modular và có thể swap từng thành phần (thay NDT bằng ICP, thay GNSS bằng V2X positioning) mà không cần thay toàn bộ stack.

Tóm Tắt

Localization là "GPS nâng cao" theo đúng nghĩa — không chỉ biết vị trí mà còn biết vị trí đó với độ chính xác đủ để planning an toàn:

• GNSS/IMU fusion cho nền tảng 10–30 cm, nhưng bị đánh bại bởi urban canyon và hầm
• NDT LiDAR localization thu hẹp xuống còn 1.6–5 cm, là công nghệ core của xe tự hành production hiện tại
• Lanelet2 HD Map cung cấp lớp semantic — làn đường, luật giao thông — mà point cloud map không có
• MapTR/StreamMapNet mở ra khả năng map-free, giảm chi phí nhưng vẫn thua về accuracy so với pre-built map

Trong Bài 5, chúng ta sẽ dùng pose chính xác từ localization và semantic info từ HD map để khám phá Planning & Control — từ route planning trên Lanelet2 graph, đến MPC trajectory optimization, đến control commands gửi đến actuator.

Nếu bạn mới bắt đầu series:

• Bài 1: SAE Automation Levels — Từ L0 đến L5
• Bài 2: Sensor Fusion — LiDAR, Camera, và Radar Kết Hợp Thế Nào?

Bài Viết Liên Quan

• ADAS Fundamentals 2026 — Bài 3: Perception và 3D Object Detection
• ADAS Fundamentals 2026 — Bài 2: Sensor Fusion trong Xe Tự Hành
• Kalman Filter trong Robot Localization: Từ Lý Thuyết đến Thực Tế