PokeBot opens RoboAPI for outside robot testing, with commercial use still excluded

PokeBot has opened RoboAPI, a free technical preview that gives outside developers access to its robot action model, while excluding commercial use and products or services for for profit third parties. Its launch page, dated October 30, invites testing on compatible robot arms.

The service is powered by PokeBot’s Poke-Aurora model. The company says it can follow instructions without collecting new training data for each task. Its central proposition is access: developers can investigate that claim on their own equipment.

An interface changes who can examine a model. A demonstration shows an execution chosen for an audience. Outside access makes it possible to choose different objects, repeat an awkward task and inspect a failure. The value of this opening will depend on what those tests reveal.

The first API example accepts a wrist camera image, the robot’s current state and a task instruction. It returns a sequence of actions. That introductory program prints the predictions without commanding a device, making a useful distinction between a working API connection and a robot completing useful work.

A complete control loop has more responsibilities. It requests actions, validates their format and executes them within the controller’s coordinate, speed and motion limits. It then captures a fresh observation and reports what actually executed before requesting the next sequence.

The documentation uses task sessions and execution receipts to keep that exchange consistent. After a stop or communication failure, it instructs developers to discard unexecuted stale actions and check the robot’s state again. A retry must not cause a previous movement sequence to run twice.

This is where a software response becomes an integration problem. A correct prediction still needs the right interpretation by the machine receiving it. Accurate feedback about the last movement helps keep the model’s next request tied to the physical scene.

The hardware guide describes a Universal Robots reference configuration using UR5, UR5e or UR7e arms, a Robotiq 2F-85 gripper and a Linux control computer. Separate instructions cover Franka hardware. The camera options include the Insta360 Ace Pro 2 and DJI Osmo Action 6 with the specified lens accessories.

The wrist view matters as much as the device connection. PokeBot’s guide treats fisheye distortion, camera placement and the gripper’s position within the image as part of the expected input. Increasing an ordinary perspective camera’s field of view does not reproduce the same projection.

That helps explain why changing robot hardware involves more than changing an address in a configuration file. The model must receive a useful view of the workspace, and the controller must interpret the output in the intended frame. Standardizing those interfaces is part of making a model portable.

The calibration procedure records a Home pose and three points on a level reference surface. Those measurements map the arm’s poses into the model’s coordinate frame. The instructions call for recalibration after changes to the tool assembly, Home pose or task axes.

For evaluation, this distinction is consequential. If the camera geometry or coordinate mapping is wrong, a failed grasp can reveal a setup error rather than a model limitation. Keeping the physical configuration consistent makes comparisons between attempts more informative.

PokeBot also provides a hardware adapter route for additional robots. Developers implement interfaces for the arm, parallel gripper and wrist camera, including measured feedback, target updates, recovery and cancellation. Existing components can be reused where suitable. The generated project provides a structure; its driver methods still require implementation.

PokeBot reports success rates of 86.0% for moving and organizing objects, 54.1% for pose and shape alignment, and 87.7% for environment interaction on its own benchmark. It describes nearly 1,000 object instances and nearly 10,000 instructions. These are company reported results.

The gap between categories is useful context. Even within the company’s evaluation, performance varies materially with the kind of manipulation involved. Treating a single successful task as evidence for every other task would lose that distinction.

Coverage by 42HOW Robotics also describes the public preview and its hardware transfer claims, drawing on PokeBot’s materials. That reporting corroborates the announcement; the performance evidence remains the developer’s own evaluation.

Black Scarab’s analysis is that outside testing is the more important next step. Repeated attempts on a documented setup can show how performance changes with object placement, task wording and interruptions. A collection of successful clips answers a narrower question than a record of all attempts.

The supplied runtime runs on the Linux computer connected to the arm, camera and gripper, with access to the model service. Its local console lets the developer manage the connected equipment and send tasks.

The operating instructions distinguish a configurable motion range from a physical barrier. They also warn that closing the browser does not stop a running task. Stopping requires the designated robot stop control or shutting down the local service.

Those details help define the responsibilities around an action model. Task interpretation, device control and stopping behavior have to work together. The interface can make model access easier while leaving the surrounding physical system essential to dependable execution.

The current noncommercial boundary makes this an evaluation opening. It gives researchers a way to examine a model while keeping commercial deployment a separate milestone.

For the wider industry, the meaningful signal will be a growing body of reproducible outside results: which tasks transfer, how often they succeed, what causes failures and how much adaptation a new robot requires. Those observations would make the claim of generalization easier to assess.

Outside results will show whether easier access translates into repeatable robot performance.