Get involved

There are several ways in, and they are not the same size.

Become a design partner

For operators running mixed-vendor fleets. The useful version of this is not a pilot. It is access to the places where the contract is wrong, and the willingness to say so early enough to change it.

If you run robots from more than one vendor and you have built the glue yourself twice, that is the conversation. Write to maintainers@swarmada.io.

Help test on real robots

In the v0.3 specification, every end-to-end grade reads partial. Nothing in that release has been exercised against a physical robot. That is the largest single gap and more code does not close it.

If you work with a robot, your own or one at your company or lab, and can help get an adapter or the conformance harness running on it, that is the most useful thing anyone can do for the project right now. The more different the robots, the better. Robots from other vendors and on other protocols all count, and so does a robot you can only reach remotely.

Variety matters more than ownership. The claim Swarmada makes is about heterogeneity: that an orchestrator can assign work across machines from different vendors without lock-in. One machine validates one vendor's adapter and nothing else. Robots from five vendors validate what is actually being asserted.

Testing happens on the owner's terms: supervised, no production fleet, no autonomous operation. The conformance harness exercises the protocol contract. Swarmada's emergency stop is a supervisory stop. It is not a safety function and it is not a substitute for a hardware emergency-stop circuit. Anything involving a moving machine happens under whatever safety controls already govern that machine.

Interested? Write to maintainers@swarmada.io. A short note saying which robot you have is enough to start.

Why the robots need to use different protocols

The contract between the control plane and a Fleet Adapter is the part of Swarmada that is meant to be neutral. A contract checked against one protocol carries that protocol's assumptions without anyone noticing.

Protocol	How it moves commands and state
ROS 2 / Nav2	DDS middleware; navigation goals with feedback and a result
VDA5050	MQTT; orders sent to the vehicle, state messages sent back
MAVLink / PX4	Command messages with acknowledgements, over radio or serial links

Reference adapters for all three are in the project's repositories. Each differs in ways the contract has to absorb, and a simulated binding does not show how.

Acknowledgement and completion are different facts. Each protocol reports that a command was received, that it is in progress and that it finished in its own way. The contract must keep those separate. Running it against one protocol cannot show whether it does.

Ownership of a robot has to be enforced somewhere. Fencing tokens and leases exist so that two controllers never both believe they own the same machine. Where a stale instruction can be refused, at the robot or only at the adapter, depends on what the protocol carries.

Failure looks different on each transport. A dropped DDS discovery, a lost broker connection and a radio link going quiet are different events. The control plane has to reach the same safe conclusion from all of them.

Simulation hides defects. The project's own conformance suite passed for months against a robot that never moved, and the false-completion defect appeared only once it did. The same applies across protocols: checks that cannot fail on one binding may fail on another.

A neutral claim needs more than one witness. An adapter contract that has been run against a single vendor's protocol is a description of that vendor. Passing the same harness on unrelated protocols is the evidence that the contract does not belong to any of them.

Robot vendors

If you build robots or robot software, the project maintainer can help.

That can mean writing a Fleet Adapter for your platform, or running the conformance harness against an adapter you have already written and reporting what it finds. An adapter that passes the conformance suite can be listed in the adapter registry. Reports that the contract does not fit your protocol are as welcome as passing results.

Write to maintainers@swarmada.io with the platform and the protocol it speaks.

Write something, or break something

The specification is public, the conformance harness runs locally, and the issue tracker is the real one, not a curated list.

The most useful contribution is not a feature. It is an adapter for a robot the reference adapters do not cover, or a conformance check that fails where it should not. A report that the contract is wrong is worth more than a report that it is unclear.

To start: run make quickstart from the repository, then read CONTRIBUTING.md.