Lightweight Solution to Generate Accurate Lanelet Maps ^†

Abstract

As automated driving technologies become more mature, there is an increasing reliance on digital maps to support safe and efficient driving. Sensors like cameras and radars can be limited by occlusions, lighting conditions, or weather, and often fall short. High-definition (HD) maps offer excellent accuracy, but they are expensive to produce. These limitations make these techniques impractical for large-scale deployment. What makes our approach particularly attractive is its hardware simplicity: the entire process requires only a precise GNSS receiver and a commonly available lane detection camera, eliminating the need for expensive sensors like LiDAR or complex multi-vehicle fleets. We rigorously evaluated our method in a highway environment, where a vehicle equipped with our generated maps successfully executed autonomous lane following and adapted its speed based on detected speed limit signs. The positional deviation of the resulting maps was consistently under 5 cm.

1. Introduction

High-definition (HD) maps have become a cornerstone of automated driving technologies, particularly for vehicles operating at SAE Level 3 and above [1]. These maps offer a detailed, structured view of a driving environment that goes well beyond what onboard sensors can perceive in real time [2]. As vehicles are expected to perform increasingly complex driving tasks—such as hands-free highway cruising or active lane-keeping under varied conditions—map data becomes an unavoidable part of the systems that provides essential support. Among the various map formats available today, lanelet maps are widely adopted in academic and industrial applications due to their modular structure and strong compatibility with routing, planning, and regulatory feature layers [3,4]. They have been used in a range of domains, from simulation and behavior planning to real-world deployment [5,6,7]. Additionally, there has been meaningful progress in adjacent areas such as map validation and automated lane modeling, and several open-source or partially open-source pipelines have emerged in recent years [8,9]. These developments have helped push the field forward, offering a foundation for map-based functionality in both prototyping and production environments. However, despite these advances, many of the current solutions are still constrained by several critical shortcomings. Most notably, many pipelines are not optimized for lightweight deployment. They rely heavily on expensive hardware like LiDAR or multi-sensor fusion setups, which limits scalability and affordability [7]. Furthermore, some approaches underperform in terms of the accuracy required for precise vehicle control. As a result, there is a growing need for solutions that strike a better balance between precision, cost, and ease of integration. In this research, we aim to address these gaps by developing a lightweight yet accurate toolchain for generating lanelet-format HD maps using minimal hardware. The main contributions of our work are as follows:

C1

In contrast to existing, complex solutions, our proposed method relies only on a high-precision GNSS receiver and a lane detection camera configuration that is already present in many modern vehicles. This makes the integration and usage of our method easy.

C2

Our generated maps only contain minimal information for vehicle control (i.e., lanes and traffic rules); therefore their real-time usage is possible, while their lane position precision is remarkable, further enhancing the applicability of this solution.

The process is divided into three main phases. In the pre-processing stage, we use MATLAB (2024b) to manually annotate reference lane lines from recorded data. This step helps anchor the rest of the pipeline to a reliable baseline. In the refinement phase, these references are further improved by aligning multiple measurements, increasing geometric accuracy across the map. Finally, the map generation step compiles the processed data into lanelet-format files using the official Python (3.10) API provided by the Lanelet2 library [8]. The usability of our generated maps has been demonstrated in a highway lane following a scenario with a real vehicle. This serves as a proof-of-concept for the broader application of our approach and highlights its potential for scalable and real-world deployment.

2. Materials and Methods

2.1. Data Collection

The first and arguably most critical step in the HD map generation pipeline is the collection of high-quality raw data. This step underpins the entire mapping process by establishing the geometric and spatial basis for the maps. Our approach to data collection was intentionally designed to balance practicality with technical precision: we used minimal sensor hardware that is readily available in production-level systems, while still achieving the accuracy required for advanced automated driving applications. The collected data served as the foundation for generating lightweight yet reliable lanelet-format maps. Our data acquisition efforts were focused on highways and rural roads, as these road types present structured but sufficiently variable environments. Highways offer well-defined lanes, consistent signage, and no pedestrian interaction—making them ideal for the initial development and validation of autonomous functionalities. The sensor setup employed during the data collection phase consisted of just two components: a high-precision GNSS receiver and a camera-based lane detection system. The GNSS unit is a Genesys ADMA Gen3 device [10], which was responsible for tracking the global position of the vehicle throughout each run. To ensure a positional accuracy adequate for HD map creation, we used a differential GNSS configuration capable of centimeter-level precision. The GNSS data was collected at a high rate and synchronized with camera readings to maintain spatial and temporal coherence. To maintain precise localization throughout the whole measurement, we used a Kalman filter to fuse vehicle odometry with the live GNSS position. For detecting lane boundaries, we used the Bosch MPC 2.5 camera [11], a production-grade forward-facing sensor designed for ADAS applications. This camera can detect both left and right lane markings in a variety of road conditions, and outputs structured lane line data in real time. This edge device is also capable of enhancing its measurements using the vehicle’s odometry. It represents a realistic choice for real-world deployment, as similar sensors are already integrated into many modern passenger vehicles. The output of the camera includes the detected lane edges given by their position, orientation, and curvature in the vehicle coordinate frame (1), shown in Figure 1. The GNSS system measures the pose of the vehicle in the global UTM frame (2), also illustrated in Figure 1. It should be noted that the lane edge information (1) is measured separately for the left and right edges of the lane, but they are supposed to be parallel, therefore their orientation and curvature are assumed to be the same. This is a production concept of the used camera and its corresponding software component.

$$l^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}(t)={\left[\begin{array}{ccc}{d}_y^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}& \theta & \kappa \end{array}\right]}^T$$

(1)

$$\rho (t)={\left[\begin{array}{ccc}X& Y& \Psi \end{array}\right]}^T$$

(2)

During each data collection session, sensor readings were logged and stored in CSV format, which included synchronized entries for time, detected lane edge geometries $l^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}\left(t\right),$ and global pose $\mathit{\rho }\left(t\right)$. This format enabled the easy inspection and preliminary filtering of the data. However, for more structured analysis and processing, we converted the raw CSV data into MATLAB ‘.mat’ files, which served as the working format throughout the pre-processing phase. The development data was collected at ZalaZONE test track, Hungary, in the motorway section, illustrated in Figure 2. The motorway segment is a built highway environment, with a long straight section and one curved section, with a total length of approximately 1.5 km.

2.2. Pre-Processing Phase

Each file contains two primary datasets: a time series of the vehicle pose, and a time series of the lane geometry information for the left and right lane edges. In order to apply physical calculations on the lane markings, the curve parameters of (1) are transformed to lane points. This is possible as the position of each measured lane point is implicitly given in (1), as the lane distance from the vehicle $d_y^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}$ equally qualifies as the $y$ coordinate of the given point in the vehicle coordinate frame $x-y$. Supposing a sample measuring time of $T_s$, (1) and (2) are discretized via measuring their samples. Thus, at sample time $k{T}_s$, where $k\in \mathbb{N},$ the lane edge point position, given in the vehicle coordinate frame, can be calculated (3).

$$p_k^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}\left(k{T}_s\right)\equiv p_k^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}={\left[\begin{array}{ccc}0& d_{y,k}^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}& {\theta }_k\end{array}\right]}^T={\left[\begin{array}{ccc}0& y_k^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}& {\theta }_k\end{array} \right]}^T$$

(3)

Based on (2–3), the global lane edge point position can be calculated (4).

$$P_k^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}=p_k^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}{T}_k+{\rho }_k$$

(4)

where $P_k^{\mathrm{l}\mathrm{e}\mathrm{f}\mathrm{t},\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}}$ is the global lane edge point pose at the $k^{\mathrm{t}\mathrm{h}}$ sample, and $T_k$ is the rotational matrix (5).

$$T_k=\left[\begin{array}{ccc}\cos \left({\Psi }_k\right)& \sin \left({\Psi }_k\right)& 0\\ -\sin \left({\Psi }_k\right)& \cos \left({\Psi }_k\right)& 0\\ 0& 0& 1\end{array}\right]$$

(5)

The pre-processing stage requires the manual annotation of the measurement metadata, namely the road and lane identification in the global map. Following manual annotation, we perform a refinement phase in which data from multiple passes over the same road segments are integrated. This allows for the statistical filtering and averaging of repeated measurements, effectively smoothing out noise and improving the overall positional stability of the detected lane features. Given the vectors formulated from (4), the points of the same lanes are concatenated (6).

$$\begin{array}{c}{P}^{lID-i}=\mathrm{c}\mathrm{o}\mathrm{l}(P_k^{lID-i})\\ P^{lID}=\mathrm{c}\mathrm{o}\mathrm{l}(P^{lID-i})\end{array}$$

(6)

Then, the lane edge line is divided into smaller sections, where a transformation is possible, after which the local longitudinal coordinate is strictly monotonically increasing (7).

$$P_j^{lID}=P^{lID}[\left(j-1\right)N:jN,:]$$

(7)

where $j,N\in \mathbb{N}$, and $N$ are hyper parameters which define the length of the snippets. Choosing a low value of $N$ guarantees the strictly monotonically increasing coordinates, but regression may fail or become unstable. Too high a value of $N$ may result in non-monotonically increasing longitudinal coordinates but regression would be stable. The snippet points are transformed to a quasi-local coordinate frame, providing the strictly monotonically increasing coordinates (8).

$$\begin{array}{c}{\tilde{P}}_j^{lID}=\left(P_j^{lID}-P_j^{lID}\left[\mathrm{0,1}:2\right]\right){\tilde{T}}_j^{lID}\\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}{\tilde{T}}_j^{lID}=\left[\begin{array}{ccc}\cos \left(P_j^{lID}\left[\mathrm{0,3}\right]\right)& -\sin \left(P_j^{lID}\left[\mathrm{0,3}\right]\right)& 0\\ \sin \left(P_j^{lID}\left[\mathrm{0,3}\right]\right)& \cos \left(P_j^{lID}\left[\mathrm{0,3}\right]\right)& 0\\ 0& 0& 1\end{array}\right]\end{array}$$

(8)

Using the quasi-local path points (8), polyline regression is applied, fitting a polynomial curve onto the snippet points (9).

$$\begin{array}{c}{y}_j^{lID}=c_{j0}^{lID}+c_{j1}^{lID}{x}_j^{lID}+c_{j2}^{lID}{\left(x_j^{lID}\right)}^2+\cdots +c_{jn}^{lID}{\left(x_j^{lID}\right)}^n\\ c_j^{lID}=g(P_j^{lID},n)\end{array}$$

(9)

where $[x_j^{lID} y_j^{lID}]$ are the fitted polyline points of snippet $j$, and $n$ is the order of the polynomial.

2.3. Post-Processing Phase

The result of the pre-processing is a robust set of lane edge points that can serve as reliable inputs for map construction. The idea is to collect all available detections within a spatial bounding box, typically sized at approximately 100 m in length and 20 m in width and compute a refined lane line by fitting a polyline on the collected data points, as introduced in Section 2. When repeated over the entire route, this method allows us to generate a comprehensive and continuous map of lane boundaries with a high positional accuracy. This refinement loop is repeated until all mappable segments are processed, ensuring consistent quality across the entire dataset. The output of this phase is a structured set of cleaned lane line points, which can now serve as the input for the HD map generation phase. To produce a usable map in a standard, machine-readable format, we utilize the Lanelet2 Python API [2], a widely adopted open-source library for HD map creation and manipulation.

3. Results

The results are generated using self-developed MATLAB scripts that accumulate and average lane line data from repeated passes over the same location. Our pipeline converts the processed lane line data into Lanelet2 map files by defining individual lanelet primitives, which include left and right lane boundaries, regulatory elements (e.g., speed limits), and lane centerlines, as illustrated in Figure 3.

The absolute fit error between the fitted polylines and the measured lane points is calculated (10) for all measured points for the centerlines of the two lanes shown in Figure 3b. Using the error vectors, statistics are calculated, namely the mean absolute fit error and the standard deviation of the error [12,13]. The results are shown in Figure 4. The mean absolute fit error is below 3 cm for both centerlines, as well as the standard deviation. This means that 95% of the measured lane points are within 2 +/− 5 cm proximity of the fitted centerline. This result proves that the fitted centerline can be used for vehicle control purposes, as most modern controllers can provide a tracking accuracy up to +/− 20 cm.

$$e_j^{lID}=|{\tilde{P}}_j^{lID}\left[:,2\right]-y_j^{lID}|$$

(10)

The generated map can be directly used in downstream modules such as motion planning or trajectory tracking. The resulting map is then integrated into our autonomous driving framework and used to replace traditional, real-time lane detection systems in test environments. By using the generated Lanelet2 maps [14], we can guide the vehicle along centerlines with improved stability and foresight, overcoming the inherent limitations of real-time perception methods that may fail under suboptimal conditions. The map-based control significantly improves lane-keeping performance, particularly in scenarios involving curves, occluded markings, or inconsistent road paint. The maps used in the autonomous chain are illustrated in Figure 5.

4. Conclusions

In our work, we represented a way of generating Lanelet2 maps and refining them over time. Throughout the development we have acquired measurement data from different routes and environments. With future developments in mind, we will try to unify the generation pipeline into a Python-only solution. Also, in some environments, mainly in rural and country roads with harsh turns, the pipeline could not generate usable maps, and this is definitely something we would like to fix in future developments. These automatically generated maps can be used in ADAS features such as in Active Lane Assist, SCC (Smart Cruise Control), and later also in Level 3 functions and beyond. In comparison to traditional HD maps, we believe our solution could be scaled easily and provide a more up-to-date map compared with the use of HD mapping equipment.