The public account is dedicated to sharing content related to point cloud processing, SLAM, three-dimensional vision, high-precision maps and other fields. Everyone is welcome to join. If you are interested, please contact [email protected]. Please do not reprint without the author's permission. All students are welcome to actively share and communicate.
Background introduction
In the automotive industry, AUTOSAR is an international consortium of automotive original equipment manufacturers (OEMs), suppliers and other industry members. They released the first reference architecture AUTOSAR Classic in 2003. Its focus is not on being independent of the underlying Dynamic application of hardware, but with the increasing importance of SOA and autonomous driving, the second standard Adaptive AUTOSAR released in 2018 addresses these needs.
However, the automotive industry is not the first to face a shift towards dynamic and flexible communication models. A similar evolution is taking place in the context of physical systems and robotics. In this context, the widely used ROS1 (a set of open source (Library and toolset for software architecture development) cannot meet the needs of real-time, security and cross-platform interoperability. Its successor ROS2 solves these shortcomings and implements service-oriented communication. ROS2 is widely used in research environments for software packaging and communication, and has also found applications in the context of automotive electrical/electronic architecture. There are now even certified solutions that meet the functional safety standard (ISO26262) and the necessary Automotive Safety Integrity Level (ASIL) for electrical and/or electronic systems, regarding ADAS functionality and service-oriented architecture in the context of highly connected vehicles (SOAs), there are still many issues to be resolved.
In this context, this article combines the following two documents:
Jacqueline Henle， Martin Stoffel. Architecture platforms for future vehicles: a comparison of ROS2 and Adaptive AUTOSAR
Apex.AI report :Adaptive Autosar and ROS 2
ROS2 and Adaptive AUTOSAR are compared and their adaptability in automotive electrical/electronic architecture is studied as shown in the figure:
Comparing the similarities and differences of ROS2 based on the Adaptive AUTOSAR standardized architecture, the following comparison aims to identify their advantages and disadvantages, the reasons for using the standard and their suitability for future-ready electrical/electronic architectures in modern vehicles.
Preface
The key difference between the adaptive AUTOSAR specification and ROS2 is that ROS2 adopts the "code first, then standardize" method , because ROS has been used and verified in the field of robotics for 12 years. The adaptive AUTOSAR part is written from scratch, and part adopts Based on proven technologies such as SOME/IP3, DLT4 and UDS5, Adaptive AUTOSAR follows a "specify first, then generate code" approach .
ROS2 excels in terms of large communities and tools for data logging, playback, visualization and debugging. It can also be bundled with other languages such as Python and Java. ROS2 leverages common open source tools rather than individual adaptive AUTOSARs. Tools provided by the vendor, so the user base is smaller, Adaptive AUTOSAR uses service-oriented SOME/IP, while ROS2 uses data-oriented DDS, the former can only switch between UDP and TCP, while the latter has QoS (Quality of Service ). Due to the presence of DDS, data transfer in ROS2 is very efficient and fast, thanks to shared memory (SHM) and zero-copy implementation.
ROS2 version F was released in June 2020 as the second long-term support version. It is currently unclear the progress of individual adaptive AUTOSAR implementations and whether they are based on the latest specification (19.03). It is understood that most implementations are based on the 18.03 specification. . On the other hand, the adaptive AUTOSAR specification is superior to ROS2 in terms of software update and configuration management and DEXT diagnostic management. Both technologies have benefits and challenges in modern C++. The biggest challenges include:
1. Standard exception handling
2. Static containers (strings, vectors, mappings)
3. Memory management
The best summary for now is: Adaptive AUTOSAR excels at compatibility with existing in-vehicle infrastructure, while ROS2 excels at application development, and ideally both technologies can coexist in production.
What is ROS2
The ROS framework is a collection of software tools, libraries, protocols, and APIs designed to simplify the task of developing software for complex multi-sensor, multi-actuator systems. In most cases, the use of robotics frameworks determines the general architectural principles for developing software. For example, whether the software is centralized or decentralized, real-time or non-real-time, etc., the key component is middleware, which is the key to gluing together the many components of the robot framework. The most basic task of middleware is to provide software nodes in autonomous vehicles. communication infrastructure. A typical use case for the ROS framework is to provide a basic interface between the upper-level (software) and lower-level (hardware) components of the system. These interfaces and components include various operating system (OS)-specific drivers, which can take a long time to be developed by a single developer. Developed primarily by Open Robotics and the ROS2 Technical Steering Committee, ROS2 has thousands of users and is used by hundreds of autonomous driving and robotics companies. The architecture of ROS2 is shown in the figure below:
What is Adaptive AUTOSAR
Adaptive AUTOSAR is an officially defined term that describes it as “AUTOSAR Runtime for Adaptive Applications (ARA). Providing two types of interfaces, services and APIs, the platform consists of functional clusters that They are also grouped in services and form the basis of adaptive AUTOSAR". In fact, it is another robotics framework consisting of functional clusters called: The specification of this framework was developed by the Autosar consortium. The actual implementation is then carried out by companies such as Elektrobit, Vector, ETAS, Mathworks, Aubass, etc. The development work is done by consortium members, only the specification is released publicly, Adaptive Autosar is based on the classic Autosar for programming applications on single-core microcontrollers.
Service-oriented architecture and its impact on architectural platforms
A car's electronic/electrical (E/E) architecture as a system includes software (SW) and hardware (HW) components as well as mechanical components. The traditional distributed architecture is characterized by HW and SW being tightly coupled on many electronic control units (ECUs). In contrast, service-oriented architecture makes application software and execution hardware independent of each other. In order to achieve this loosely coupled architecture, the operating system (OS) and middleware play a key role. The middleware layer is mainly responsible for communication between ECUs. Therefore, the requirements for middleware include the execution of abstracted and virtualized communication within the entire vehicle architecture or with the cloud and back-end infrastructure. Communication between these system components is very important during system development. The period may be unknown. Therefore, in connected systems, communication is dynamic and links need to be established flexibly at runtime. The large amounts of data generated in connected vehicles and service-oriented architecture have led to new protocols in E/E architecture. integration in . As an automotive reference architecture for dynamic communications specified in the Adaptive AUTOSAR specification, functional applications and a POSIX-compliant operating system are separated from a modular layer called the Adaptive Application Runtime Environment (ARA). See picture below.
The structure of adaptive AUTOSAR
In ARA, interfaces and services are defined to specify operating system access and a communication middleware to implement a service-oriented architecture based on Ethernet. In the first version of Adaptive AUTOSAR, the extensible service-oriented IP middleware (SOME/IP) was specified as the middleware protocol for the corresponding standardized architecture. In addition to automotive-oriented middleware solutions, DDS is a non-car-specific alternative. Adaptive AUTOSAR includes DDS starting from version 18-10, while ROS2 is built on DDS from the beginning and provides no other middleware. The integration of DDS is an example of a non-industry-specific middleware solution enriching the automotive standard Adaptive AUTOSAR.
The structure of ROS2
Parallel to this development, ROS2, originating from robotics applications, entered the automotive industry. In contrast to Adaptive AUTOSAR, ROS2 is open source and requires no membership or licensing fees. Untuned implementations provided by the ROS community are not officially certified. , not suitable for real-time applications in vehicle systems . However, recently commercial real-time operating systems (RTOS) based on ROS2 developed by automotive software companies have been certified for ASIL-D applications. Motivated by these developments, we conducted a comparison of ROS2's architecture with an adaptive AUTOSAR-based modular structure. The following comparison is made.
Adaptive AUTOSAR and ROS2 provide a hierarchy that separates execution hardware and applications. Comparing the overall structure of these platforms, it can be seen that the naming of the Adaptive AUTOSAR application programming interface (API) gives an impression of the intended functionality of ROS2. Hierarchies are not easy to interpret to the same extent, so we need to compare the scope and content of ROS2's Client Library and Abstract DDS Layer with the adaptive AUTOSAR architecture. Since Adaptive AUTOSAR is a standard in the automotive industry, we wanted to evaluate the applicability of ROS2 in this industry and will compare the two platforms based on the functionality and core advantages of Adaptive AUTOSAR. The core of the adaptive AUTOSAR architecture is the ARA including the adaptive API provided by the feature set. Feature sets are classified as Adaptive Platform Foundation or Adaptive Platform Services, which provide APIs for accessing ARA and intra-platform applications. They describe the behavior of the software platform from an application and network perspective but do not further specify the software design. Adaptive Applications can provide services to each other or interact with non-platform services.
Adaptive AUTOSAR architecture and ROS2 differences
Communication Management
In Adaptive AUTOSAR, the communication and information sharing of applications is organized by the Communication Management (CM) API package. In this way, service-oriented communication between the various levels of the platform is implemented and monitored. CM also provides intra-machine and inter-machine communication. . The API specifies SOME/IP as the middleware protocol implemented, and DDS was added in version 18-10. While DDS and SOME/IP share common characteristics, there are key differences.
SOME/IP implements object-based service-oriented communication. The subscriber's service class needs to be pre-defined during the development process and is therefore static to a certain extent. In contrast, DDS operates dynamically through the sender and receiver. Time discovery implements dynamic runtime discovery and provides more interoperability and flexibility since static service specifications are not required. DDS implements publish-subscribe functionality based on the Real-Time Transport Protocol (RTPS) and leverages this transport protocol by providing advanced data management capabilities. Additionally, other protocols can be added. In SOME/IP, publishing information can be broadcast to all subscribers by using User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). Event-driven communication in SOME/IP can provide a current snapshot of data, and field-based communication can transfer data with read and write permissions and receiver data history. Another feature is method-based remote procedure call (RPC), which enables the client to launch a specific function on request and return a message with data. DDS defines three communication methods: a message can be sent to a subscriber based on its topic, or the client can call a service and deliver it to the recipient. The third mode combines the two approaches: a target is published, triggering feedback that is periodically sent to the recipient.
In Adaptive AUTOSAR, communication paths and service definitions can be established dynamically during development, at system startup, or at runtime. Additionally, Adaptive AUTOSAR specifies signal-based network binding to allow the transformation of corresponding communication applications into service-oriented communication applications.
ROS2 defines a middleware API named rmw to enable application-agnostic integration of DDS combined with RTPS. As the only middleware framework solution, both Adaptive AUTOSAR and ROS2 provide zero-copy capabilities and are widely used in the automotive industry. Standardized inter-process communication . Furthermore, communication in ROS2 is organized through nodes, each node provides a function to the system, publish-subscribe communication is implemented in a decentralized manner, and the nodes discover each other without an intermediate master node, unlike adaptive AUTOSAR, Nodes in ROS2 need to be integrated at design time, but service discovery only happens at runtime. This is a key difference between the two platforms, adaptive AUTOSAR's CM enables reduced overhead where dynamic communication is not required.
Execution Management
APIs in Adaptive AUTOSAR implement functions related to platform and application lifecycle management, including authentication, startup and shutdown of applications, EM interacts with the operating system, and schedules applications at runtime, so applications can Organized by priority, the execution checklist specifies other topics related to EM. It clearly defines the possibility to statically set up resources for a specific application, as well as to control resource allocation through communication.
Execution management in ROS2 is organized through the launch file in the rcl API. Execution is implemented through executors (Executors). This concept is based on using operating system threads to implement callback functions, execution timers, service servers, and action servers. , to handle incoming messages and events. While ROS2's standard executor does not guarantee determinism, it can be tweaked and optimized to achieve this goal, however such tweaks are currently only found in commercial solutions based on ROS2 and are not part of the standard open source implementation. In addition, other real-time and efficiency issues arise when using ROS2 standard actuators, so it seems that there is still room for further improvement in meeting the requirements of the automotive industry.
Core Type
The core type API package defines the basic requirements applicable to all functional clusters of the adaptive platform. It contains a central initialization function for initializing all shared libraries included in the ARA layer. It is recommended to call this function for each adaptive application as Entry Point, Furthermore, it describes error handling and distinguishes between errors, violations, and corruptions. Errors are the return values of adaptive functions and are usually caused by input data. A violation refers to an internal state of the adaptive platform that cannot be recovered. Corruption is the result of corruption of system resources such as the stack, heap, or hardware. For application developers, errors are only expected because violations or corruption may indicate serious problems in the system environment, such as faulty hardware. In addition, the core type API defines data types commonly used in adaptive platforms, the platform type package describes standard types such as integer, double precision float, or float, and the core type package defines data types such as arrays and vectors. Additionally, it defines the return data type in the event of an exception or error.
Similar to adaptive AUTOSAR, ROS2's client library clcpp needs to be initialized first. The client library also contains incorrect definitions, such as invalid node or topic names, incorrect function parameters, or runtime errors. However, a clear separation between errors, violations, or corruption is not explicitly described. Therefore, there is no way to determine which error caused the entire process to abort or throw an exception.
ROS2 applications usually communicate through interfaces, which can be messages, services or operations. The interface contains multiple fields. Each field has a field type and field name. Built-in field types include Boolean, integer, character, floating point, Double-precision floating point numbers and strings, which can be used to define static, bounded or unbounded dynamic arrays, or bounded strings, and combinations of these types can be used to create custom messages, similar to adaptive AUTOSAR in this regard.
Representational State Transfer（RESTful）
While the CM API package covers service-oriented communication between adaptive applications, the Representational State Transfer (RESTful) API package provides web service-based communication options, unlike RESTful services in the mobile domain which do not often expose resource constraints , which needs to be optimized for automotive applications to provide low latency and deterministic memory and processing times. The APIs in the CM package are precisely defined at the byte level, so most of them deal with static data. RESTful APIs usually deal with dynamic data in asynchronous processing, combined with Uniform Resource Identifiers (URIs). In terms of implementing RESTful API, there is currently no dedicated package for ROS2. However, for ROS versions Indigo or Kinetic, a package called ROSTful exists, and we cannot predict if and when we will be able to port it as a ROS2 package. Another alternative to implement asynchronous data processing in ROS2 is to use an Action. The client can call the Action, similar to a remote procedure call, and pass multiple data parameters. The Action then processes the data and executes a callback when completed, although the Action Similar to the RESTful API in Adaptive AUTOSAR, but they are not exactly the same, and ROS2 does not fully meet the characteristics of the RESTful API.
Persistency
Adaptive AUTOSAR explicitly specifies persistence of information after startup and ignition, in addition to using volatile storage. On the other hand, ROS2 is limited by the underlying DDS implementation in terms of data persistence. Cyclone DDS states that transient and persistent memory will not be used before version 0.9. The current version 0.8.2 only supports volatile storage of data, so It can be considered that it partially meets the requirements of Adaptive AUTOSAR persistence functionality.
Time-Synchronisation
In terms of time synchronization, both Adaptive AUTOSAR and ROS2 adopt a similar approach. In Adaptive AUTOSAR, the master clock and the slave clock are synchronized, usually using the Network Time Protocol (NTP) for synchronization, but the Precision Time Protocol (PTP) is a higher Alternative for accuracy, in ROS2 messages can also be synchronized with each other and with different clocks to choose from, the same PTP is the solution to achieve the highest accuracy.
Platform Health Management
Adaptive AUTOSAR monitors the time constraints, logical program flow and platform status of its application. When an error is detected, it notifies the status management module, which determines the error handling method. In addition, the platform health management interacts with the hardware watchdog. A watchdog response can be triggered in the event of a critical fault, but merely notifying the status management module is not sufficient. However, the interface between platform health management and other functional clusters is only of informational nature and is not standardized. In ROS2, these features are not implemented by default. However, according to the open source documentation of ROS2, platform health management can be achieved. This functionality can be achieved, for example, by using the logging feature to trigger various recovery routines when an error occurs.
Identity Access Management
Adaptive AUTOSAR Identity and Access Management (IAM) uses x.509 certificates and is responsible for authentication and authorization of resource access. IAM provides access control between and within ECUs. ROS2 also uses x.509 certificates to implement access control using permission files in the provided DDS security plug-in "DS:Access:Permission". The access control and authorization mechanism of ROS2 uses the public key infrastructure provided by the "DDS:Auth:PKI-DH" plug-in implemented by DDS. The main difference between the two platforms is that AUTOSAR provides adaptive authentication and authorization within the ECU, while ROS2 does not take a clear position in this regard, and currently no available tuning options for this purpose have been found.
Diagnostics
The Diagnostics API package describes a conformant implementation of the Unified Diagnostic Service (UDS), compliant with the corresponding ISO 14229-1 standard. Currently it provides functionality over an Ethernet-based diagnostics over IP (DoIP) layer, but is expected to be expanded to include traditional automotive networks such as CAN. ROS2 does not contain UDS-compliant diagnostic functions, and although there are several diagnostic packages included in the official ROS2 package index folder, they are not related to UDS and therefore are not compliant with the ISO 14229-1 standard.
Log and Trace
In Adaptive AUTOSAR, Logging and Tracing provides APIs for logging and tracing applications. The generated information is classified according to severity and can be associated with different cases (such as safety and security topics). The AUTOSAR alliance provides a standard protocol for representing log information as well as corresponding data analysis tools. For ROS2, there are Logging and tracking software package. Most of these are not part of the binary package but can be integrated as needed. Tracing packages can record runtime and execution data, system and component behavior, and their analysis. Analysis tools for tracking files are also recommended. A major drawback of ROS2 is that its logging capabilities are not compliant with real-time requirements and there are issues with the credibility of some log entries. While it is unclear whether these issues also exist in Adaptive AUTOSAR, it is certainly a necessary requirement for a safe and reliable E/E architecture.
Cryptography
In terms of encryption programs, the Adaptive AUTOSAR platform defines an interface to the encryption stack "ara::sec::crypto", which includes random number generation, Advanced Encryption Standard, asymmetric encryption Rivest–Shamir–Adleman (RSA), hash functions , media access control address (MAC) and key exchange mechanism. AUTOSAR also supports handling cryptographic objects such as X.509 certificates. ROS2's security features are based on the DDS standard's security plug-in, which is called "DDS:Crypto:AES-GCM-GMAC" and uses the Galois counter mode of the Advanced Encryption Standard, a public key infrastructure that handles encryption, decryption, signing and hashing. Since all security features of DDS are disabled by default, users must enable them through the ROS2 security tool. Both Adaptive AUTOSAR and ROS2 provide the same functionality, but require manual activation in ROS2.
State Management
State management receives events from other Adaptive AUTOSAR platform applications such as platform health management, diagnostic management, update and configuration management, and network management. These events include event type, priority, and application identification as input to the state manager to request the execution manager to perform state transitions. For example, platform health management can trigger error recovery through the state management service, which requests the execution manager to restart the corresponding function, and diagnostic management can request to switch the system to a different diagnostic state or initiate updates and configuration management to shut down parts of the system. During diagnostics and updates, status management will use network management to keep the network operational during diagnostics or updates.
ROS2 does not have similar diagnostic or update functions. However, the recovery of interrupted processes can be achieved using the Quality-of-Service (QoS) feature. By identifying the process as unavailable, the recovery mechanism can be initiated. However, the QoS option is Part of the underlying DDS implementation, it is just an indirect feature of ROS2.
Update and Configuration Management
Adaptive AUTOSAR's update and configuration management is the interface that handles update requests, the updates themselves and software modifications. It is responsible for implementing over-the-air updates (OTA) and combines the installation and update process with the removal and tracking of software components to achieve this purpose. The service is similar to Linux package managers such as dpkg or Yellowdog Updater, Modified (YUM), and only performs authorized software updates. It also enables variant-specific configuration and functional verification, as well as all other processes after updates. There are two packages for continuous integration (CI) and continuous development in ROS2, the ROS2 scripts and templates within the build factory, provided by Open Robotics, and the Pull Request (PR) build package that runs when a PR occurs and Test package, it only works on Linux and does not work across repositories. To compensate for these limitations, there are also CI build packages, which unlike PR builds do not run and test automatically, and their testing activities are not limited to updated components, but test all packages on all platforms. The scope of the test can also be limited for time constraints. For updated features, package maintainers must continually make package releases. Overall, this functionality appears to be similar to the Adaptive AUTOSAR service.
Summarize the differences
The above table shows a summary of the capabilities of ROS2 with the Adaptive AUTOSAR API functionality. However, it is worth mentioning in this context that ROS and ROS2 were originally developed as a solution for robotics applications. From this starting point, it is now also available used in autonomous driving solutions.
One of the reasons for the success of ROS/ROS2 may be that automotive engineers may be looking for alternatives to AUTOSAR, as the standardization content of this platform is very large and the workload required to comply with the specifications seems to be high, especially for those who lack AUTOSAR experience For developers. In addition to the fact that the amount of effort required for conformance to the standard increases disproportionately with the size of the software project, ROS/ROS2 solutions appear to be promising alternatives that are explicitly designed to implement functionality for interaction using nodes whose Loose coupling leads to modularity, scalability, adjustability, and enables faster development.
In addition, ROS2 provides a variety of features that simplify application development tasks. An example is a predefined, robot-specific message type that can be used directly to implement intra-node communication. In addition, ROS2 provides powerful code debugging tools that can record, playback and visualize data. For example, RQT-Graph can display the communication between nodes to deduce the logical architecture of the system from the bottom up. Another example is RVIZ, which visualizes sensor data and a vehicle's position in the environment. In terms of how platforms are developed, they all follow a model-based approach. In terms of coding, the Adaptive AUTOSAR platform defines guidelines for using C++14 as a standard to achieve simpler distributed system structures. The coding guidelines are based on existing guidelines from the automotive industry. Client libraries for ROS2 are a set of codes used to ensure consistency and applicability of API usage. These libraries allow users to access ROS2 concepts to build applications. There are client libraries available for various programming languages. The ROS2 documentation also provides a coding style guide to support the goal of a consistent product.
One of the main differences between the two platforms is that the AUTOSAR standard is not open source. Access to the documentation requires membership in a global consortium of nearly 300 organizations that also contribute to the specification and evaluation of the standard. There is a licensing fee, and there are no AUTOSAR-licensed tools available for free . In contrast, the ROS library and related documentation are open source, and the developer community provides additional packages and code libraries that can be customized for modification. This is very important because another limitation of AUTOSAR is the poor quality of the documentation. On the other hand, there are also ROS2-based solutions that are not open source, especially the recently certified automotive-specific solutions that are not public, in which case the benefits associated with open source may not be fully enjoyed, but the automotive Specific adaptations appear to be beneficial, and if the ROS community can bridge the most important gaps identified in Table I, the advantages mentioned here may allow ROS to expand from the autonomous driving domain to other automotive domains, thus forming a framework for mature AUTOSAR. A realistic alternative to the standard.
Other key advantages of ROS2
1. The Adaptive Autosar component is a process. In ROS2, a component is a node, and a process can have multiple nodes.
2. Adaptive Autosar only uses C++ at the application layer, and the ROS2 prototype can also be written in other languages such as Python.
3. Adaptive Autosar does not provide data recording, playback, visualization or debugging tools, especially large-scale data recording seems to be completely missing.
4. Adaptive Autosar uses service-based SOME/IP, and ROS2 uses data-based DDS. The former can only switch between UDP and TCP, while the latter has QoS (Quality of Service).
5. ROS2 has only one open source implementation, used by thousands of users. There are multiple closed-source implementations of Adaptive Autosar, which are largely incompatible with each other.
6. ROS2 supports high-performance data transfer protocols such as shared memory or zero-copy (via RTI Connext Micro).
7. ROS2 contains reference implementations of device drivers, such as Velodyne VLP-16 HiRes.
8. ROS2 provides some tools, such as a static transformation library, some functions of a certifiable mathematics library, and a time synchronization library for topic synchronization.
Conclusion
The architecture and content of Adaptive AUTOSAR and ROS2 are presented in the context of current automotive architecture development challenges. While the permission-based adaptive platform is specifically tailored to the trend towards service-oriented architecture in automotive, the open source ROS2 was originally targeted at robotics. Application, starting from the layers and APIs specified by adaptive AUTOSAR, the degree of correspondence between the ROS2 architecture and the adaptive function set of the AUTOSAR platform is explained. Adaptive AUTOSAR is more standardized than ROS2 and also provides standards for the development process, which meets With interoperability and consistent specifications within the industry, the platform inherently meets automotive requirements, particularly safety aspects.
Although ROS2 does not specify so many services, APIs, or process standards, the community provides packages with additional functions. As pointed out in the conclusion of Table I, ROS2 can fully satisfy some of the API and service functions of adaptive AUTOSAR, although the standards The implementation does not provide all car-related features, but can be adjusted by adding packages and custom settings. Adaptive AUTOSAR, on the other hand, has features partially implemented by ROS2, but it is not clear if there are additional packages to Filling the gaps, additionally, based on the analysis Adaptive AUTOSAR provides some APIs that are not met by the ROS2 implementation, as described in various parts of the API, these gaps may sometimes be mandatory (e.g. network management), In other cases where these differences are more relevant to automotive requirements (e.g. diagnostics), the safety certification of a commercial version based on ROS2 shows that, with corresponding adjustments and designs, it can comply with automotive service-oriented architecture requirements, which explicitly refers to the Rewriting parts of the open source implementation to enhance real-time capabilities and memory management, compared to adaptive AUTOSAR, allows new users to start using ROS2 for architecture development without any barriers.
references
【1】Jacqueline Henle， Martin Stoffel. Architecture platforms for future vehicles: a comparison of ROS2 and Adaptive AUTOSAR
【2】Apex.AI report :Adaptive Autosar and ROS 2
For more detailed content, send "Knowledge Planet" in the background to join Knowledge Planet to see more.
resource
Autonomous driving and positioning related sharing
Moving object detection based on optical flow in autonomous driving
Camera extrinsic parameter calibration based on semantic segmentation
A review of autonomous vehicle positioning methods in high-speed scenarios
Patchwork++: A fast and robust ground segmentation method based on point clouds
PaGO-LOAM: Ground-based optimized lidar odometry
Multimodal road edge detection and filtering method
A framework for simultaneous calibration, positioning and mapping of multiple lidars
Extraction, mapping and long-term positioning of rods in dynamic urban environments
Motion distortion correction of non-repetitive scanning lidar
Fast and tightly coupled sparse direct radar-inertial-visual odometry
3D vehicle detection based on cameras and low-resolution lidar
Annotation tools and city datasets for 3D point cloud semantic segmentation
Basic introduction to getting started with ROS2
Automatic calibration of solid-state lidar and camera systems
Sensor fusion positioning solution of lidar+GPS+IMU+wheel speedometer
Mapping and positioning of road scenes based on sparse semantic visual features
Annotation tools and city datasets for 3D point cloud semantic segmentation
More articles can be viewed: A summary of historical articles on point cloud learning
SLAM and AR related sharing
Introduction to TOF camera principles
Introduction to TOF time-of-flight depth camera
Open source and optimized F-LOAM solution: based on optimized SC-F-LOAM
[Open source solution sharing] ORB-SLAM3 is open source!
[Paper Quick Reading] AVP-SLAM: Semantic SLAM in automatic parking systems
[Quick Reading of Point Cloud Papers] StructSLAM: Structured Line Feature SLAM
Commonly used 3D depth cameras
Review and evaluation of monocular visual inertial navigation SLAM algorithm for AR equipment
SLAM Overview (4) Laser and Vision Fusion SLAM
Semantic SLAM system for real-time reconstruction by Kimera
SLAM Overview (3) - Vision and Inertial Navigation, Vision and Deep Learning SLAM
Easy-to-extend SLAM framework-OpenVSLAM
Gao Xiang: Challenges in unstructured road laser SLAM
Introduction to SLAM method based on fisheye camera
3D Vision and Point Cloud Learning Planet : Mainly aimed at intelligent driving full-stack related technologies, the Knowledge Planet for learning and sharing of 3D/2D vision technology will continue to share practical technology, summarize knowledge points, solve code problems, share the latest paper, and answer questions. etc. Planet invites big names with continuous sharing capabilities in various fields to join us, provide technical guidance to beginners, and answer questions without hesitation. At the same time, Planet will work with well-known companies to release relevant recruitment information and referral opportunities for autonomous driving, machine vision, etc., creating a cluster of technical talents who can share and help each other in learning and employment.
If there are any errors in the above content, please leave a comment. Corrections and exchanges are welcome. If there is any infringement, please contact us to delete it.
Scan QR code
Follow us
Let’s share and learn together! We look forward to friends who have ideas and are willing to share to join Knowledge Planet and inject fresh vitality into sharing. Topics shared include but are not limited to three-dimensional vision, point clouds, high-precision maps, autonomous driving, robots and other related fields.
Sharing and cooperation methods: WeChat "cloudpoint9527" (remarks: name + school/company + research direction) Contact email: [email protected].
Click "Looking" and you will look better.
