Publishing Capabilities
There are several ways you can publish your capabilities.
- Publish on self-hosting: If you are running in a self-hosted environment you can run
npx transitiveDev publishinside the capability directory to make it available on your self-hosted registry. - Publish on transitiverobotics.com: To publish your capability to the official capability store please run
npm packin your capability and send us the tar-ball it produces, via Slack or email. In the future we will provide a more streamlined approach for publishing capabilities and updates, but we expect there will always be a review step to ensure quality.
You can choose to make your capability available for free or for a monthly fee. You can configure this in the meta-data inside your package.json file. You will receive the proceeds of your capability's usage by Transitive users once a month minus a payment processing fee charged by our payment processor (Stripe) and a 15% commission.
Meta-data in package.json
Before you can publish your capability to the official store, you need to change the scope of the package name from @local (the default) to something else, ideally your transitiverobotics.com username. The scope you pick must not collide with the scope of any npm dependencies in your package.
Transitive capabilities add additional information inside package.json in the transitiverobotics field as described in this example:
transitiverobotics: {
title: "My New Capability", // (string) A human readable title
price: {
perMonth: 15, // (number; optional) if provided, will charge that number of dollars (USD) per robot per month
},
videos: [ // (list of URLs; optional) Lists YouTube videos you want to show in your capability's documentation; the first one will be shown on top.
"https://www.youtube.com/embed/...."
],
requires: [ // (optional) A list of conditions that a device need to satisfy in order to be able to run (and hence be allowed to install) the capability. This is not fully documented yet, so it's best to reach out to us if you need help with this.
{
message: "Requires Ubuntu 20 or higher.",
rule: {
">=": [
{
var: "os.lsb.major"
},
20
]
}
},
{
message: "Requires at least one ROS release to be enabled in your config.",
rule: {
">": [
{
"$size": {
var: "activeRosReleases"
}
},
0
]
}
}
]
},
Review Guidelines
There are several things we look at when reviewing capabilities.
- Prudent use of resources:
- CPU, Memory: we will be testing robot, cloud, and web components for their usage of CPU and memory. There are no set thresholds to remain below but resource usage needs to be adequate for the value the capability provides. Said differently, resources should not be wasted.
- Network bandwidth, in particular MQTTSync: make good use of MQTTSync's deduplication and diff-based syncing feature, rather than, say, sending the same data over and over again.
- Avoiding redundancy with Transitive-provided features. For instance, a capability should not create a separate communication path between web, cloud, and robot besides MQTTSync unless there is a good reason. Similarly, there should not be a need for separate authentication and authorization mechanisms, besides the ones already provided by the framework.
- End-to-end user experience: Transitive is specifically design to make it easy to create end-to-end capabilities, i.e., functional units that are independent of anything else that Transitive users can add to their solution by simply installing them through the portal or via configuration files. This also means that capabilities need to be self-containers: the user is not required to set up any additional systems to make them. In particular, the only way the user should interact with the capability is via the UI components included in the capability itself, not a web app hosted elsewhere.