Mixed-vendor fleets on one floor
Most working floors run robots from more than one vendor, each with its own cloud, its own model, and its own idea of the building. One facility pool serves all of them without asking any vendor to give anything up.
· 4 min read
IN SHORT
A mixed-vendor fleet on one floor normally means several separate clouds, several separate models, and no shared record. A Czar Grid serves every robot in the building from any vendor over the facility's own network, so the fleet shares one perception model, one record, and one place to learn the site, while each vendor keeps its own fleet software and safety envelope.
The mobile robots came from one vendor because they were the best at the time. The pick arms came from another because the first vendor did not make arms. The humanoids being trialed at the end of the building came from a third, because that is who had humanoids to trial. Nobody chose a mixed-vendor fleet. Every working floor ends up with one.
Each vendor brought a model, a cloud, a fleet dashboard, and an opinion about how the building is laid out. The robots do not share what they see. The automation team keeps three sets of credentials and three support queues. When a pallet is left in an aisle, three different models decide three different things about it. A facility pool does not remove the vendors. It gives them one thing to share.
One pool, every vendor
A Czar Grid serves every robot in the building, from any vendor, over the facility's own network. The mobile robot asks it for perception. The pick arm asks it about an unfamiliar item. The humanoid asks it what the supervisor meant. They all ask the same pool and get answers from the same models, each within its own latency budget.
Nothing about this requires a vendor to change its robot. The vendor's fleet software still dispatches its own robots. The vendor's controller still runs the body. The stops, speed limits, reflexes, and motion limits stay on each machine exactly as the vendor shipped them. The pool sits beside the vendors' systems, not inside them.
What the floor gets that it did not have
The first thing a mixed floor gets from a shared pool is consistency. One perception model, adapted to this building, answers all the robots. A spill, a blocked aisle, or a misplaced tote is understood the same way by every machine that encounters it, regardless of whose badge is on the chassis.
The second thing is one record. Substrate keeps what every robot asked, what the pool answered, and whether the robot acted or fell back. Today a mixed floor has no single place to look when something goes wrong across vendors. With a pool, the sequence of events on the floor is in one record on site, written in one format, readable by a person.
The third thing is one adaptation loop. When the floor learns a new item or a new layout, Substrate adapts the shared model on the site's own captures, on the pool, with nothing leaving. Every vendor's robots benefit at once. The article on a new item learned once, not once per vendor covers this in detail.
What stays separate
Plenty stays separate, and should. Each vendor keeps its fleet software and its own view of its own robots. Each vendor's safety case is untouched. If one vendor's robots are air-gapped from everything by policy and another's are allowed a declared route to that vendor's fleet software, the pool runs both postures at once; a mixed estate is an ordinary configuration, not a special case.
The site decides which vendor systems the pool connects to. Local Bridge, Substrate's governed connectivity, permits only the routes the site declared and denies egress by default. A vendor's fleet software is a declared route if the site says so and nothing otherwise. A connection is a decision, not a default.
The integrator's position
A systems integrator is usually the one holding a mixed floor together. The integrator sequences the conveyors, ties the warehouse system to the robots, and gets blamed when the vendors disagree. A pool gives the integrator a shared surface to work with and a shared record to point at, and E31 Consulting puts Element 31 engineers on site to install it with the integrator, the automation team, and the robot vendors together.
Some integrators will go further and ship the pool under their own name as Czar Chassis, bundled with the fleet they are delivering, so their customer receives one system. It is the same Grid either way; the difference is whose name is on the proposal. How to buy describes both routes.
One subscription, however many vendors
The commercial side does not multiply with the vendor count. The Grid is one subscription for the configured pool, with hardware, platform license, and sustainment in one line, fixed for the term. Adding another vendor's robots to the floor does not move it. For a floor that expects to keep adding vendors, that is the point.
Questions this raises
- Does a vendor have to integrate with every other vendor on the floor?
- No. Each vendor's robots talk to the pool, not to each other's software. The pool is the shared surface, and the vendor keeps its own fleet software and safety envelope unchanged.
- Who owns the shared model after the site adapts it?
- The adapted weights are produced on the pool from the site's own captures and stay on the operator's hardware. They do not go to any vendor's cloud, and no vendor's robots are preferred by them over another's.
- What does the integrator do on a mixed-vendor floor with a pool?
- The integrator still sequences the floor and connects the vendor systems the site declares. E31 Consulting puts Element 31 engineers on site to install the pool alongside the integrator, the automation team, and the robot vendors.
KEEP READING