Autoware, the world’s leading open-source autonomous driving software stack, enables vehicles to navigate within areas covered by high-definition (HD) maps of the environment. At TIER IV, our research division PFLAB, in collaboration with partner driveblocks GmbH, is developing technology for autonomous driving in environments without maps, which would reduce deployment costs and increase the scalability of Autoware-based systems.
Composite visualization of mapless perception using driveblocks in a TIER IV vehicle. Top: 3D-generated local road corridor map based on sensor input from rooftop-mounted cameras. Bottom: Camera images overlaid with generated local road corridor map.
Autoware-based systems have seen widespread deployment in Japan and around the world, offering an open-source alternative to proprietary autonomous mobility solutions. For deployments, the operating environment must be digitalized by capturing high-definition sensor data and generating HD maps that represent the 3D structure of the area, along with associated mobility related semantic labels. The 3D structure is captured in the form of dense pointcloud maps, which enable the system to localize itself within the environment and determine its position relative to a global reference frame. Navigation goals can be specified in the same global reference frame. Semantic labels are included in a lane-level vector map, providing information about lane geometry and regulatory elements such as speed limits and traffic lights.
This mapping process can be expensive and time-consuming, and must be repeated as the environment changes over time – due to seasonal variations in leaf cover or ongoing construction in built-up areas.
Another related limitation of HD-map-based autonomy is that Autoware systems require an environment with a rich, structured 3D surface for localization. Environments such as tunnels or roads through open fields, where the surroundings are feature-poor, provide few localization cues to the system, making them difficult for Autoware to operate in.
Due to Autoware’s dependence on HD maps of operating environments, scaling Autoware deployments over larger areas is a challenge. One option to overcome these limitations is to move to a mapless architecture, where Autoware can provide autonomous functionality without the need for HD maps. This approach would allow the operating range of Autoware-based systems to be expanded to include:
Because of the deployment flexibility a mapless navigation function would offer, including such a function in Autoware would be advantageous. This article reports on efforts to define and implement a proof-of-concept mapless navigation system for Autoware.
A mapless autonomous system must, in principle, replicate the functionality of a map-based approach. Specifically, it must be capable of localizing itself in relation to its high-level navigation goal, understanding the local traffic scene and planning a route through that scene to reach the goal. However, there are use cases where a map-based system has advantages compared to a mapless one, and vice versa. Therefore, it makes sense to consider a hybrid system that can switch between approaches depending on the use case. Also, designing and implementing a functionally complete mapless system from scratch presents a significant challenge, so simplifying the initial target use case is a sensible approach.
Therefore, rather than define a complete mapless system that can perform autonomous navigation in all environments, as a starting point, we chose to select an appropriate and in-demand use case – autonomous navigation in highway environments. Then we defined a mapless system to operate within this reduced operational design domain (ODD).
In this section, we review the use of HD maps in the current Autoware architecture to determine what information a mapless approach needs to replace. We then examine the specific use cases we aim to cover within the selected highway ODD, and define the corresponding requirements for a mapless system.
Sensing
The sensing component of Autoware interfaces with physical sensor hardware, captures raw sensor data and performs pre-processing to prepare the data for use by the perception and localization components. HD map information is not currently used in Autoware sensing. In the future, it may be used to focus sensor attention – either in hardware or pre-processing – on areas of interest such as roadways, potentially occluded areas and localization-rich 3D features. As it stands, the sensing component does not have any particular requirements for a mapless architecture.
Localization
Autoware performs global localization of the system within a dense 3D point cloud map. This enables the system to get an accurate 6DOF (3D position and 3D attitude) estimate within the point cloud map. As the transform between the point cloud map and the semantic map is known, this gives the system precise information about the location of lane geometry and related traffic regulations.
A secondary function of the localization system is to provide a relative motion estimate of how the vehicle is moving in the local frame, providing accurate estimates of the vehicle’s kinematic state.
A mapless architecture does not have a global map for localization. A state estimation system is needed to measure local motion and provide an estimate of the vehicle’s kinematics at each time step. In a fully mapless system, a source of global position knowledge and localization within the road network is needed, such as using GNSS and IMU to localize within a road-level map (for example, car navigation systems, Google maps, OpenStreetMap).
Perception
Perception in Autoware is limited to the detection and recognition of dynamic objects (vehicles, pedestrians, unmapped objects) in the traffic scene. The perception system relies on the contents of the HD semantic map as a virtual sensor to understand road layout – such as lane boundaries – and traffic regulations – such as speed limits, traffic light positions and which lanes they control. Because perception is computationally expensive, semantic map information can also be used to filter or provide an attentional mechanism for perception algorithms, focusing computational resources on important regions such as near roads and walkways.
A mapless approach requires sensor-based perception of lane boundaries, lane classifications and relationships between lanes (adjacency, traffic direction, overlap/merging, etc). In use cases requiring it, a mapless approach also needs to detect and recognize traffic signs and associate them with the particular roads and lanes they apply to.
Currently in Autoware, the perception of objects is done in a global reference frame, aligned with the HD map. In a mapless architecture, an alternate reference frame (either global or local) needs to be defined for perception.
Planning
Autoware has three levels of decision-making and planning, all of which utilize HD map information in some capacity.
1. Mission/global planning: Defines an overall mission goal (global goal position) and makes a route plan to reach it. Searches the HD map’s lane-level road network for a connecting sequence of lanes from the current position to the goal.
2. Behavior selection: Selects a behavior mode – lane following or free space navigation (parking). The behavior is chosen based on the semantic labels of the current location within the global route.
3. Local planning: Plans a local trajectory to progress along the global route towards the goal. The trajectory should respect the lane geometry provided by the HD map.
In addition to these steps, the system needs to maintain an estimate of position with respect to the local and global paths to decide when the goal is reached and whether the local path needs to be replanned.
The mapless architecture needs to perform these three steps, making use of the limited perceptual information from the mapless perception system:
1. Mission: Define a mission that is not dependent on an HD Map. Define a mission at the local level.
2. Behavior selection: Choose between local behaviors specific to the use case.
3. Local planning: Plan a local trajectory, respecting the lane geometry provided by the perception system.
Control
The primary controllers of Autoware follow trajectories expressed in global coordinates. Given the current estimated location and the reference trajectory, the system calculates control commands to minimize the lateral displacement from the trajectory while advancing toward the goal.
In some cases, HD maps are used to verify that the current position of the vehicle is within the lane boundaries before issuing commands to the vehicle interface.
In theory, a local coordinate system could be used to control the vehicle. However, the implementation requires the reference path to have a consistent frame of reference between cycles of computation, which is achieved by utilizing the global frame of reference. A mapless architecture would have to mimic this fixed frame of reference over the reference trajectory, or implement a control method that does not rely on it.
For a simplified highway ODD, we define three use cases to be addressed in the mapless architecture proposal. The use cases are local behaviors and do not require a global road network or position estimate. Specifically, we would like to perform the following highway-based actions.
On highways, vehicle speeds can reach 100 km/h, so perception and lane modeling capabilities must extend far enough to enable safe planning at that speed. In Autoware, the current planning system requires the system to be able to decelerate to a full stop within the current planning horizon. For the highway use case, we overlook this requirement.
ℹ️ The implementation is for left-hand traffic, consistent with Japanese road rules.
In addition, we assume a simple highway road structure with 2-4 lanes in each direction and a division between road directions. As a result, the system does not have to perceive the direction of lane travel.
Based on the above discussion, we can identify the requirements for the three highway use cases as follows.
Perception
Localization
Provide a relative position estimate of local motion (in any coordinate frame, sufficient to calculate relative motion between time steps).
Planning
Define and execute local missions in a local reference frame reflecting the use cases: Lane following, lane change and off-ramp.
Control
Follow the planned local trajectory in a local reference frame.
Here, we detail the proposal of a mapless autonomy architecture for Autoware based on the requirements outlined above. The architecture describes the node structure of the computation flow and the message-passing interfaces between each computation node. It is organized into three categories: Nodes to be developed or adapted from the current implementation; nodes that can be reused from the current implementation; and nodes that should be implemented in the future (but are beyond the scope of a simple proof of concept).
In the following diagram, we show the proposed software architecture. From top to bottom, the figure includes the following computation nodes and message definitions:
In operation, the data flow within the mapless architecture would go from the goal information source to the control output. The global goal can be identified algorithmically by a goal planner or, in this case, set by the safety driver via the Autoware HMI. The safety driver could initiate a certain behavior by setting a ROS mission parameter (given in the table below, first column) via the terminal or a GUI, which is then converted into a local goal message of type autoware_auto_planning_msgs::msg::LocalMission. For example, the safety driver could initiate the missions lane_keeping, lane_change, or take_next_exit.
Local mission planner
For each mission type, a set of rules is defined to select the target and drivable lanes, defined in the message type autoware_auto_planning_msgs::msg::MissionLanes, from the local road model.
If a local mission does not have a clear interpretation within the available local road model, we propose continuing with the currently active mission type or postponing the request for a maximum distance of a few hundred meters. An example of a situation where a postponement is required is a mission request to stop on the shoulder lane when no such lane is available.
Local behavior planner
Based on the MissionLanes, the behavior planner computes a collision-free trajectory that allows the ego vehicle to follow or switch to the target lane while adhering to the constraints imposed by the deadline parameter, drivable lanes, and surrounding objects. The trajectory may cross drivable lanes if necessary – for example, to avoid an obstacle or cross multiple lanes.
The proposed architecture was implemented in a proof-of-concept test on TIER IV’s autonomous vehicle platform. The mapless perception module, which generates the road corridor model from current sensor data, is provided by our development partner, driveblocks. While this is a proprietary solution, driveblocks plans to release example output data from their model. This will allow for testing of the open-source architecture design and the Autoware proof-of-concept implementation.
The source code and configuration files for the proof-of-concept implementation, along with instructions and an example launch file, are available on GitHub.
The local road corridor model and other perception modules are available for licensing from driveblocks.
To assess the proof-of-concept implementation, we conducted experiments to confirm the open- and closed-loop behavior of the mapless architecture.
Open loop: We manually drove an Autoware-installed vehicle on a public highway in Japan, performing mapless perception and planning. The vehicle did not operate in autonomous mode. An example of mapless perception and road corridor modeling at highway speeds can be seen in this video.
Closed loop: We also confirmed the use of the mapless architecture in a closed-loop experiment on a private test track, where the generated trajectories were used to control the vehicle in autonomous mode. Unfortunately, video from the test track is restricted. The following experiments were confirmed on a three-lane, 300-meter straight test track at low speeds (maximum 20 km/h).
The first two issues highlight the sensitivity of a mapless architecture when planning in a local reference frame based on local data – both of which are inherently uncertain. These issues, particularly the limited perception range, are expected to be resolved through a combination of an enhanced sensor setup and continuous evolution of the algorithms.
The driveblocks perception module allows for a plug-and-play method to generate representations of the local road network. This enabled Autoware to perform limited mapless navigation in highway-like environments with minimal changes.
In the future, merging information from local road models with global maps – such as OpenStreetMap or HD maps – will become increasingly important. Navigation data could be fused with local, sensor-based road models, combining the advantages of both – global navigation knowledge and local context. A global navigation information source, together with an advanced local behavior planner, enables the system to operate without human mission input. Additionally, exploring supplementary sources like street sign detectors can further enrich the information pool, facilitating comprehensive decision-making processes. As stated in the introduction, the mapless architecture is intended to function as a separate planning component. Our ultimate vision involves combining this component into a single architecture with the existing Autoware modules to seamlessly transition from HD to local maps, or combining both into a single environment representation.
About the authors
Simon Thompson | PFLAB
Simon is the coordinator of external research projects at TIER IV and team lead of PFLAB. He spent 19 years at the National Institute of Advanced Industrial Science and Technology (AIST) in Japan studying all aspects of navigation for autonomous systems, from localization and mapping to planning and control. In 2014, he was a joint recipient of the RSJ Technical Innovation Award for his work on automating forklifts to remove radioactive debris from the site of a damaged nuclear reactor.
Maxime Clement | Planning and Control Team
After researching multi-agent optimization for his PhD at the National Institute of Informatics of Japan, Maxime switched to industry, joining TIER IV in 2021. Working with the Planning and Control team, he focuses on improving the planning capabilities of Autoware and takes part in collaborations with other members of the Autoware Foundation.
TIER IV is always on the lookout for passionate individuals to join our journey. If you share our vision of making autonomous driving accessible to all, get in touch.
Visit our careers page to view all job openings.
If you’re uncertain about which roles align best with your experience, or if the current job openings don’t quite match your preferences, register your interest here. We’ll get in touch if a role that matches your experience becomes available, and schedule an informal interview.
Inquiries
Social Media
X (Japan/Global) | LinkedIn | Facebook | Instagram | YouTube
More