Real-time simulation updates + ROS publishing via Python API

I’ve been trying to get Isaac Sim to simulate in real-time while being run by Python API. So far, I’ve been trying:

for i in range(30 * 60):
    kit.update(1.0 / 30.0)

to get the simulator to update at 30 Hz for a minute. However, this does not seem to work – most of the time it ends up running for over a minute. Additionally, when I run rostopic hz /rgb on an /rgb topic for a camera in the simulation, the publish rate varies wildly – sometimes it’s consistently > 40 Hz, other times it’s only around ~14 Hz.

  1. Is there any way to get the simulator to run in real-time, like when running the simulator via GUI and not the Python API?
  2. Why does the ROS topic vary so much between different sessions? Is there a way to have it publish at a consistent rate / set the rate of publishing?
  3. How does one get the simulator to run indefinitely? E.g. until the program is closed. I assume there’s a better way than just using while True: kit.update()?
  4. Is there any good example Python script that I can look at to understand the above questions? I’ve looked at some of the stuff in omni.isaac.samples, but can’t seem to find where the “simulation loop” is for the examples I’ve examined.

Will look into this, currently there aren’t any pure python ROS samples, but we should have one. I will share the .py file here when I have something.

1 Like

Alright, thanks!

@wchen 2021.1.1 was released this week, and docs went live last night:

see https://docs.omniverse.nvidia.com/app_isaacsim/app_isaacsim/sample_python_ros.html
for how to run ROS from native python, added samples for running the stereo camera sample and a simpler clock.py sample for manual ticking and rospy usage.

Thanks for getting back to me!

I’m still a bit confused on how the real time clock stuff works though. I modified the code in clock.py:

    start = time.time()
    for frame in range(121):

        # publish manual clock every 10 frames
        if frame % 10 == 0:
            result, status = omni.kit.commands.execute("RosBridgeTickComponent", path="/ROS_Clock_Manual")

        kit.update(1./60.)
    print(time.time() - start)

This printed 0.75 seconds instead of the desired ~2.

As for the code that should be running realtime:

    start = time.time()
    for frame in range(121):

        # publish manual clock every 10 frames
        if frame % 10 == 0:
            result, status = omni.kit.commands.execute("RosBridgeTickComponent", path="/ROS_Clock_Manual")

        kit.update()  # runs with a realtime clock
    print(time.time() - start)

That printed 0.52.

How is the latter in real time? Also, why is manual ticking in carter necessary? Carter is not supposed to be real time since it specifies a dt in kit.update(), right? How do sim time and system time differ in terms of how fast they tick up?

Sorry by realtime I mean that the step size will change so that the time passing in sim will match the time passing with the system clock. You can confirm this by echoing the /manual_time rostopic

In the first case it will perform exactly 121 frames at 1/60.0 so 2 seconds of simulation time will pass, it might take more/less system time dependent on performance, in your case it looks like its running 2.66x faster than realtime, if it took .75 seconds of system time for 2 seconds of simulated time.

In the second case you will see that if you compare the time on the /manual_time topic from the first to last message, it should be about 0.52 seconds.

Thanks for the explanation!

Is the manual ROS prim ticking necessary for realtime simulation then?

Nope, this sample was more for illustrative purposes showing how to manually tick from python.
If the component’s enabled flag is set to true, it will automatically tick every update()

Ah got it. Then, is there a way to set the publishing rate for a ROS topic being published by a prim?

The only way to control the publishing rate at the moment is to manually tick when running in native python.
We are looking into the best way to allow user specified tick rates to the component itself, but that will be in a future release.

1 Like

Alright. Thanks so much for the help!

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