Robust.AI uses collaborative mobile robots to move goods through warehouses

Robust.AI develops Carter, a mobile robot that works alongside warehouse staff to move goods and support fulfillment. Its approach combines autonomous transport with direct human interaction, while its Robotics-as-a-Service model makes deployment scope and acceptance terms central to the buying decision.

01 / ProductCarter carries goods while people remain part of the process

The Carter product page describes a mobile robot with shelving, a touchscreen, barcode scanning and put-to-light guidance. Its force-sensing handlebar supports direct physical interaction, including manually moving the robot when appropriate. The design is intended to make autonomous transport useful within human warehouse work, rather than requiring every action around the robot to be automated.

Robust.AI publishes a 100-kilogram payload rating and an operating-time claim of up to 18 hours. Those are product specifications and vendor claims, not measurements from this article. The deployed shelving, goods distribution, battery use and operating conditions should be confirmed for the offered configuration. A nominal payload limit does not describe how every assortment of items fits on the robot.

The warehouse-fulfillment page presents picking support, putaway, point-to-point transport and mobile sortation. These jobs share a basic opportunity: separate the movement of goods from some of the walking or pushing that staff currently do. Carter is therefore best understood as a transport and workflow tool. The described fulfillment process still includes people handling items.

02 / AudienceLook for avoidable travel between stable work steps

A good starting candidate is a facility where workers repeatedly move totes between receiving, picking, packing or other defined locations. If the handoff points are understood, a mobile robot can be evaluated on a bounded transport route before the team changes the rest of the warehouse process. That gives the operating staff a clear task against which to judge the system.

Picking support is a different scenario from simple tote transport. The robot may carry an order container and help direct the sequence of human work, while staff still identify and pick the goods. The evaluation should distinguish travel saved from changes in picking accuracy or handling speed. Those outcomes have different causes and should not be merged into a single productivity claim.

The current company homepage emphasizes flexible deployment and an all-inclusive, no-CapEx proposition. That makes the offering relevant to operators who want an ongoing service relationship rather than only buying equipment. It does not establish that every building, task or commercial arrangement can start without preparation. Site readiness and the precise scope of “inclusive” remain contract questions.

03 / WorkflowA proposed rollout begins with one transport loop

Consider a proposed rollout between a tote handoff point and a packing area. The warehouse team first maps the present route, its queues and the rules for giving work to a person or machine. It then identifies the goods that Carter will carry and the circumstances in which a person may reposition it. This is an evaluation example, not a deployment carried out by Sequenced.

Next, define the handoff. A completed robot journey is useful only if the correct tote reaches a location where someone can use it. The proposed acceptance test should therefore include identification, loading, destination confirmation and unloading. It should also include ordinary congestion, an occupied destination and a tote that cannot be accepted immediately. Those states reveal how the robot fits the existing work.

Robust.AI’s Shiplab announcement, dated 8 July 2026, describes a phased approach beginning with tote transport before expanding into broader picking workflows after validation. The announcement is useful evidence of the proposed deployment model, not proof that every planned phase has already achieved its intended result. Its staged structure offers a sensible way to separate transport value from more involved workflow changes.

Once the first loop is working, the team can consider picking support or putaway. Expansion should preserve the ability to measure the new task separately. A robot that works well on a simple route may encounter different congestion, loading patterns and interaction needs when it accompanies picking. Reusing the same hardware does not make those operating conditions identical.

Finally, record exceptions in terms the warehouse can act on: waiting for loading, unavailable destination, navigation interruption or a person choosing manual movement. The aim is to distinguish a robot issue from an upstream or downstream bottleneck. That distinction makes it easier to decide whether another robot, a changed route or a changed handoff would improve the process.

04 / PricingRaaS makes acceptance and service scope part of the economics

Robust.AI describes a Robotics-as-a-Service agreement in its Shiplab announcement, but the public material reviewed does not provide a numerical monthly tariff. A prospective customer therefore needs a quotation defining the deployed fleet, service term, support and the work required to make the chosen process operational. “No CapEx” marketing does not by itself describe the full payment schedule or contractual obligations.

The Shiplab release describes payments deferred by phase until jointly confirmed performance. That is a stated arrangement for that engagement. It should not be generalized into a promise that every customer receives the same acceptance condition or payment timing. A buyer can use it as a concrete question for its own proposal: what event starts payment, and how is that event measured?

The commercial contact route is the place to scope those terms. Our suggested comparison includes any site preparation, integration, operator time and residual manual transport alongside the service charge. These are analytical cost categories, not fees asserted by Robust.AI. The business case should use completed warehouse work rather than robot journeys alone.

05 / DistinctionsHuman interaction and incremental deployment shape the offer

Carter’s combination of autonomous movement and a handlebar for direct interaction is a meaningful design choice. It recognizes that warehouse staff may need to move or redirect equipment in the course of ordinary work. The benefit is easiest to assess by observing real handoffs: whether staff understand what the robot is doing and can resolve an interruption without creating confusion about the next task.

Locus Robotics is a useful comparison for collaborative warehouse fulfillment and picking workflows. Vecna Robotics provides another perspective on autonomous material movement. The comparison should focus on the load, handoff process and orchestration requirements that each proposed system must serve. A shared “warehouse robot” label can conceal very different operating jobs.

A June 2026 Aptiv collaboration announcement describes radar and vision perception for Gen 3 Carter, paired with visual localization and mapping. It says Aptiv is advancing toward PL(d) certification for PULSE across relevant use cases. That wording describes work on the sensor platform, not confirmation that Gen 3 Carter as a whole has achieved that certification. The delivered platform and its documentation need to be checked directly.

06 / QuestionsSeparate announced fleets, completed deployments and qualified configurations

The O’Neill Logistics announcement, dated 28 July 2026, describes 24 robots across two sites with go-live planned for the fourth quarter of 2026. On the evidence read, that is a deployment plan rather than independent confirmation of completed operation. It indicates commercial activity, while leaving actual site readiness and outcomes to later evidence.

For a prospective customer, the important hardware question is which Carter generation and perception configuration will be delivered. Product specifications, a component-selection announcement and a future certification milestone are related but distinct evidence. Ask for the actual system’s supported operating conditions and safety documentation instead of combining all advertised capabilities into one assumed configuration.

The integration boundary also needs to be clear. A simple point-to-point transport phase may need less connection to warehouse software than coordinated picking or putaway. The proposed project should state where tasks originate, how destinations are chosen and how completion is reconciled. Otherwise, the robot can move goods successfully while the surrounding information flow still relies on an improvised manual process.

Finally, define the service relationship when a route or workflow changes. Warehouses reorganize inventory, change packaging and adjust shift patterns. A RaaS agreement should make clear which changes are covered, who updates the operating setup and how a revised workflow is accepted. That is where an ongoing service model may prove useful, but the public proposition alone cannot settle the details.

07 / DecisionStart with a task whose value survives a measured trial

Robust.AI is worth considering when collaborative transport can remove a recognizable bottleneck and the warehouse wants to expand in stages. Begin with a specific loop or fulfillment task, measure completed handoffs and agree the RaaS acceptance criteria. Treat announced customer rollouts and future certification language as context, while basing the purchase on the configuration and service terms actually offered.