How Isaac Sim Talks to ROS 2

Control a simulated LED panel using ROS 2 services with Isaac Sim — and scale it with Champion.
Blog>
how-isaac-sim-talks-to-ros-2
Last updated: 
July 2, 2025

When working with NVIDIA Isaac Sim and ROS 2, one of the most powerful, but underrated, tools at your disposal is the ROS 2 service. Services let you send a request and wait for a response, making them perfect for simple commands like “Turn on the LED” or “Check battery level.”

Let’s break it down with an example: controlling an LED panel in a simulation.

🔌 The Setup

You have:

  • Isaac Sim: running the simulation and acting as the service client
  • Battery Node (ROS 2): providing battery level and LED control services
  • Relay Node (optional): to abstract or forward requests between Isaac and ROS

The LED Use Case

In this example, we demonstrate how to use ROS 2 services to control an LED panel in a simulated robot environment within NVIDIA Isaac Sim. The use case involves a service-based interaction where Isaac Sim acts as a client node requesting the LED panel to be toggled, and a ROS 2 node (Battery Node) acts as the service server responsible for validating system state (e.g. battery level) and executing the request. This setup showcases how service calls can be used to implement discrete, deterministic actions between Isaac's simulation runtime and external ROS 2 logic, enabling clean separation between visualization and control logic.

The scenario:

  1. Isaac Sim wants to turn on an LED panel when battery is above 50%.
  2. It sends a service request to the Battery Node.
  3. The Battery Node:
    • Checks charge level.
    • If OK, it powers the LED.
    • Sends a result response back: "Panel turned on."

Here’s what that interaction looks like:

Isaac Sim (Client)
  └─> [Request] "Turn on LED"
        └─> Battery Node (Server) checks charge
                └─> [Response] "LED turned on"
Full communication flow of a ROS 2 Action: the client sends a goal (e.g., move to a position), receives acceptance or rejection, ongoing feedback during execution, and finally, the result. Ideal for long-running robot tasks like navigation or manipulation.

⚙️ Why Use Services?

  • 🔁 Deterministic: Isaac waits for confirmation before moving on.
  • 🎯 Precise: Only runs once per request.
  • 🔒 Safe: You can add conditions like checking battery before activating hardware.

🧰 Bonus: Add a Relay Node

Let’s say you don’t want Isaac to talk to the Battery Node directly (maybe you’ll swap it later). Add a Relay Node:

  • Isaac → Relay Node → Battery Node
  • The relay handles logic/routing and sends the final response back.

This makes your system more modular and easier to maintain.

Available Now

Book a demo and get early access. Free trial!

Email Address:
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Email Address:
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.