Realtime Robotics optimizes industrial robot motion before and during production

Realtime Robotics develops software for planning and optimizing industrial robot motion. Resolver works with simulated cells in the cloud; RapidPlan addresses motion during execution. The distinction matters because an offline optimization study and a deployed runtime controller solve different engineering problems.

01 / ProductTwo products address different moments in the robot lifecycle

Realtime Robotics is the industrial robotics company operating at rtr.ai. Its company page describes its robot-motion focus, while the current homepage presents Resolver and RapidPlan as the principal offers. The useful category is software for making physical robot movements more workable, rather than a general AI assistant for factory staff.

Resolver takes an existing simulated cell and searches for improved motions and coordination. The product describes optimization of robot paths, interlocks and task allocation, with results returned for engineering validation. Its scope is especially relevant where changing one robot’s route affects the routes available to other robots. Optimizing an isolated move may not improve the cell if a different machine still determines the pace.

RapidPlan operates closer to execution. Realtime describes active operation, in which it responds to application requests and sensor inputs, and passive operation, in which it supplies motion plans to another control system. That is a meaningful deployment choice: the party responsible for issuing movement commands and responding to abnormal state must remain explicit.

The company markets these products using AI and automation language, but the reader decision is concrete. Does the engineering team need a better plan for a known cell, or must the running cell respond to changing movement requests? The answer determines the product discussion, the integration effort and the evidence required before accepting a result.

02 / AudienceThe strongest fit is a cell whose motions constrain one another

A multi-robot assembly or handling cell can accumulate conservative waiting rules as engineers avoid collisions and resolve interference. Resolver is relevant when those choices leave room to reconsider paths and sequencing together. A team with a reliable baseline model can compare a proposed arrangement against that baseline, rather than treating any faster simulated animation as proof of a production improvement.

The Resolver overview makes the simulation relationship tangible: a study contains scene data and queries defining what to solve. Engineering organizations already maintaining digital cell models have a clearer route into this workflow than a factory with only incomplete drawings and undocumented robot routines. Preparing a trustworthy model can be the larger job.

RapidPlan is more relevant when a cell needs to respond to differing requested destinations or changing sensed conditions during operation. That does not imply that every factory requires dynamic planning. A stable, simple sequence may be easier to maintain with existing tools. The comparison should consider how often useful movement choices actually change and how expensive the current programming approach is.

03 / WorkflowA proposed Resolver study starts with a model that can be checked

Consider a proposed optimization of a cell where two robot arms share an access zone. First, the integrator establishes a baseline using the installed robot geometry, end effectors, surrounding equipment and intended tasks. That baseline needs a clear definition of cycle time, including the machine waits that robot motion alone cannot remove. This is a proposed evaluation workflow, not a study performed by Sequenced.

The documented study package separates project scene information from optimization requests. The user guide names project.yaml for the scene and queries.json for solve requests inside the uploaded study archive. This distinction helps explain why geometry and objectives both matter: a faithful cell model does not by itself say which sequence, constraints or tradeoffs the optimizer should prioritize.

The team then submits the study through the supported workflow, reviews candidate results and brings the selected result back into its simulation environment. Realtime’s Resolver description presents export and validation as part of the process. The engineering review should inspect changed clearances, coordination assumptions and cycle boundaries before considering implementation on the physical cell.

For RapidPlan, the proposed evaluation would additionally exercise execution-state transitions. What happens if a requested destination is unavailable, a sensor changes the scene or another controller stops the cell? Planning an available route and deciding whether the whole machine may move are different responsibilities. A useful demonstration includes these handoffs as well as ordinary point-to-point motion.

04 / PricingCommercial access depends on the product and connector

Realtime’s trial page invites a request, and its contact page provides the sales route. We did not find a public numerical tariff on those pages. A free-trial invitation does not establish unrestricted production use, guaranteed account acceptance or the cost of ongoing compute and support. Those terms should be settled for the intended study and deployment.

Current documentation also changes the access picture. The Resolver overview directs Process Simulate users to request an account and labels Visual Components access as early access, despite listing supported versions. It says MELSOFT Gemini connector support is ending: connector 1.23.0, released with Resolver 2026.09.21, is the last maintained version, with backward compatibility for 60 days before compatibility testing ends. A new Gemini dependency therefore needs a migration discussion.

The quotation should separate a Resolver evaluation from a RapidPlan production deployment. A design team may need temporary study capacity, while a running cell needs clearly defined runtime, integration and support arrangements. The public pages establish the offers and inquiry routes, but they do not provide enough detail to calculate a defensible total cost for either scenario.

05 / DistinctionsMotion optimization is a distinct layer within factory software

Siemens is a useful adjacent comparison for teams already working in a broad industrial software and automation environment. Resolver’s relationship with Process Simulate illustrates how a specialized optimization tool can sit within an existing engineering workflow. The decision is whether that extra optimization step improves a meaningful constraint, while leaving the team able to inspect and maintain the resulting cell design.

KUKA provides a different comparison: the robot platform, control environment and application equipment remain essential parts of the installed system. Realtime’s software should be judged on the motion-planning work it contributes. A cross-platform planning proposition does not make every robot model, controller release or surrounding device interchangeable.

The offline-versus-runtime distinction is a particular strength of the product framing. A manufacturer can ask for evidence about a bounded design improvement without assuming it must introduce a new live control dependency. Conversely, a genuinely variable process can be evaluated as a runtime integration problem, with the stronger commissioning requirements that follow from making decisions during operation.

06 / QuestionsCurrent connector support and model fidelity decide usefulness

Connector status deserves verification at the beginning of a project. A previous announcement of an integration is not a guarantee that its maintenance continues. The current Gemini notice and Visual Components early-access wording are examples of details that can change the practical path from a promising demonstration to an approved engineering tool. Ask which exact release combination will remain supported during the planned project.

Model fidelity is the second major uncertainty. Missing obstacles, inaccurate tooling geometry or unrealistic timing assumptions can produce an attractive simulated result that fails to transfer to the installed cell. The evaluation should identify who owns those inputs and how changes are checked. The software’s collision-avoidance language should not be interpreted as independent certification of the whole machine.

Finally, distinguish completed features from roadmap items. The Resolver product page labels automatic robot positioning and end-of-arm-tool selection as coming soon. Those may inform a later conversation, but the first project should be valuable using the capabilities that are available to the customer today. A procurement decision that requires a future feature needs a separate delivery commitment.

07 / DecisionChoose the planning stage before choosing the engagement

Realtime Robotics deserves consideration when robot coordination is a measurable engineering bottleneck and the team has a model or execution interface it can validate. Start with a defined constraint, establish the current supported toolchain and require a result that can be inspected in the surrounding automation environment. That creates a clearer decision than comparing broad AI claims or assuming every simulated improvement becomes production output.