Cloud connectivity for robots.
From the outset, a key objective of the Rocos platform was to make it as easy as possible to bring the benefits of cloud connectivity to robotics. In thinking about how to connect robots to the cloud, it was important to consider how mechatronics engineers could do the least amount of work possible to gain connectivity. Another consideration was how customers could connect robots to the cloud without having to install anything on the robot at all! (As a side note, this is indeed possible with the Rocos agent! Albeit in a limited set of scenarios).
What resulted, is a target 5 minute ‘time to hello robot’ way of getting the Rocos agent onto robots, authenticated, and connected, achieved on Debian flavours of Linux by hosting our own PPA, allowing customers to securely pull Rocos agent packages and install with a simple apt-get, and without any dependencies on other languages and frameworks such as Python.
In choosing the language for the agent, Golang came out on top - for a few reasons.
- It has great performance characteristics;
- Has an easy cross-platform OS and processor architecture compilation;
- And a vibrant ecosystem.
Top it all off with the fact that we can compile our agent down to a single statically linked binary and you have a low-footprint, high performance chunk of code that acts as a Swiss-army knife for connectivity and robot-side stuff.
So what exactly does the Rocos agent do?
Primarily it does what it says on the tin - it acts as an agent for our platform, sitting on robots and providing secure, reliable connections between the robot and the Rocos platform. It does this by dialling out to API endpoints in the cloud-hosted Rocos platform, establishing encrypted, compressed bi-directional streams, over which remote users and code can request specific telemetry from the cloud, can send control messages, do remote configuration updates as well as access the robot’s file system, amongst other things. Once connectivity is established it is sensitive to network health and will do its utmost to re-establish unhealthy connections. If the robot experiences a network partition it will cache data locally and then re-send it once connectivity is re-established.
Configure the shape of the data you need.
On top of the fundamental connectivity the Rocos agent provides, it offers a set of messaging features allowing developers to configure, at request time, the shape of the data they stream. This includes sampling interval (for example, give me odom data once a second, or as fast as its generated by the robot); TTL (don’t send me data if more than x time has passed since it was generated); and deadline (how long to attempt sending a message before giving up and retrying later, subject to the TTL). This means the agent can support a variety of messaging scenarios: Have a high frequency sensor stream but don’t want to burn precious bandwidth sending it all on to connected subscribers? No problem - drop down the send frequency to a message every 10 seconds if you like. Is your robot operating in a cave and it’s vital that no matter how bad the network connection is the message must get through? We’ve got you covered - just configure the TTL for the length you think the robot will be down in the cave and the agent will ensure the messages get through as soon as connectivity is re-established.
The Rocos agent was designed to provide these message features consistently for whatever kind of robot you need to operate. This design principle means that within the agent, its component-based design strives to translate robot concerns as close to the outer edge of the agent as possible. This transforms robot messages and deals with their specifics as soon as possible in the telemetry streaming pipeline. Internally this means that the agent is working with canonical messages and accesses all the message features.
ROS, MAVlink, or any other robot - we've got it covered.
Security and streaming technology is completely consistent regardless of the type of robot. This means we support ROS robots, robots that use MAVlink, Boston Dynamics Spot, and a bunch of low-level transports like TCP tidy up any other stacks we come across. With Rocos, there’s an option to build out integration with new robots natively - as we did for Spot. Basic Spot telemetry was streaming within three days of starting integration, then remote teleoperation within five, which provides great validation of the Rocos agent design.
One very important thing to know about the way the agent and platform work together is that the agent only sends data when something wants it. So it doesn’t automatically sit there sending streams of telemetry up to the platform - it only sends what’s been requested from the platform. For example, if you bind up some charts on a Rocos dashboard to visualize data in realtime, the agent only sends data for that dashboard when someone has it open in a browser. If more than one operator has the dashboard open, the agent only sends the data once, and the platform ensures the data is multicast out to all connected subscribers.
The only exception to this is storage streams. You can configure a storage stream in the Rocos portal to ensure the agent always sends telemetry to the platform, even if no one is currently observing it. Data sent on a configured storage stream ends up in the analytics store for you and your team to review later, allowing you to query on specific timeframes, dig into the data and plot it alongside other telemetry streams so you can better understand the behaviour of your robot. There are also ways for customers to export data from storage and to pipe storage stream data into their own cloud storage accounts where they can get to it with their own analytics tools.
Telemetry streaming on the fly - regardless of internet connectivity.
Not only does Rocos provide the pub/sub concept from agent to browser, but also provide this from agent to Rocos API, and…agent to agent! That’s right, you can perform a bunch of telemetry streaming use cases without access to the internet at all. This means you can have an agent acting as a field gateway - perhaps sitting on some compute on the LAN but not on any robot - and this can act as a telemetry broker allowing you to process telemetry from multiple robots on the network, make decisions then send messages back to the robots without once going near the internet. Very useful for internet-denied environments or where you simply want to air-gap your robot’s network for security reasons.
Connectivity is key for Rocos and for enabling true, production-ready robot fleet operations.