Reimagining Real-Time: Apex.OS 25-05 Release Powers Next-Gen Autonomy

New type evolution primitives and improved rosbag tools—25-05 is built to streamline safety-critical development across industries.

Today, we announce the Apex OS 25-05 releases. This release focused on feature development, but we also snuck in some great quality and user experience improvements. The release period spanned three months, starting at the beginning of March.

We strive to stay one step ahead of our customers’ needs for quality and functionality. This is a fine line that requires equal parts agility and steadfastness. We chose to walk it so that our products can be deployed in numerous safety-critical domains. We encourage all interested parties to reach out and discuss how they can utilize the 25-05 releases of Apex.Grace, Apex.Ida, and Apex.Alan for their upcoming production programs. 

Type adaptation 

This feature was backported from ROS 2 Humble (REP 2007). Its purpose is to extend the ROS C++ client library (rclcpp) to provide a standardized method to convert between ROS types and user-defined C++ types. Prior to this concept being introduced, developers had to write code to interface with a custom data structure (such as cv::Mat from OpenCV). This is error-prone and not as efficient as the middleware can be with respect to serializing the data from one data structure to another. Today, the developers can define a type adapter to handle this conversion process programmatically. Conversion, serialization, and deserialization functions are supported.

Type adaptation is a milestone on the path towards type evolution. This is the ability to effectively version the message interfaces so that old data from years ago recorded with the original data model can be migrated to new versions of that data model, for example, because you needed to add an additional field, change a type, set bounds, or make a field optional. There is huge value in data retention, but the trade-off is usually a lack of innovation in the data model. Type evolution will allow the data model to evolve while dragging the old data along for the ride.

Record and replay — Kilted update 

In the last release, we brought our record and replay services into sync with the upstream ROS 2 Jazzy release. Now these services are in sync with the latest ROS 2 Kilted release. Along with general stability and bug fixes, the following features were added:

·      Replay of multiple rosbag files via the CLI

·      New option to replay messages chronologically based on the publication timestamp

·      The highly anticipated return of a progress bar shown during replay, like what was seen in ROS 1

·      A few methods to use during troubleshooting: printing debug messages stored in rosbag files, filtering options in the CLI for bagfile info, and showing the size contribution of each topic within a bagfile

The record and replay services have evolved into an entire framework used by all types of engineers in a given project — application developers, system architects, system integrators, and system testers. We will remain involved in the open-source development of rosbag2 and will continue to backport those changes to Apex.Grace.

Message source timestamps 

In most middleware solutions and frameworks like ROS that use the pub-sub communication pattern, the subscribing application must use an inaccurate timestamp to estimate when a given message’s data was captured (typically by a sensor like a camera or lidar). In addition, most middleware solutions do not guarantee that every message sent is received in the same order.

Some perception sensors capture a source timestamp for when the scene was observed. In Apex.Grace, we can capture this source timestamp and store it in the message for the publishers to access. This allows the publisher to filter through its subscriptions and process the messages in the order the sensor captured them (because sometimes the middleware can deliver messages out of order).

Stability and user experience 

We want to enable early-stage and production projects with respect to our SDK, its tools, and the common workflows developers use to write applications and deploy them to autonomous systems. This means it needs to be easy to move fast and break things, while being able to solidify on a technical direction and harden the code within that system.

This release contains great user experience (UX) improvements around working with meta-message libraries, streamlining build steps for finding Bazel runfiles, and decoupling one of the main ROS packages (rclcpp_components) from the legacy build system. Collectively, these changes make updating and using introspection and visualization tools (ros2cli, rqt, RViz) — and their custom-built plugins! — more trivial, allowing developers to move faster.

There is no one-size-fits-all concept when it comes to a robotics SDK and middleware. That was our justification for the features and changes made in this release. We are enabling developers to leverage a common, safety-certified framework and unified middleware that can be molded to the needs of their robotics, autonomy, and/or safety-critical products and programs.

If you are interested in Apex.AI products for your projects, contact us.