Spring and Physical AI for Beginners: Build a Tested Robot Mission Coordinator

A warehouse employee asks a robot to bring a parts bin to the packing station. The request sounds simple. The software has to answer several different questions: What does the employee mean? Is the destination allowed? Is the observation current? Did the robot accept the job? Did the bin actually arrive?

This is where Physical AI becomes interesting for Java developers. A model can help interpret a situation or propose an action. A useful application also needs business rules, interfaces, state, feedback and understandable failure handling. Those are familiar concerns in Spring applications.

Spring can coordinate a Physical AI application, but a Spring service is not a robot motion controller or an independent physical safety system. Understanding that boundary is the foundation of this guide.

We will build a small Spring Boot application that submits delivery missions to a deterministic robot simulator. It includes a real Spring AI tool definition and callback test, without requiring an AI subscription, API key, GPU or robot. The simulator is a teaching fixture, not a learned policy or a physics simulation. You will learn the integration boundary before adding expensive or unpredictable components.

Research checked on October 30, 2026. The architecture and warehouse scenario below are proposed learning material. Vendor demonstrations are identified as such; the code does not reproduce their robotics capabilities.

1. What is Physical AI?

For this article, Physical AI means AI used in a system that perceives a physical environment and influences it through actions. A robot might combine camera images, a task description and learned behavior to decide how to pick up an unfamiliar object. The system then needs fresh feedback to determine whether the action worked.

The core loop is observation, interpretation, decision, action and another observation. An answer in a chat window can be useful without changing anything outside the application. A robot moving a bin changes the environment. That change can make the previous observation obsolete.

Several terms appear frequently:

Term	Beginner explanation	Example in our warehouse
Perception	Turning sensor input into an estimate of the current situation	Recognizing a bin or estimating whether an area is occupied
Policy	A rule or learned mapping for choosing actions from observations	Selecting the next grasping movement
Vision-language-action model, or VLA	A model combining visual input and language with action output	Using an instruction and camera view to produce robot actions
World model	A model of how an environment may evolve	Predicting what might happen after a movement
Digital twin	A digital representation linked to a particular physical system	A calibrated model of one work cell
Simulation	A controlled environment for experimenting with behavior	Testing a route under different obstacle layouts
Orchestration	Coordinating tasks, rules, services and their outcomes	Creating a delivery mission and tracking its result

These are working explanations, not claims that every product uses the same architecture. A fixed conveyor with ordinary control logic does not become an AI system merely because its status is shown in a Java dashboard. Conversely, an AI model alone does not provide all the mechanisms needed to operate a warehouse robot.

It helps to separate three questions. Can the model understand the task? Can the robot execute the relevant skill? Can the complete system authorize, observe and account for the operation? Our Spring project concentrates on the third question.

2. Why this is a timely Spring topic

The most relevant trend for Homann Software's Java and systems engineering audience is connecting embodied AI to dependable business workflows. That is an editorial assessment based on the developments below, rather than a measured market ranking.

Physical reasoning and simulation are moving closer together

Google's October 13, 2026 article, Gemini 4 Argon for Robotics, demonstrates work spanning robot control, reconstruction of simulation environments, physical understanding and iterative improvement. One example uses a digital model to practice a task before physical execution; another repeatedly checks camera observations during manipulation. These are vendor demonstrations, not evidence that arbitrary robots can perform arbitrary warehouse tasks reliably.

The lesson for an application developer is concrete: the application needs to represent observations and outcomes, not just send a natural-language instruction and accept a confident response. The demonstrations also explain why simulation deserves its own place in the development process. A successful simulated action remains evidence about that simulation and its assumptions.

Robotics platforms are expanding beyond an isolated model

NVIDIA's March 16, 2026 robotics ecosystem announcement connects its Cosmos world models, Isaac simulation frameworks and GR00T robotics models with industrial partners. It illustrates a broader engineering stack involving data, simulation, models and deployment. The announcement is a vendor source, and its deployment statements should be read in that context.

For this tutorial, the useful distinction is between training or evaluating robot behavior and integrating that behavior with an order, operator or production workflow. Buying access to a model does not automatically solve the integration work.

Spring's AI integration has a current stable baseline

Spring's October 23 release announcement identifies Spring AI 2.0.2 as a maintenance release and 2.1.0-RC1 as a release candidate. The candidate adds features including tool-call confirmation. We use 2.0.2 in this example, so none of the code depends on that candidate feature. Spring Boot 4.1.2 was also announced on October 23.

Spring AI 2.0 established a Boot 4 baseline and made the tool-calling loop part of the advisor chain, as described in its GA announcement. That makes Spring relevant to AI application integration. It does not establish built-in compatibility with every robotics model or robot controller.

The existing Homann article on Physical AI and the Tesla Roadster discusses a different application and its control boundaries. This guide takes a distinct beginner angle: an executable Spring mission coordinator, a harmless proposal tool and a simulated delivery outcome.

3. Where Spring belongs

Figure 1. Proposed systems architecture. The downloadable application implements the mission coordinator, proposal tool and deterministic robot adapter. The hardware and middleware blocks are context for a future integration.

Spring Framework provides the programming infrastructure for our Java components. Spring Boot starts and configures the application. Spring MVC exposes HTTP endpoints. Bean Validation checks basic request fields. Spring AI supplies the tool annotation and callback machinery used in the optional proposal boundary.

In a larger system, Spring might also connect a warehouse management system, maintain mission records, integrate operator permissions and publish business events. Those are possible extensions, not implemented features of the download.

A robot runtime has another job: navigation, skill execution and feedback near the machine. ROS 2's action design describes long-running goals with feedback, results and cancellation. That is a useful conceptual match for delivery missions. This project does not include ROS 2, a ROS bridge or cancellation; an actual adapter would have to map those semantics deliberately.

Physical safety functions require their own engineered mechanisms. An HTTP service reading a Boolean called stopActive cannot guarantee that a robot will stop at the right time. The observation can be delayed, the network can fail and the situation can change immediately after a check. Our admission rules are application rules for a learning exercise. They are not a safety case.

This division also clarifies timing. Submitting a delivery objective is different from maintaining a motor control loop. We make no hard real-time guarantee for the Java application. We also make no latency comparison between Java and other languages: no such benchmark was performed.

4. The beginner scenario: deliver one parts bin

Imagine a small workshop with two named destinations: PACKING and INSPECTION. An operator submits a mission with a request identifier. The coordinator obtains an observation, checks its admission rules and sends a command through RobotGateway.

The rules are intentionally small enough to understand:

1. A destination must be on the allowlist.
2. A request identifier must contain 1–64 letters, digits or hyphens.
3. The observation must have a timestamp, must not be future-dated and must be at most two seconds old.
4. The reported cell must be clear and its reported stop signal inactive.
5. Only one active or unresolved mission is admitted in this process.
6. Repeating the same request identifier and destination returns the existing mission.
7. Reusing that identifier for another destination is rejected.
8. A delivery is successful only after the adapter reports DELIVERED.

The two-second observation window and ten-second result timeout are arbitrary teaching values. A real application would derive timing requirements from its equipment, clocks, communications and operating environment.

The same point applies to destinations. A name such as PACKING is a business concept. A real robot needs a maintained mapping to an approved map location or skill. We do not accept model-generated coordinates or executable code as a shortcut around that mapping.

Our simulator returns a fresh ready observation. Its first outcome poll returns RUNNING; its second returns DELIVERED. Poll count drives that behavior, so this is a deterministic contract fixture. It has no geometry, dynamics, camera, collision detection or machine learning. That makes it inexpensive to run and clear to reason about, while also sharply limiting what its results prove.

Watch the mission develop

5. Set up and run the example

Download the runnable Spring project and editable diagram sources. The archive includes the Maven project, tests, a PowerShell HTTP demonstration, PlantUML source and a BPMN 2.0 file with diagram interchange information.

The tested baseline is Java 21, Maven 3.9.11, Spring Boot 4.1.2 and Spring AI 2.0.2. You need a JDK and Maven on your path. The first build needs internet access to retrieve dependencies from Maven Central. After extracting the archive, open a terminal in examples and run:

mvn verify
mvn spring-boot:run

The application binds to 127.0.0.1:8080. It is a local lab with no authentication and no physical robot connection. If another application uses that port, stop it or choose another port and adjust the demonstration URL.

In a second PowerShell terminal, submit a delivery and poll it twice:

$baseUrl = 'http://127.0.0.1:8080'
$body = @{ requestId = 'demo-1'; destination = 'PACKING' } | ConvertTo-Json
$mission = Invoke-RestMethod -Method Post -Uri "$baseUrl/missions" `
    -ContentType 'application/json' -Body $body
$mission.status
(Invoke-RestMethod -Uri "$baseUrl/missions/$($mission.id)").status
(Invoke-RestMethod -Uri "$baseUrl/missions/$($mission.id)").status

The expected sequence on a fresh application instance is:

DISPATCHED
DISPATCHED
SUCCEEDED

An HTTP 202 Accepted response reports the coordinator's mission representation. It does not certify delivery. The simulator is what supplies the later delivery result.

Repeat the original POST and the same mission identifier comes back. Change the destination while keeping demo-1 and the application returns 409 Conflict. A blank required field produces 400 Bad Request; an unknown mission identifier produces 404 Not Found.

The GET endpoint refreshes mission status. In this teaching simulator, that read also increments a fixture poll counter. A production status endpoint should read maintained mission state or query a real adapter without using the number of HTTP reads to manufacture progress.

6. Understand the Java implementation

Start with a replaceable robot boundary

The coordinator knows an interface, rather than a specific robot vendor:

public interface RobotGateway {
    record Observation(Instant observedAt, boolean zoneClear, boolean stopActive) {}
    enum Outcome { RUNNING, DELIVERED, FAILED }
    Observation observe();
    void submit(UUID commandId, String destination);
    Outcome outcome(UUID commandId);
}

This is an excerpt from the compiled project; its imports are in the download. Observation is an immutable Java record. Outcome is a small vocabulary shared by the coordinator and adapter. A UUID identifies a command independently of any human wording.

The interface does not claim that a controller's acknowledgement is proof of a physical outcome. It provides separate operations for submission and outcome observation. A real adapter must define where its DELIVERED evidence comes from: a navigation result, station sensor, operator confirmation or some combination. A model saying “done” is not automatically suitable evidence.

Check observations after receiving them

The service receives its Clock through the constructor. Tests can supply a fixed or adjustable clock, making the timing rules reproducible. The admission check uses the time after obtaining the observation:

RobotGateway.Observation observation = robot.observe();
Instant now = clock.instant();
if (observation == null || observation.observedAt() == null)
    throw new Rejected("Missing observation");
Duration age = Duration.between(observation.observedAt(), now);
if (age.isNegative() || age.compareTo(Duration.ofSeconds(2)) > 0)
    throw new Rejected("Observation is stale or future-dated");
if (observation.stopActive() || !observation.zoneClear())
    throw new Rejected("Robot cell is not ready");

The order matters. If you capture now before asking a simulator for an observation timestamp, an observation created moments later can appear to come from the future. The integration test caught that issue during development, and the final code obtains now after the observation.

With remote hardware, this simple rule would also require an explicit clock synchronization and timestamp contract. Strict future rejection is a teaching choice, not a universal distributed-system policy. More fundamentally, a fresh clear observation is only a snapshot. Continuous local monitoring remains necessary in a real robot system.

Reserve a request before external I/O

Suppose the robot accepts a command but the acknowledgement disappears. Automatically issuing a new command could duplicate physical work. The lab therefore stores a mission before calling the gateway:

Mission mission = new Mission(id, requestId, destination, Status.DISPATCHED, now);
byRequest.put(requestId, mission); keys.put(id, requestId);
try { robot.submit(id, destination); }
catch (RuntimeException uncertain) {
    mission = new Mission(id, requestId, destination, Status.UNKNOWN, now);
    byRequest.put(requestId, mission);
}

UNKNOWN means the coordinator cannot establish a reliable result. It does not mean the robot is stationary, that the command failed or that retrying is safe. The lab retains the reservation and rejects new missions while an unresolved mission exists.

Repeated requests with the same key return that reservation. They do not submit a second command. This behavior is tested within one application process. Both the reservation map and the simulator's command map disappear on restart, so the example provides no durable or distributed exactly-once guarantee.

The service methods are synchronized to make the single-process exercise straightforward. They hold a lock while calling the adapter. A blocking remote adapter would make that a poor production design: use bounded I/O, durable state transitions and concurrency control designed around external work.

Keep mission states honest

The state model distinguishes four statuses:

Status	Meaning in the lab	Can another mission start?
DISPATCHED	Submission completed without an exception; delivery is unconfirmed	No
SUCCEEDED	The adapter reported DELIVERED	Yes
FAILED	The adapter reported FAILED	Yes, in this simplified model
UNKNOWN	Submission or outcome is uncertain, or the result is overdue	No

In a real installation, even an explicit failure may require inspection or recovery before releasing the robot. The lab omits that recovery model. It also omits cancellation, charging, multiple robots and route planning.

When an active mission remains RUNNING for more than ten seconds, a status refresh changes it to UNKNOWN. This is checked on polling, not by a background timer. If no one refreshes status, no timeout transition happens. Once unknown, a later DELIVERED or FAILED report can reconcile the mission. A RUNNING report alone keeps it unresolved.

7. Add a bounded Spring AI tool

Now consider the instruction, “Bring this parts bin to packing.” An optional model could interpret that sentence and select a business destination. We expose only a proposal operation at this stage:

@Tool(description = "Propose a parts-bin destination. Does not move a robot or submit a mission.")
public Proposal proposeDelivery(String destination) {
    if (!java.util.Set.of("PACKING", "INSPECTION").contains(java.util.Objects.toString(destination, "")))
        throw new MissionService.Rejected("Destination is not allowed");
    return new Proposal(destination, true);
}

The returned record contains the destination and requiresOperatorSubmission=true. That flag explains the proposal's status; it does not enforce approval by itself. The important boundary is structural: this tool has no reference to MissionService or RobotGateway, so calling it cannot dispatch a mission.

Spring AI's tool-calling reference explains that the model requests a tool call while the application executes it. That leaves the application responsible for controlling the capabilities behind its tools. The lab verifies an actual Spring AI callback:

var callbacks = ToolCallbacks.from(tools);
String result = callbacks[0].call("{\"destination\":\"PACKING\"}");
assertTrue(result.contains("PACKING"));
assertTrue(result.contains("true"));

This test checks annotation discovery, schema creation and JSON argument execution against Spring AI 2.0.2. It does not test natural-language understanding, model tool selection or an entire conversation. No ChatClient, model provider or model API request is included in the runnable application.

To extend it, first build an evaluation set of representative instructions and expected destination proposals. Include ambiguity, unsupported stations, malicious text and conflicting instructions. Then connect a provider through a separate proposal adapter and evaluate it against that set. Keep the operator's authorized submission separate from the model's output, and bind permissions to the authenticated operator rather than a name supplied by the model.

A prompt such as “Always ask before moving” is not an access-control mechanism. An adapter with no dispatch capability is a stronger starting boundary. Likewise, model-produced JSON still needs validation: valid JSON can contain an unauthorized destination or a request based on outdated observations.

8. Read the UML and BPMN views

Figure 2. UML sequence view of the normal simulator path. The editable PlantUML source also shows the alternative UNKNOWN outcome.

The UML sequence answers “Who calls whom?” The operator submits a request to the HTTP controller. The controller delegates to MissionService. The service checks the observation and calls RobotGateway. Later, polling asks for evidence about the command's outcome.

The separation between the initial response and later status is the essential detail. Returning successfully from submit is not the same event as receiving DELIVERED. The architecture must preserve that distinction even if a conversational interface makes the interaction feel like a single request.

Figure 3. BPMN 2.0 business process sketch. The source is a non-executable model with explicit decisions and layout data; the Java code does not run a BPMN engine.

BPMN answers a complementary question: “What can happen to the delivery request?” A rejected admission ends without command submission. An admitted request proceeds to outcome observation. RUNNING returns to observation; delivery, failure and uncertainty have separate endings.

The diagram is deliberately a business-level summary. A lost submission acknowledgement is represented by the uncertain outcome path rather than a detailed technical exception model. The service code reserves the mission before sending and immediately records UNKNOWN if submission throws. Physical safety behavior and equipment recovery are outside this process sketch.

For a beginner, the two diagrams support different conversations. Use UML with someone implementing adapters and tests. Use BPMN with the operator or process owner to establish what “finished,” “rejected” and “needs review” should mean. Neither diagram substitutes for a detailed hardware integration specification.

9. What has actually been tested?

The packaged Maven verification runs 28 tests: 22 mission-service tests and six Spring application, HTTP and tool-callback tests. They exercise behavior with deterministic observations and outcomes, rather than asserting that a model's prose looks plausible.

The mission tests cover acceptance without premature success, observed delivery, terminal failure, stale and future timestamps, the exact two-second age boundary, missing observations, missing timestamps, occupied zones, active stop reports, invalid destinations and request identifiers. They also cover duplicate requests, conflicting payloads, active-mission exclusion, lost acknowledgements, reconciliation, unavailable results, overdue outcomes, unknown mission identifiers and release after completion.

One concurrency test submits sixteen identical requests through eight worker threads and checks that they produce one mission identifier and one gateway submission. This is evidence for the single-instance synchronized implementation. It says nothing about multiple application replicas or recovery after a crash.

The Spring tests start an application context and use MockMvc to verify HTTP validation and response behavior. The callback test invokes the actual Spring AI tool adapter without an external model. A separate localhost HTTP demonstration exercises the packaged application through a real network socket.

These checks verify the coordinator's tested contracts. They do not prove collision avoidance, robot reliability, perception accuracy, a calibrated digital twin, AI reasoning quality or safety certification. No physical equipment, ROS runtime, VLA inference or commercial model service was used. That limit is part of the result, not a footnote to ignore when deploying.

For your own changes, begin by writing the scenario in business terms. For example: “When acknowledgement is lost, repeating the request must not issue a second command.” A test that captures that outcome is more useful than a test that merely checks whether a method was called somewhere.

10. What changes when you connect a real robot?

Persist identity and uncertainty

A production coordinator needs durable mission records and a unique constraint on the request identifier within a defined tenant or caller scope. Store the request's relevant payload so a reused identifier cannot silently mean another task. Plan how the coordinator recovers a mission that was reserved before a crash.

The robot side must also define duplicate-command handling. A transactional outbox can help carry durable intent from a database toward an adapter; it does not make an external movement transactional. If a connection fails after submission, reconcile using the original command identifier. Do not replace uncertainty with a fresh command identifier merely to make a retry appear successful.

Define what observation and completion mean

Write down the timestamp source, coordinate frame, units, equipment identity and expected freshness of every observation. A Boolean named zoneClear is deliberately too small for most real installations. A physical integration may require richer sensor quality, validity intervals and equipment state.

Likewise, distinguish “goal accepted,” “robot reached a position,” “bin transferred” and “recipient confirmed delivery.” Choose the evidence that matches the business requirement. An attractive dashboard can otherwise report success while the important work remains unfinished.

Separate authority and communication

Authenticate operators and service clients. Authorize the relevant robot, destination and operation in application code. Restrict the network paths and robot credentials available to each adapter. An optional AI proposal service should receive only the information and capabilities its task requires.

For model input, treat signs, camera text, retrieved manuals and operator notes as untrusted content. A visual instruction on a box should not be able to redefine authorization rules. Retain enough information to reconstruct which input led to a proposal, while handling camera data and operator information according to the organization's actual requirements.

Engineer operation and recovery

Remote calls need timeouts and cancellation semantics. A real mission can outlive an HTTP request. Use asynchronous work and durable state where that is appropriate, and define which actor resolves unknown missions. Record business request identifiers, command identifiers, adapter events and timestamps so an operator can explain what happened.

Useful operational measures include the proportion of missions with confirmed delivery, time spent unresolved, frequency of duplicate requests, rejected stale observations and operator interventions. Select measures before the pilot and avoid publishing speed or productivity claims until they have been measured in the actual environment.

Finally, work with the equipment and safety specialists responsible for the installation. Software admission checks complement a broader engineered system. Connecting this tutorial to hardware is a new engineering project, not a configuration toggle.

11. A practical learning path

Start with the download exactly as it is. Run the tests, submit one mission and observe the three-step status sequence. Repeat the same request. Change its payload. Read the corresponding service tests and predict the result before running them.

Next, add one business rule, such as an operator-visible mission description or another approved station. Update the contract and test the rejected cases as well as the successful path. Keep robot geometry out of this stage.

Then improve the mission lifecycle: add durable storage, a recovery view and an explicit resolution process for uncertainty. Test restart and adapter failure scenarios before adding an AI provider. This order makes it easier to identify whether a failure belongs to mission coordination or model behavior.

Only then add a model-backed proposal adapter. Compare it against a fixed set of instructions, keep the tool bounded and display the proposal for authorized submission. Once that is understood, explore a robot simulator or a documented middleware adapter with a clearly defined scope.

Do I need Python to start?

Not for this project. The application and tests run in Java. Some robotics, simulation and model-training ecosystems use Python or C++; you can interact with such components through an explicit adapter when the task requires them. The choice should follow the component's responsibility and supported tools.

Does Spring AI make any robot intelligent?

Spring AI helps integrate AI capabilities into Java applications. It does not supply a universal robot skill, physical calibration or equipment-specific safety design. The annotated proposal method in this lab is ordinary application code exposed through a real AI tool mechanism.

Is this a complete Physical AI system?

It is a tested application integration lab for one part of such a system. Its simulated adapter and direct tool callback let you learn without physical actions or model costs. A complete system would add perception, appropriate robot behavior, physical feedback, equipment integration and the required operating controls.

Why not let the model call the robot directly?

Some research demonstrations expose robot primitives to a model. Our beginner design deliberately gives the model only proposal authority, because understanding an instruction and authorizing movement are different responsibilities. You can expand the design later after specifying the additional authority and evaluating the consequences.

The practical starting point is small: give a business request a stable identity, keep uncertain outcomes visible and verify completion from an appropriate source. Spring provides a useful place to implement that coordination. Physical AI becomes easier to understand when each component's responsibility is explicit and each reported result has evidence behind it.