Modern robotics stacks: ROS 2, simulation and AI

By Marco Lopes · Published April 20, 2026 · Hardware & Gear

A robot is a distributed software system with physical consequences. Sensors arrive late, networks disappear, batteries sag and the real world refuses to behave like a clean demo environment. Adding AI expands what a machine can interpret, but it also expands the number of ways it can fail.

At Kordspace, we approach robotics through our perspective as a remote collaborative software, AI, Web3, hardware and design studio. We want understandable interfaces, repeatable builds and explicit boundaries between intelligence and control. Not every capability in our toolkit belongs in every robot; unnecessary infrastructure only adds failure modes.

As of April 2026, ROS 2, modern simulators and edge inference give us useful building blocks. The challenge is connecting them into a system we can test, deploy and maintain. Here is how we structure that work.

Start with the mission and operating envelope

Before choosing a computer or a model, we define what the robot must accomplish and where it is allowed to operate. An indoor inspection platform and an outdoor manipulator have different sensing, power, environmental and safety requirements.

We write down the operating envelope: expected surfaces, lighting, weather, payload, human proximity, connectivity and charging arrangements. We also define failure behavior. Does a localization failure require a controlled stop? Can the machine finish an operation offline? Who can authorize recovery?

Our first deliverable is a small set of measurable acceptance tests. These might cover stopping distance under specified conditions, task completion, recovery from a disconnected sensor and safe behavior when a command expires. We establish thresholds from the application and risk assessment, not from generic benchmark claims.

This keeps component selection tied to the mission rather than to whichever development board or model looks most impressive.

Separate control, autonomy and cloud services

We organize the stack into three layers with different timing and reliability expectations:

• Control and safety: motor control, actuator limits, watchdogs and appropriately designed safety mechanisms.
• On-robot autonomy: sensor processing, localization, planning, perception and task execution.
• Cloud and operations: telemetry, dataset management, training, deployment coordination and fleet visibility.

These are responsibility boundaries, not necessarily three separate boxes. A microcontroller might handle a motor loop while a Linux computer runs ROS 2. The physical separation depends on the application, but the failure boundaries must remain clear.

We keep time-critical control local. A cloud request should not sit between detecting a hazard and responding to it. Similarly, a stalled perception process should not leave an actuator executing an old command indefinitely.

For every interface, we specify units, coordinate frames, timestamps, acceptable age and failure behavior. “Target velocity” is incomplete without a validity period and rules for rejecting stale or out-of-range values. These contracts often matter more than the choice of middleware.

Use ROS 2 as integration infrastructure

ROS 2 gives us conventions and tools for composing robot software. We use topics for streams, services for short request-response operations and actions for longer-running work that needs feedback and cancellation.

Distribution choice starts with hardware support. In April 2026, ROS 2 Jazzy is a useful long-term-support baseline where its operating system and driver support fit. We still verify every required package and vendor SDK before committing. A supported distribution does not automatically make every dependency maintained or compatible.

We treat middleware configuration as engineering work. Quality-of-service settings must match the data: a camera stream may prioritize fresh frames over complete delivery, while configuration state has different requirements. Incompatible publisher and subscriber settings can produce apparently healthy nodes that exchange nothing.

We standardize message definitions, namespaces, launch configuration and tf2 frame conventions early. Lifecycle nodes can help us coordinate initialization and activation, but they do not guarantee safe operation by themselves.

Finally, we measure latency and jitter on the target hardware. ROS 2 supports real-time-oriented designs; installing it does not make an application deterministic or safety-certified.

Choose hardware around sustained workloads

A development kit working on a desk is not yet a deployable robot computer. We evaluate sustained inference, memory pressure, thermal throttling, storage endurance, boot behavior and power transients together.

The compute decision follows the workload. We may need a GPU for perception, a smaller accelerator for constrained inference, or a CPU-only system for simpler autonomy. Vendor drivers and accelerator runtimes can constrain the operating system and ROS distribution, so we test that combination before designing around it.

We also budget for connectors, mounting, cable routing, electromagnetic interference and service access. These details affect reliability as directly as processor selection.

For remote collaboration, we make the bench reproducible: documented wiring, labeled devices, versioned firmware and a hardware inventory. We separate remote software access from permission to move machinery. A remote session is not a substitute for local supervision when the test requires it.

Make simulation part of development, not a demo

Simulation is most valuable when it answers specific questions. Can our navigation behavior recover from a blocked route? Does the planner respect joint limits? What happens when a sensor stops publishing?

For a ROS 2 Jazzy-based stack, Gazebo Harmonic is a common starting point. We may consider Isaac Sim when GPU-based rendering and synthetic perception data justify its requirements, or Webots when it better fits the platform and workflow. We evaluate integration effort, licensing, automation, hardware requirements and asset portability rather than declaring one simulator universally best.

We keep robot geometry, joint definitions, collision shapes and sensor frames under version control. Visual accuracy is not enough: incorrect inertia, friction or sensor timing can make a convincing simulation misleading.

Our test suite includes nominal missions and injected failures. We vary lighting, latency, noise, friction and obstacle placement, then check whether required behaviors still hold. For reproducible tests, we control random seeds and record simulator versions.

We also handle simulated time explicitly. Nodes must consistently use the intended clock, and tests should account for pauses, resets and time jumps. Simulation narrows uncertainty; hardware-in-the-loop testing and controlled physical trials remain essential.

Give AI a bounded role

We find AI most useful when its responsibilities are clear: detecting objects, estimating scene properties, interpreting instructions or proposing task steps. We avoid turning a model's output directly into unrestricted motor commands.

A practical pattern is interpret, validate, execute. A model proposes a structured action. A separate component checks its schema, permissions, preconditions and operating constraints. A controller then executes an approved operation with monitoring and cancellation.

For example, “inspect the charging area” might become a named inspection task with a destination and completion criteria. It should not become arbitrary generated code with access to every robot interface.

On-device inference reduces dependence on connectivity, but it creates resource contention. We benchmark perception alongside mapping, logging and planning, not in isolation. We define what happens when inference times out, produces uncertain results or consumes too much memory.

We version the model, preprocessing, labels and runtime together. A model update is a behavior change, even when its API is unchanged. Recorded-data evaluation and simulation are useful gates before controlled hardware testing and limited rollout.

Keep the cloud useful and out of the control loop

We prefer Google Cloud for the supporting platform when the project's constraints allow it. Cloud Storage can hold recordings and datasets, Artifact Registry can hold deployment images, and Vertex AI can support training and evaluation workflows. We use Cloud Run for suitable stateless APIs or processing tasks, and GKE where Kubernetes orchestration genuinely earns its complexity.

The robot-to-cloud boundary deserves a dedicated gateway. We generally avoid stretching ROS discovery and DDS traffic across the public internet. Instead, we expose a narrow, authenticated interface for telemetry, mission requests and update status.

Pub/Sub can support cloud-side event distribution, but it does not replace local robot messaging or deterministic control. We design store-and-forward buffering, retention limits and reconnection behavior so intermittent connectivity does not become data loss or uncontrolled disk growth.

AWS or Azure can support the same architectural separation when existing infrastructure or requirements favor them. Portability comes primarily from clean contracts and reproducible packaging, not from pretending managed services are interchangeable.

Record enough evidence to debug failures

Robotics failures cross subsystem boundaries. A missed turn might start with a timestamp mismatch, become a localization error and only later appear as a planning problem.

We record structured events alongside selected sensor and state data. ROS 2 bags are useful for playback and investigation, but recording every topic continuously can overwhelm storage and expose sensitive information. We choose channels, compression, retention and upload rules deliberately.

Time synchronization is part of observability. We distinguish capture time from receipt time and document clock sources. Across machines, we validate the synchronization method against the application's actual timing needs.

A useful incident bundle includes software versions, parameters, calibration identifiers, model versions and relevant logs. Without that context, replay may reproduce the data while missing the configuration that caused the failure.

Treat safety, security and updates as separate disciplines

Cybersecurity protects access and integrity. Functional safety addresses unacceptable physical risk. They overlap, but one does not substitute for the other.

We keep emergency-stop and other required safety functions independent of application AI and cloud availability, according to the system's risk assessment and applicable requirements. Ordinary software stop commands should not be confused with a validated safety function.

For security, we segment networks, minimize exposed services and manage device identity and credentials. ROS 2 security features, including DDS security through SROS2 tooling, can contribute authentication, access control and encryption when configured appropriately. We test enforcement rather than assuming it is enabled.

Updates need signed artifacts, compatibility checks and a recovery plan. We avoid updates during hazardous operations and stage deployment before broader rollout. Rollback must account for firmware, configuration and persistent-data compatibility, not just the application image.

A short readiness checklist

Before we move beyond a controlled prototype, we check that:

• The operating envelope and failure responses are documented.
• Hardware, ROS packages and accelerator runtimes are version-pinned.
• Message contracts include timing, units and coordinate frames.
• Simulation covers faults, not only successful missions.
• AI outputs pass independent validation before execution.
• Essential behavior survives cloud disconnection.
• Logs identify software, models, calibration and configuration.
• Safety functions and emergency procedures are tested appropriately.
• Updates have a verified recovery path.

Build one complete slice, then expand

We start with one meaningful task across the whole stack: a sensor input, a decision, a controlled physical action and enough telemetry to explain the result. We exercise that slice in simulation and on supervised hardware before adding more autonomy.

This exposes integration problems early without requiring a complete fleet platform. It also gives a remote team a shared artifact: a repeatable test with explicit expectations. We can then add capabilities incrementally while keeping a known-good baseline.

If we can help turn a robotics concept into a testable product, we would welcome the conversation. Start a project with Kordspace, or explore our related software, AI, hardware and design capabilities on our services pages.