Wandelbots connects robot application development with industrial execution

Wandelbots develops NOVA, a software platform for creating robot applications and running them across supported industrial robot systems. Its value is a common development and execution layer, with an important commercial boundary between pre-production development and physical production use.

01 / ProductNOVA brings software development closer to robot execution

The NOVA platform overview describes three connected concerns: an operating layer for robot execution, tools for building applications and cloud services for managing access and instances. Python tooling, APIs, simulation connections and visual orchestration are presented as ways to develop around that execution layer. The practical attraction is a shared interface for work that otherwise changes with each robot environment.

NOVA does not remove the original robot controller. The 26.7 execution model explains the division between planning, execution and the underlying controller, which still performs low-level robot control. An application supplies motion intent and receives execution state; the physical controller remains responsible for operating its hardware. This boundary is central to understanding both integration and commissioning.

The company website frames this as physical AI infrastructure. That framing includes connecting learned policies or higher-level applications to motion, but it should not obscure the simpler use case: writing and maintaining industrial robot applications through a common software layer. A buyer can assess that benefit without assuming a general-purpose AI policy is already qualified for its production task.

02 / AudienceA platform choice for developers with a real robot application

The clearest audience is an integrator or internal automation team that wants to reuse application logic across supported hardware. A machine-tending application may contain similar sequencing, operator interaction and state handling even when robot brands differ. A common API can make that logic easier to organize, provided the team still accounts for each machine’s reach, tooling and controller behavior.

The current robot setup guide covers ABB, FANUC, KUKA, Stäubli, Techman, Universal Robots and Yaskawa. This is a documented ecosystem, not a universal compatibility promise. The particular controller, firmware, connection method and installation prerequisites matter more than seeing a manufacturer’s name on a list. Virtual development support should also be checked separately from the intended physical configuration.

NOVA is less clearly justified when the requirement is one fixed cell that an existing integrator can deliver and maintain with familiar tools. Introducing another development layer has value when it simplifies a recurring problem. The team should be able to name the application logic it wants to reuse, the people who will maintain it and the deployment process that will benefit.

03 / WorkflowA proposed application moves from a virtual cell to controlled execution

Consider a proposed application that transfers parts between a fixture and a machine. A developer first models the robot and relevant geometry in a virtual environment, then defines the application’s states: ready, approach, grasp, transfer, release and recovery. This is an evaluation example, not a workflow tested by Sequenced. It gives the common API a specific job instead of asking whether the platform can automate a factory in general.

In the documented execution model, planning context includes robot kinematics, movement limits, collision information and other constraints. The planning stage produces a trajectory, while execution communicates progress and state over the supported interface. The API documentation therefore gives developers a way to distinguish “a path was calculated” from “the robot finished the intended operation.” The application must react to that distinction.

The platform overview also describes streaming short motion sequences from an outside planner or policy. For an AI application, that is a potential connection point between a learned decision process and industrial execution. It is not, by itself, evidence that any external policy is safe or reliable on a real machine. The evaluation should define permitted commands, state transitions and interruption handling before adding a variable policy.

Before connecting physical hardware, the team follows the versioned setup and intended-use requirements. The safety guidance says NOVA must not replace the original robot controller and requires the safety controller to be configured before use. The proposed commissioning process should verify the whole cell, including tooling, access and machine interactions. A virtual trajectory is useful evidence, but it is only one part of that work.

04 / PricingDevelopment access and production operation use different licenses

The license documentation is unusually important to the buying decision. Installing and accessing NOVA without a license does not permit using virtual robot controllers or connecting robots. Licenses are assigned through Customer Success. Developer licenses are user-based and limited to pre-production development; robot licenses are based on physical robots and cover physical demonstrations and production.

Both license types are described as annual and automatically renewing. The documented developer allocation includes two cloud instances and one VM or bare-metal instance, while robot-license deployment quantities can be customized. Admins and Developers require licensed seats; Operators do not consume paid seats. These published distinctions are more useful for planning than inventing a per-robot price that the page does not disclose.

Activation and deactivation require internet access, and the developer license lists offline use for up to 60 days. Production offline allowances are custom. Licenses cannot normally be paused or suspended. An integrator should therefore settle the relationship between development seats, installed robot rights and disconnected-site needs before treating a successful virtual prototype as a licensed production deployment.

05 / DistinctionsThe useful distinction is a common execution layer with explicit control boundaries

Viam is a useful adjacent comparison for developers connecting software, devices and fleet operations. The question for a NOVA evaluation is narrower: whether its robot-motion interface and supported controller integrations simplify the particular application. Reusing business logic, device integration and physical motion are related engineering goals, but they need not be solved by the same platform.

Vention offers another comparison for a buyer starting from the need to build an automation cell. NOVA is most compelling when the team wants to own and develop software around robot execution. A buyer who primarily wants configured equipment and a commissioning partner may place more weight on the complete cell-building and delivery relationship.

The roles documentation also gives the platform an operational dimension. Admin, Developer and Operator roles separate management, development and routine use, with access scoped around instances. That can help an organization avoid giving every operator the same powers as the application developer. Integration and API-token availability is described as request-based, so automated administration should be confirmed rather than assumed.

06 / QuestionsCheck controller support, planning behavior and lifecycle ownership

The first uncertainty is the exact physical setup. A robot-brand abstraction can reduce application differences while leaving controller preparation, networking and capabilities different. Before committing to a fleet-wide approach, take one representative controller from each intended family through the documented setup. The outcome should be a supported configuration list that the operations team can maintain.

The second is what happens when planning cannot produce the desired motion. The execution-model documentation includes limitations and fallback behavior, so an application should not interpret a planning response as blanket proof of collision-free operation. Ask how failures, alternative paths and unavailable trajectory combinations are represented in the specific API version. The developer needs an explicit response for those states.

The third is change management between virtual development and installed production. A revised application, geometry model or external AI policy can alter motion behavior even if the robot hardware stays the same. Define who approves the application version, how a site can return to a previous version and what evidence is retained after commissioning. These are consequences of adopting programmable execution infrastructure, not reasons to avoid it.

07 / DecisionChoose NOVA when reusable robot software is the objective

Wandelbots is worth evaluating when the organization wants a maintained software layer for developing and deploying robot applications across a documented ecosystem. Begin with one application that exposes the intended reuse, verify the physical controller configuration and settle production licensing before moving beyond the virtual stage. The decision should rest on development and operating benefits that the team can demonstrate in its own environment.