The Space ROS team is excited to announce the release of Space ROS Humble 2024.04.0.
Space ROS is a project that seeks to enable the development of robotics for space. We do so by providing a set of packages based on ROS 2 Humble, together with additional software related to static analysis, an extension for VSCode to use the results of the analyzers, custom docker images that facilitate getting started, and several demos that feature simulations of space applications.
Release details
This release updates the base build of Space ROS to the Humble 2024-02-22 version. It also fixes several issues in the tools and demos. In total, 10 issues have been closed as part of this release. For an exhaustive list of all the issues addressed, click here .
The Space ROS project is comprised of multiple docker images, demos, and additional tools. The base Space ROS image is available as osrf/space-ros:humble-2024.04.0 on DockerHub.
This release comes 3 months after the last release. The next release is planned for July 31, 2024. If you want to contribute to features, tests, demos, or documentation of Space ROS, get involved on the Space ROS GitHub issues and discussion board.
@mkhansen out of interest, how deterministic is Space ROS? I ask since I have heard from a couple colleagues that work with satellites etc. that even dynamic memory allocation is off the table as it is not considered sufficiently deterministic.
So if may ask, what applications does Space ROS target and how does it get around constraints like no dynamic memory allocation without a complete rewrite?
I think those slides are pretty relevant. As I understand there is a lot in common between automotive and aerospace, with the latter just being much stricter. Having looked very quickly through those slides, it does appear that Apex AI has rewritten a fair bit of ROS2 code to the extent that the comparison on their second last slide seems to suggest that Apex.OS is sufficiently different from ROS2 to be considered its own thing.
Hi @allsey87, hope you don’t mind me tagging-in on this one. I joined the Space ROS ACO and have continued on as a contributor. Instead of a ROS background, I have been writing very low-level (C and assembly) code with strict deterministic memory and timing requirements for a decade. Standard boiler-plating applies – I’m speaking for myself, not on behalf of the Space ROS project committee or my employer.
Space ROS as it exists right now isn’t more deterministic, static, etc. than the standard ROS 2 distribution. If you look at the Space ROS SciTech paper you’ll see that while memory safety was called out as an area for improvement, the focus was
“… updates to the framework and surrounding process that would accelerate that certification if Space ROS was selected as part of a future mission solution.”
Space ROS is not supposed to be a drop-in replacement for your safety critical flight software and is not a direct alternative to an ROTS, cFS, or F’.
The goal is to provide an on-ramp for incorporating ROS components into projects that have software quality requirements such as DO-178C and NPR7150.2.
You can find an overview of what Space ROS is on the website and more technical details available in the docs.
As an example use-case that this could support, imagine a complex space system with payloads or subsystems that require the power and flexibility of a ROS stack while a traditionally verified flight computer (with all the constraints you mentioned) manages the vehicle.
The Distributed Spacecraft Autonomy project at NASA Ames is preparing a flight demo of these hybrid trust architectures that includes an isolated Space ROS process working under the direction of a more traditional cFS flight software stack which was previewed at Small Sat last year.
If you need to interface with traditional flight software, several communication bridges exist and, if you’re more concerned about the certifiability of the ROS 2 systems themselves, multiple deterministic ROS 2 execution projects exist that could be used with Space ROS if desired. (I haven’t directly linked any to avoid accidentally overlooking a project or implying an endorsement.) There was some preliminary work on using the rcl_allocator_t memory allocator interface to run Space ROS with arena allocated memory you can find in the Space ROS repository here. There is plenty of interest in continuing this work, PRs welcome.
Does that answer your question?
TL;DR: It isn’t, one day it might be, but right now it isn’t targeting those applications.
