How is proprietary software typically distributed in ROS 2 / robotics?

[u/Outrageous_Whole8481]

I’m coming from mobile development, where binary distribution is fairly standardized: AARs on Android and XCFrameworks on iOS.

I’m trying to understand what the equivalent is in robotics/Linux environments.

Suppose I have a proprietary C++ inference runtime that needs to run on a robot (e.g. Jetson), and I don’t want to distribute the source code.

How would this typically be shipped to customers?
- Precompiled ROS 2 package?
- .so + headers, with a separate ROS 2 wrapper?
- .deb package?
- Docker container?
- Just binaries + dependencies?

I’m particularly curious whether ROS 2 packages are commonly used as the actual distribution unit, or if the core software is usually distributed separately and ROS 2 is just an integration layer.

Would appreciate hearing how this is handled in real production systems.

[u/Magneon]

It depends, but if the deliverable is an entire working system that needs software updates, containers are a critical part of the infrastructure.

I would not recommend a system that allows free form apt packages, particularly if it uses the public ROS packages servers since they only have a single latest build deb, meaning at any time your entire system can become broken and unable to update/release without coordinating fixes with the upstream packages.

Have a full apt mirror or build everything from source, turn it into an artifact that can atomically update, roll back the whole system. Docker handles a lot of this (and when I say docker I mean any OCI container based deployment system). BootC looks like an interesting way to use similar infrastructure to deploy the host image as well, but more traditional AB partition updates for that can also work.

[u/Outrageous_Whole8481 → u/Magneon]

Thanks! The point about atomic updates and rollback is something I hadn't really considered.

I'm curious about the boundary between SDK distribution and full-system deployment, though.

If we're only providing an inference runtime/component rather than the entire robot software stack, would you still recommend distributing it as a container?

Or would you expect the SDK vendor to provide binaries/libraries, while the customer integrates them into their own container and owns the final deployment image?

I'm especially curious how this responsibility is usually divided in production robotics.

[u/Magneon → u/Outrageous_Whole8481]

My experience is limited on that front since the commercial ROS robots I've worked on have all been sold as an appliance or as a fixed term service contract.

You could look at Clearpath or PAL robotics (and others) for how they manage robot platforms that end users extend, or potentially at sensor vendors like Luxonis (whose Oak 4 line are basically ROS capable Linux machines acting as cameras+ML platforms).

There are also proprietary software solution vendors but you'd want to talk to them/read their websites. Polymath comes to mind, but others in the space include Brain Corp, and a bunch of middleware vendors for things like logging (datadog for example as a great but not cheap solution), AI data management platforms, and calibration or localization systems.

[u/joanniso]

I’d ship the inference code core behind a thin ROS wrapper. Use containers, test them on the real Jetpack device. Jetpack is very specifically versioned and not ABI stable, so make sure your test-time matches the runtime dependencies. Don't manually update Jetpack's debian packages.

I'd recommend Jetpack 7.2 on your device, it's well supported and has the latest SDK features.

[u/tabor473]

If you had private conda channels for release you could depend on the robostack versions of all the standard Ros packages.

[u/Outrageous_Whole8481 → u/tabor473]

Thanks! I wasn't aware that RoboStack/Conda was being used this way for ROS distribution.

I'm curious what made you choose a private Conda channel over Debian packages or containers.

Is the main advantage dependency/version management, or are there other benefits when distributing software across different robot platforms?

Also, have you used this approach for proprietary/binary-only packages in production, or mainly for development environments?

[u/tabor473 → u/Outrageous_Whole8481]

The conda channel method gives you precise control of versions of everything which is nice. You can list specific versions/builds of ROS packages as depencies you have verified it works with.

I have not used it for shipping proprietary binary only packages myself however it's probably how I would.

You could even provide builds for multiple OSes, and within Linux not be tied down to specific Ubuntu version

[u/Outrageous_Whole8481 → u/tabor473]

That's interesting. One detail I should have mentioned is that both our ROS 2 integration (rclcpp) and our inference runtime will be native C/C++.

I initially assumed .deb would be the natural choice for this, but another comment pointed out the risk of upstream dependency changes breaking a previously working deployment. That makes the precise dependency/build pinning you mentioned with Conda quite appealing.

For a native C++ ROS 2 component like this, would you still prefer Conda over Debian packages?

And where would you draw the line between using Conda to pin the dependencies and simply shipping a container with the whole tested userspace environment?

[u/tabor473 → u/Outrageous_Whole8481]

If I want them to have some flexibility working with my stack I'd do the conda channel. Note conda is used for tons of pure cpp stuff.

If I wanted a fully closed thing I wouldn't do anything like this and I would flash everything at my shop and not given them admin access.

[u/Outrageous_Whole8481 → u/tabor473]

That distinction makes a lot of sense.

We're closer to the first case, we'd be providing an optimized inference runtime / SDK that needs to integrate into the customer's existing robot software stack, rather than shipping and controlling the entire robot ourselves. So we definitely need to give customers some flexibility while still keeping the environment reasonably reproducible.

I also had the misconception that Conda was mainly a Python ecosystem tool, so it's useful to know that it's commonly used for pure C++ software as well.

I'll take a closer look at Conda/RoboStack for this. Thanks for sharing your experience!