Agnocast & Callback Isolated Executor: True Zero-Copy IPC and Middleware-Transparent Scheduling for ROS 2

Projects
4

@gbiggs
Thank you for your thoughtful questions and for taking the time to engage with our work!

ROS 2 enables the easy construction of robotics systems across a very wide range of environments. We position Agnocast as a library for users who want to further push performance tuning to its limits in specific environments. In other words, users who encounter performance bottlenecks in systems built on the existing ROS 2 stack now have the option to migrate part or all of their middleware stack to Agnocast. Since the user interface is designed to closely mirror rclcpp, migration requires minimal effort. At this stage, Agnocast only supports C++ clients on Linux, though we may expand platform support in the future.

  1. Agnocast is a separate communications system, not going through the RMW layer. This makes it incompatible with all the existing ROS tooling, including tools such as rosbag2 and rviz, and also means it won’t benefit from improvements to the RMW layer - such as the upcoming memory architecture agnostic improvements that will allow ROS messages to be views onto GPU buffers. Why did you ignore the RMW layer?

For details on why Agnocast is not integrated as an RMW implementation, please refer to this. Compatibility with the existing ROS 2 ecosystem is ensured through the Bridge feature. This feature mediates between Agnocast’s communication world and the RMW-based communication world, enabling seamless interoperation between them. From the user’s perspective, the experience remains the same as working with a standard ROS 2 system — users can transparently interact with ROS 2 applications that do not use Agnocast, including tools such as rviz and rosbag, without any additional effort.

  1. You state that CIE “removes this middleware layer”. Does this mean that it is removing the ROS executor infrastructure and effectively allowing nodes to execute directly in OS processes, rather than through the executor abstraction?

This statement does not imply the removal of the ROS executor infrastructure. Rather, it refers to eliminating scheduling behavior from the middleware layer in order to resolve issues related to nested scheduling. Specifically, CIE achieves semantic equivalence between OS-level scheduling and executor-level scheduling by constraining the executor to manage only a single callback. For the most accessible explanation of the nested scheduling problem and how CIE addresses it, please refer to our paper.

  1. Your LinkedIn post says that “It has been officially decided that these middleware will be adopted across the entire Autoware project, replacing the existing ROS 2 stack.” Does this mean that Autoware is no longer using ROS?

To be precise, the announcement means that Autoware will provide users with the option to fully adopt Agnocast, rather than forcing an immediate migration. As described in the autoware_agnocast_wrapper README, building Autoware with the default build options continues to produce a system based on the conventional ROS 2 stack. By enabling the Agnocast build option, users can build Autoware with Agnocast as its communication foundation. TIER IV, the primary contributor to Autoware, has decided to build its autonomous driving systems with the Agnocast-enabled option going forward. It is also important to note that even with the Agnocast-enabled build, Autoware continues to depend on the existing RMW communication stack for inter-host communication and for interacting with tools such as rviz and rosbag that rely on RMW-based communication.

2 Likes