Isaac Mission Dispatch & Client w/ VDA5050 open source release for ROS2

At ROSCon Kyoto 2022, we are releasing open source for Isaac Mission Dispatch and Client for ROS2 Humble. Mission Dispatch allows a cloud/edge system to send, and monitor tasks from a ROS2 robot via VDA5050 client using industry standards for production deployments. Mission Dispatch is a cloud native micro-service which can be integrated as part of larger fleet management systems.


Mission Dispatch is available now at and as a pre-built cloud native container on NGC.

Mission Client is part of the Isaac ROS release for ROS2 Humble and is available now at

Mission Dispatch has been verified to work with the recently released OTTO Motors & InOrbit AI VDA5050 connector on ROS2 Galactic.

(diagram of cloud | edge to robot for task assignment and monitoring using cloud native components, ROS2, and the newly released open source Mission Dispatch & Client in green)

We define a task as an operation performed by a single actor (i.e. robot), and a mission as a collection of tasks performed by one or more actors. This definition allows for orchestration of complex multi-actor missions decomposed into tasks for individual actors (i.e. robots).

Mission Dispatch is a cloud native micro-service, used to connect to a fleet of local robots to assign tasks and track progress. The service can be run locally on premise in an edge computer, or at a CSP (cloud service provider). It offloads the fleet management system from the work of communicating directly with every robot, allowing it to focus on the optimization problem of best assignment of missions given available resources to perform the work. Mission Dispatch constructs tasks using mission trees to solve for complex fallback behavior on failure.

In this example, the mission is shown on the left. The corresponding VDA5050 Order messages are shown on the right.

Mission Dispatch uses a database to store information about the system allowing for fault tolerance should a failure occur; this allows multiple concurrent Mission Dispatch micro-services sharing the database load balanced by an ingress service such as NGINX or Envoy to scale with the number of robots in the fleet. The database is a separate service where we use Postgres by default and could be modified to use the database of your choice.

Mission Dispatch works with a corresponding Mission Client running on the robot. Dispatch and Client communicate using the VDA5050 standard on top of MQTT (industry standard for a highly efficient, scalable protocol for connecting devices over the Internet). Dispatch and Client identify each other through an MQTT broker, and need to agree on the name of the robot to establish the connection over MQTT.

Mission Dispatch sends tasks to the robot where an MQTT→ROS2 node is used to convert the VDA5050 JSON messages into ROS messages for the Mission Client to process. The JSON messages are converted by Mission Client to ROS2 actions, often with Nav2 for navigation tasks. Mission Client receives state and error updates from ROS and converts them to VDA5050 JSON messages for transmission by the ROS2→MQTT node to Mission Dispatch.

Mission Dispatch and Client can be used to test robots in simulation for automation of test portions of CI|CD, performing a series of predefined tasks evaluated against expected results; we use this in practice, in addition to the primary usage of assigning tasks to robots in operation.

To stand-up your own instance of Mission Dispatch and Client, clone the Mission Client or VDA5050 connector repositories into your ROS workspace to build from source with colcon alongside your other ROS2 packages and deploy the build to the robot. Mission Dispatch can be deployed in three ways:

  1. Install dependencies locally and run
  2. Leverage pre-built containers, and run with Docker Compose
  3. Leverage pre-built containers, and run a HELM chart on Kubernetes

Mission Dispatch can be integrated to fleet management systems (i.e Anyfleet, Roborunner FleetGateway) with Mission Client on the ROS2 robot; Mission Client can be connected to existing fleet management systems supporting VDA5050 (i.e. InOrbit) separately from Mission Dispatch.



Very happy that the Connector is already being used by such impactful projects! Can’t wait to try out Mission Dispatch


Much appreciation for the collaboration, and quick merge to enable Mission Dispatch to work with the VDA5050 connector.

We welcome feedback, to make improvements.


1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.