One of the recurring architectural decisions in robotics projects is how to organize task execution.

In practice, this decision becomes important very quickly. A robot rarely performs only one action. It needs to move, detect, decide, recover from failures, and sometimes interrupt one task to handle a higher-priority event.

Two common ways to model this logic are:

• State Machines
• Behavior Trees

Both are useful, but they are not equally suitable for every robotics problem.

A common mistake is to treat them as interchangeable. From project work, we have found that they solve different orchestration problems and lead to very different system complexity as a project grows.

This article is meant to be a practical guide based on the kind of robotics workflows where this decision actually matters.

The comparison here comes from two representative examples:

• An agriculture workflow with move -> detect -> pick -> place
• A patrol robot workflow with patrolling, intruder handling, docking, and recovery

The main takeaway is simple:

A State Machine works very well when the task is mostly linear and mode-based.
A Behavior Tree becomes more useful when the robot must react, recover, reprioritize, and combine multiple decision layers at runtime.

Behavior Trees vs State Machines: Quick Comparison

State Machines in Robotics

A State Machine models a system as:

• A set of states
• A set of transitions
• Conditions that determine when the system moves from one state to another

A simplified example looks like:

Idle -> MoveToTarget -> DetectObject -> PickObject -> PlaceObject -> Done

At any moment, the robot is usually in one well-defined state, and the logic is expressed as transitions between these states.

In robotics projects, this makes State Machines intuitive and easy to debug for workflows that follow a predictable sequence.

Why They Work Well in Practice

State Machines are easy to reason about because they match how humans often describe tasks:

1. Go to location
2. Detect object
3. Pick object
4. Place object
5. Return or stop

For many real systems, this is enough.

Figure 1: State Machine view of a structured robotics workflow.

Where State Machines Worked Well: Agriculture Pick and Place

Consider an agricultural robot working in a structured environment such as a greenhouse or a controlled farm row.

At first glance, move -> detect -> pick -> place sounds too simple, and that can make the conclusion feel too easy. In practice, the real workflow is usually more involved than that.

A more realistic agricultural cycle may include:

1. Move to the next plant
2. Slow down and switch to scanning mode
3. Detect fruit or crop candidates
4. Filter candidates by ripeness, reachability, or confidence
5. Align the mobile base or manipulator
6. Execute the pick
7. Verify grasp success
8. Place the crop in a collection bin
9. Update yield count or row progress
10. Move to the next target

This is a strong State Machine use case, and in our experience it is exactly the kind of workflow where a State Machine stays clear and manageable.

Why It Fit Well

Even with added perception and verification steps, the task is still mostly sequential.

Each stage has a clear objective:

• Navigation gets the robot into position
• Scanning and detection identify candidate fruit
• Selection logic chooses the best target
• Manipulation aligns and executes the pick
• Verification confirms whether the grasp succeeded
• Placement completes the harvest cycle

There may be retries, skips, and small local recoveries, but the overall structure is still linear and mode-based.

A simplified state model could be:

Idle
  -> NavigateToPlant
  -> ScanCropRegion
  -> DetectCandidateCrops
  -> SelectTargetCrop
  -> AlignManipulator
  -> PickCrop
  -> VerifyGrasp
  -> PlaceInCrate
  -> UpdateTaskProgress
  -> AdvanceToNextPlant
  -> ScanCropRegion ...

If something goes wrong, the recovery logic can still remain local to the active step. For example:

• If no crop is detected, retry scanning once or move to the next plant
• If crop confidence is low, rescan from a slightly different pose
• If the pick fails, retry the grasp with another candidate
• If the bin is full, transition to an unload or crate-swap routine
• If manipulation repeatedly fails, flag the plant and continue

Those are real operational branches, but they still fit naturally into a State Machine because they usually remain tied to one phase of the process rather than globally reprioritizing the whole robot.

What We Learned from This Type of Workflow

In agriculture pick-and-place, the robot usually does not need deep concurrent reasoning across many competing goals.

It is typically operating in a bounded loop:

• finish the current step
• move to the next step
• recover locally if needed

That makes the software easier to implement, test, and explain across the team.

The important point is not that the agriculture problem is trivial. It often is not. The point is that the complexity is still usually organized around process stages rather than competing runtime priorities.

That is why a State Machine can still work well even when the workflow includes:

• target quality checks
• grasp verification
• localized retries
• bin management
• row-by-row progress tracking

Practical Benefits

• The flow is explicit and easy to visualize
• Failures are usually local to a step
• Operators can understand the workflow quickly
• Debugging is straightforward because the current state is usually obvious

Where It Starts to Strain

Even in agriculture, State Machines become harder to manage if we keep adding:

• battery-aware behavior
• human-aware pausing in shared spaces
• dynamic obstacle handling
• multiple interrupt levels
• task preemption
• alternative recovery paths
• mission-level decisions such as switching rows or unloading based on fleet context

At that point, the transition graph can grow rapidly.

Figure 2: Agriculture harvesting workflow with stage-based execution.

Behavior Trees in Robotics

A Behavior Tree organizes decision-making as a hierarchy of nodes rather than a flat graph of states.

Instead of building one large transition graph, a Behavior Tree breaks the robot’s behavior into smaller decision blocks that can be composed together. This makes it possible to express not only task flow, but also priority, fallback, retry, and interruption in a more structured way.

Typical node types include:

• Sequence: run children in order until one fails
• Fallback / Selector: try alternatives until one succeeds
• Condition: check if something is true
• Action: perform a task
• Decorator: modify behavior such as retrying or limiting execution

A Behavior Tree is evaluated repeatedly, which makes it naturally suited for reactive systems.

That repeated evaluation, often called ticking, is one of the most important practical differences from a State Machine. The tree is not simply waiting in one state for a transition. It keeps re-evaluating the current situation and asking which branch should be active now.

This is what makes Behavior Trees useful in robotics systems where conditions can change while the robot is already in motion. A battery condition can become true mid-task. An intruder can appear while the robot is patrolling. A navigation action can fail and trigger a local recovery branch without needing to redesign the whole mission graph.

Another practical strength is locality. A recovery subtree can live close to the action it supports. A retry policy can wrap only the branch that needs it. A high-priority condition such as low battery can sit near the top of the tree and override lower-priority behavior cleanly.

A simplified view might look like:

Fallback
  BatteryLow? -> Dock
  IntruderDetected? -> Intercept
  PatrolRoute

Figure 3: Behavior Tree showing priority-based decision structure.

This structure is different from a State Machine in an important way:

A Behavior Tree is not only describing “what state am I in?”
It is also continuously describing “what should I do right now, given current conditions?”

Where Behavior Trees Became Necessary: Patrol Robot

Now consider a patrol robot in a larger, less predictable environment.

Its responsibilities may include:

• Follow a patrol route
• Monitor for intruders
• Interrupt patrol when an intruder is detected
• Move to investigate or intercept
• Resume patrol if the event clears
• Dock when the battery is low
• Recover from blocked paths or navigation failures

This is where Behavior Trees become much more useful, and in practice this is the kind of system where they stop being a preference and start becoming the better architectural tool.

Why Patrol Was Different

Patrol is not a simple linear workflow.

The robot must continuously balance priorities:

• patrolling is the default task
• intruder response may preempt patrolling
• docking may preempt both when battery becomes critical
• recovery behaviors may temporarily override any of the above

Trying to model all of this in one large State Machine often leads to too many transitions:

• Patrol -> IntruderDetected
• IntruderDetected -> Intercept
• Intercept -> Patrol
• Patrol -> Dock
• Intercept -> Dock
• Recovery -> Patrol
• Recovery -> Dock
• Recovery -> Intercept

As conditions increase, the state graph becomes harder to maintain and reason about. That is usually the point where a team starts feeling the limits of a State Machine.

A Better Fit with Behavior Trees

A Behavior Tree can model the same logic more naturally:

Fallback
  Sequence
    BatteryLow?
    Dock

  Sequence
    IntruderDetected?
    InvestigateOrIntercept

  Sequence
    PatrolRouteAvailable?
    PatrolRoute

Recovery can also be attached locally:

Sequence
  PatrolRouteAvailable?
  RetryUntilSuccessful
    PatrolRoute

This structure makes it easier to express priority and fallback behavior.

What We Learned from This Type of Workflow

In patrol robots, the environment and task priorities can change at runtime.

The robot may be:

• following a patrol loop
• interrupted by a perception event
• forced to reroute due to a blocked corridor
• required to dock before finishing the route

Behavior Trees handle this well because they are built for:

• reactivity
• prioritization
• modular decision logic
• reusable sub-behaviors

In systems like Nav2, this is one reason Behavior Trees are such a practical fit. Navigation is not a one-shot action. The robot may need to replan, retry, wait, recover, or switch goals based on runtime conditions, and a tree structure handles that more naturally than a large set of cross-linked states.

Figure 4: Patrol robot behavior tree with patrol, intruder handling, docking, and recovery branches.

The Practical Difference: Sequence vs Reactivity

The easiest way to distinguish the two is this:

State Machine

Best when the main question is:

What step of the process am I in?

Behavior Tree

Best when the main question is:

Given the current world state, what behavior should run now?

This is why State Machines often feel natural for production steps, while Behavior Trees feel natural for autonomous runtime decision-making.

State Machines: Practical Strengths and Limits

Advantages

• Simple to understand for linear workflows
• Easy to implement for finite process steps
• Explicit transitions make debugging easier
• Good fit for task pipelines with limited branching

Where the Advantage Was Clear

In the agriculture workflow, each step depends on successful completion of the previous step:

• no point in picking before detection
• no point in placing before picking
• no point in advancing before the current cycle is finished

That dependency chain maps directly to states.

Limitations

• Transition graphs grow quickly as exceptions increase
• Harder to model layered priorities
• Reactivity becomes messy when many interrupts exist
• Reuse across tasks is often weaker than in tree-based designs

Where the Limitation Starts to Appear

Suppose the agriculture robot must now also:

• monitor battery
• pause for human presence
• re-scan if crop confidence drops
• retry grasp using alternative poses
• switch to a different collection bin when full

A once-clean State Machine can become crowded with cross-links and exception handling. That does not make it wrong, but it does mean the orchestration model is being asked to handle more reactivity than it was originally optimized for.

Behavior Trees: Practical Strengths and Limits

Advantages

• Naturally reactive to changing conditions
• Easier to express priorities and fallbacks
• Modular subtrees are reusable
• Recovery behaviors can be attached cleanly
• Scales better when many conditions interact

Where the Advantage Was Clear

In the patrol robot:

• patrol is the default behavior
• intruder handling is conditional and higher priority
• docking is conditional and may override patrol
• recovery should be local to the failing branch

This is exactly the kind of layered runtime behavior that Behavior Trees express well.

Limitations

• Harder to understand initially if the team is new to them
• Poorly designed trees can become opaque
• Continuous ticking can make debugging feel less direct than a single active state
• For simple linear tasks, a Behavior Tree can be unnecessary overhead

Where the Limitation Appears

If the agriculture task is almost always:

Move -> Detect -> Pick -> Place

then implementing a full Behavior Tree may add complexity without much benefit.

In such a case, the architecture is technically valid, but not necessarily the simplest solution.

When We Would Choose a State Machine

A State Machine is usually the better choice when:

• the workflow is mostly sequential
• the number of branches is limited
• system modes are well defined
• operators need very explicit process visibility
• task completion matters more than continuous reprioritization

Typical examples include:

• pick-and-place sequences
• machine operation cycles
• startup and shutdown procedures
• inspection routines with fixed steps

Rule of Thumb

If you can describe the robot’s job mainly as:

Step 1 -> Step 2 -> Step 3

then a State Machine is often enough.

When We Would Choose a Behavior Tree

A Behavior Tree is usually the better choice when:

• the robot must react continuously to the environment
• multiple conditions compete for attention
• priorities can change at runtime
• recoveries need to be modular
• behaviors should be reusable across missions

Typical examples include:

• patrol robots
• service robots
• navigation with recovery branches
• mission planners with interrupts and fallback policies

Rule of Thumb

If you can describe the robot’s job mainly as:

Keep doing the best possible behavior based on current conditions

then a Behavior Tree is likely the better fit.

Agriculture vs Patrol: What the Choice Looked Like in Practice

These two examples capture the difference well.

Agriculture

For move -> detect -> pick -> place, a State Machine works well because:

• the task is strongly ordered
• the workflow is repetitive
• transitions are predictable
• failures can be handled step by step

Patrol

For move -> intruder response -> docking -> recovery, a Behavior Tree works better because:

• the robot must keep reevaluating priorities
• behaviors may interrupt one another
• recovery should be local and reusable
• the environment is more dynamic and less structured

This is not because Behavior Trees are always more advanced. It is because the patrol problem is fundamentally more reactive.

Conclusion

The main lesson from these workflows is not that one model is modern and the other is outdated. It is that they fit different kinds of problems.

State Machines remain a strong architectural choice when the robot is progressing through a structured process with clear stages, local failures, and limited global reprioritization. That is why they can still work well even in fairly capable agriculture systems.

Behavior Trees become more valuable when the robot must continuously evaluate conditions, switch priorities, and attach recovery behavior close to the action that failed. That is why they fit patrol, navigation, docking, and other runtime-reactive autonomy problems so well.

In practice, the most useful question is usually not “Which one is better?” It is “Is this robot mainly progressing through stages, or is it continuously selecting among competing behaviors?”

That distinction tends to make the right choice much clearer.

Tuning navigation in ROS2 Nav2 can quickly become a frustrating process.

For Ackermann-drive robots using planners like Hybrid A* or controllers like MPPI, even small parameter changes can lead to unexpected behavior.

A typical workflow looks like:

• Modify parameters in YAML
• Launch navigation
• Observe behavior in simulation
• Repeat

With dozens of parameters across planners, controllers, and costmaps, this process becomes slow, manual, and difficult to scale.

A natural question arises:

Can we automate Nav2 tuning?

At first glance, tools like Optuna, Bayesian optimization, or even agent-based workflows workflows seem promising. However, in practice:

Automation alone does not solve Nav2 tuning.

This article presents a different perspective:
Nav2 tuning is fundamentally a systems engineering problem, not just a parameter optimization problem.

The Problem with Nav2 Parameter Tuning

Nav2 exposes a large number of parameters across:

• Global planner (Hybrid A*, State Lattice)
• Controller (MPPI, DWB)
• Costmaps
• Robot model and kinematics

These parameters are tightly coupled. A change in one component often affects others.

The common “edit-run-observe” loop:

Edit YAML → Run → Observe → Repeat

has several limitations:

• No reproducibility across experiments
• No quantitative comparison between configurations
• Strong dependence on visual inspection
• Poor scalability across different scenarios

As highlighted in Nav2 community discussions (notably by maintainers), manual tuning becomes increasingly difficult as system complexity grows.

A Systems Perspective on Nav2

Instead of treating tuning as a search problem, it is more useful to view Nav2 as a multi-layer system:

• Robot model defines what is physically possible
• Costmaps define how the environment is interpreted
• Planner defines feasible paths
• Controller defines how those paths are executed

Poor navigation behavior is often a result of incorrect assumptions in one of these layers, not just “bad parameters”.

Parameter Classification for Nav2

A practical way to simplify tuning is to categorize parameters into three types.

1. Constant Parameters (Robot Geometry)

These represent the physical properties of the robot:

• Footprint
• Wheelbase
• Minimum turning radius

Robot Footprint and Geometry

These should match real-world measurements and should not be tuned for behavior.

Incorrect values can lead to:

• Invalid or infeasible paths
• Collisions despite correct planning
• Controller instability

2. Hard Parameters (Environment Representation)

These define how the robot perceives obstacles:

• Inflation radius
• Cost scaling factors
• Obstacle layers

Costmap and Inflation Visualization

They directly influence:

• Clearance from obstacles
• Safety margins
• Path feasibility

These parameters are typically tuned once per environment and remain relatively stable.

3. Soft Parameters (Behavioral Tuning)

These control navigation behavior:

• MPPI critic weights, DWB parameter weights
• Velocity and acceleration preferences

Trajectory Smoothness Comparison

They affect:

• Smoothness of motion
• Aggressiveness
• Oscillations and steering stability

These are the primary parameters adjusted during iterative tuning.

This separation helps isolate problems and prevents conflicting tuning decisions across different parts of the system.

The Missing Piece: Benchmarks

One of the biggest gaps in Nav2 workflows is the lack of standardized benchmarks.

Instead of testing random navigation goals, define consistent scenarios:

benchmarks:
  - full_loop
  - tight_corridor_uturn
  - corner_escape
  - reverse_reposition

Each scenario evaluates a specific capability:

• Tight space maneuvering
• Reverse behavior
• Long-distance navigation
• Stability in constrained environments

Start Simple: Progressive Benchmarking

A common mistake when tuning Nav2 is jumping directly into complex scenarios like tight corridors or full loops.

This makes debugging difficult since multiple components (planner, controller, costmaps) are stressed at once.

Instead, use progressive benchmarks, start simple, and then increase complexity.

Level 1: Primitive Behaviors

benchmarks:
  - straight_line
  - in_place_rotation
  - gentle_turn

These test basic control:

• Straight motion stability
• Smooth rotation
• Steering oscillations

Straight Line Benchmark Visualization

Issues here usually point to:

• Controller critics and parameters
• Velocity limits

Level 2: Constrained Behaviors

benchmarks:
  - narrow_passage
  - obstacle_avoidance

These test interaction with the environment:

• Obstacle clearance
• Costmap behavior

Problems here are often related to:

• Inflation radius
• Cost scaling

Level 3: Full Scenarios

benchmarks:
  - full_loop
  - tight_corridor_uturn
  - corner_escape

These combine planning and control under realistic conditions.

Full Environment Loop Benchmark Visualization

Why This Works

• Level 1 → Controller issues
• Level 2 → Costmap issues
• Level 3 → System-level issues

This layered approach reduces trial-and-error and makes tuning more systematic by isolating issues at the correct level of the system.

Example Benchmark Results

Tight Corridor UTurn Benchmark Visualization

Corner Escape Benchmark Visualization

Using Foxglove recordings allows clear visualization of trajectories, velocity profiles, and controller behavior.

Once benchmarks are defined, the next step is to make experiments reproducible.

YAML-Driven Experimentation

Instead of modifying a single configuration repeatedly, define experiments explicitly:

experiment:
  name: "high_clearance_smooth"

nav2:
  inflation_radius: 0.7
  mppi:
    temperature: 0.3
    critic_weights:
      path_follow: 5.0

A simple runner script can execute:

run_experiment exp.yaml

This enables:

• Reproducible experiments
• Easy comparison between configurations
• Structured iteration

Quantitative Evaluation Metrics

Relying only on visual inspection is insufficient.

Useful metrics for evaluating Nav2 performance include:

• Time to goal
• Path length
• Minimum obstacle distance
• Velocity or steering smoothness
• Number of oscillations

Example Comparison

Logged Steering and Velocity Signals

Even simple logging of these metrics significantly improves decision-making during tuning.

Key Observations

From applying this structured approach:

1. Many issues originate from incorrect modeling

Incorrect footprint or costmap configuration often leads to poor navigation performance.

2. Benchmark-driven tuning is more reliable

Fixed scenarios make it possible to compare configurations objectively.

3. Parameter grouping simplifies tuning

Separating constant, hard, and soft parameters reduces complexity.

4. Automation is not the first step

Automated tuning tools are useful only after:

• Benchmarks are defined
• Metrics are established
• System behavior is understood

Toward a Better Nav2 Workflow

A structured navigation tuning workflow can be organized as:

nav2_benchmark/
├── scenarios/
├── configs/
├── runner/
├── metrics/
└── results/

Such a framework enables:

• Reproducible experiments
• Quantitative evaluation
• Scalable tuning workflows

Conclusion

Nav2 tuning is often framed as a parameter optimization problem.

In practice, it is a systems engineering problem involving:

• Accurate robot modeling
• Consistent environment representation
• Structured benchmarks
• Quantitative evaluation

Automation can help, but it is not the solution.

A structured approach based on experiments, metrics, and system-level understanding leads to more reliable and scalable navigation performance.

Discussion

• How do you currently tune Nav2?
• Do you rely on visual inspection or quantitative metrics?
• Would a standardized benchmarking framework improve your workflow?

Autonomous Mobile Robots (AMRs) combined with robotic arms are becoming common in warehouses and factories. They move through aisles, dock at shelves, pick objects, and deliver them to new locations.

But building such a system is not just about writing code. It is about designing the right architecture: one that allows navigation, perception, manipulation, and control to work together reliably.

In this article, we break down how to design a scalable AMR + Manipulator system and how to choose the right frameworks for each layer.

Problem Definition

Imagine a warehouse workflow:

Figure 1: Problem definition for Warehouse Mobile Manipulation Workflow.

1. Navigate to a storage aisle
2. Identify the correct bin
3. Dock precisely in front of it
4. Pick the object using a 6-DOF arm
5. Deliver it to a drop-off station
6. Repeat safely and consistently

To build this reliably, we need structured system design.

Layered System Architecture

Figure 2: Layered architecture for a scalable AMR + manipulator system.

A scalable mobile manipulation system can be divided into clear layers:

1. Hardware Layer

• Mobile base
• LiDAR and RGB-D camera
• 6-DOF robotic arm
• Gripper

2. Perception Layer

• Object detection
• Dock alignment
• Obstacle detection

3. Planning Layer

Navigation

• Global path planning
• Local obstacle avoidance
• Docking behavior

Manipulation

• Motion planning
• Collision checking
• Trajectory execution

4. Execution Layer

• Joint controllers
• Base velocity controllers

5. Task Orchestration

• State machine or Behavior Tree
• Error handling
• Recovery behaviors

This separation keeps the system modular. Each layer can be developed, tested, and improved independently.

Design Philosophy: Simulation First, Then Integration

Architecture alone is not enough. The development process matters just as much.

At Kodo Robotics, we follow a simple rule:

Simulate first. Integrate gradually. Deploy last.

Simulation First

Before touching hardware, we validate everything in simulation:

• Navigation tuning in warehouse layouts
• Arm motion planning in clutter
• Docking precision
• Sensor behavior under different conditions

Simulation allows fast iteration, safe testing, and reproducible experiments.

Figure 3: Development Loop for a scalable robotics system.

Test Modules Independently

Each layer is tested separately before full integration:

Navigation

• Path planning stability
• Obstacle avoidance

Manipulation

• IK validation
• Collision-free trajectories

Perception

• Object detection accuracy
• Pose estimation consistency

This prevents integration problems later.

Incremental Integration

Instead of integrating everything at once, we proceed step by step:

1. Base + navigation
2. Arm motion planning
3. Docking integration
4. Full pick and place loop
5. Fault and recovery testing

Only after simulation and integration tests are stable do we move to hardware validation.

Hardware Testing

Real-world testing focuses on:

• Sensor latency
• Mechanical tolerances
• Calibration drift
• Real-world noise

Simulation builds confidence. Hardware testing validates assumptions.

Framework Comparison by Architecture Layer

Framework selection should support the layered architecture — not fight it.

Now let’s look at each layer clearly.

Navigation

For warehouse AMRs, Nav2 is currently the most practical choice.

It provides:

• Mature planners
• Behavior Tree orchestration
• Recovery behaviors
• Costmaps and zoning
• Docking support

It is modular and widely adopted.

Isaac offers acceleration and perception-focused advantages, but Nav2 provides stronger out-of-the-box industrial navigation features.

MATLAB can prototype planners but does not provide a complete industrial navigation stack by default.

Practical choice: Nav2 for most industrial AMR systems.

Manipulation

For arm motion planning, MoveIt2 remains the most flexible and integration-friendly option.

It offers:

• Collision checking
• OMPL-based motion planning
• Inverse kinematics (IK) solvers
• Planning scene management
• Pick-and-place framework with grasp execution support
• Integration with ros2_control for hardware execution

Isaac provides strong GPU-based workflows, especially for perception heavy pipelines.

MATLAB/Simulink is excellent for prototyping kinematics and trajectory logic, but typically integrates with ROS for execution.

Practical choice: MoveIt2 as the backbone, optionally supported by MATLAB for algorithm design.

Simulation

If you follow a simulation-first philosophy, simulator choice matters.

Gazebo

• Fast iteration
• Tight ROS2 integration
• Ideal for functional validation

Isaac Sim

• High visual fidelity
• Advanced sensor realism
• Strong for perception systems

Simulink + Unreal

• Control focused validation
• Physics based modeling

Choose based on what you are validating:

• System logic → Gazebo
• Sensor realism → Isaac
• Control validation → Simulink

Control Design

For many industrial systems, ros2_control is sufficient.

However, when:

• Advanced model-based control is required
• Safety validation is important
• Autocode generation is needed

MATLAB/Simulink provides strong structured workflows.

Isaac mainly accelerates compute-heavy tasks rather than replacing control design frameworks.

Deployment

Deployment depends on system constraints.

ROS2

• Modular
• Linux native
• Hardware abstraction friendly

Isaac

• GPU optimized deployment

MATLAB/Simulink

• Automatic C++ generation
• Clear traceability from design to runtime

For model-based workflows, MATLAB shines during deployment integration.

Recommended Hybrid Approach

A layered architecture allows mixing tools intelligently:

• Navigation → Nav2
• Manipulation → MoveIt2
• Simulation → Gazebo or Isaac Sim
• Control validation → MATLAB/Simulink
• Runtime deployment → ROS2

The goal is not to choose one ecosystem, but to design a clean, modular system.

Conclusion

Building an AMR + Manipulator system is an architecture challenge.

Clear layering, disciplined testing, and simulation-first development are what make systems scalable and reliable.

At Kodo Robotics, we focus on structured system design, because in robotics, integration quality determines success.

Let’s Build Reliable Robotics Systems

If you are designing a warehouse automation system or exploring mobile manipulation for industrial use, architecture decisions made early will define long-term success.

Whether you are prototyping a new platform or scaling an existing deployment, a modular, simulation-first approach reduces risk and accelerates development.

Feel free to connect or reach out if you would like to discuss system architecture, mobile manipulation, or AMR platform design.