Real Time Factor greater than 1

[Sharan123]

I've tried setting the real time factor to be greater than one by adjusting the world parameters in grass_plane.world

<max_step_size>0.004</max_step_size>
<real_time_factor>1</real_time_factor>
<real_time_update_rate>250</real_time_update_rate>

I've tried setting the max_step_size to 0.008, while keeping everything the same, also tried setting the real_time_update_rate to 500 while keeping everything at default (0.004) it also didn't work. I've learned that real_time_factor is never used and that actual real_time_factor is justmax_step_size*real_time_update_rate.

Both of these changes (0.004 -> 0.008 & 250->500) individually yielded an error of

gazebo_mavlink_interface.cpp:331 max_step_size of 0.004 s does not match real_time_update_rate of 500 In case of changing the real_time_update_rate.

I've then learned that when using PX4 we can change the real time factor by setting export PX4_SIM_SPEED_FACTOR=2 which I've done by adjusting the session.yml file in the example_tmux_scripts/two_drones_gps by changing the gazebo part of the sim (just exporting the sim_speed_factor first prior to launching)

- gazebo:
      layout: tiled
      panes:
        - export PX4_SIM_SPEED_FACTOR=2; waitForRos; roslaunch mrs_simulation simulation.launch world_name:=grass_plane2 gui:=false

However this also failed and resulted in the same error message as before!

I have been using the following recipe for 04_with_linux_setup_uav_modules

Bootstrap: docker
# Bootstrap: docker-daemon
From: ctumrs/mrs_uav_system_ls_modules:1.0.4
...

and added a couple of programs and custom scripts by adjusting the 05_user_modifications_from_singularity_img/ (mostly try testing the custom world file).

Is there a way to speed up the simulation with respect to real-time without hitting the error from gazebo_mavlink_interface?

[klaxalk]

Hey, so the only reliable way for chaing the RTF in Gazebo is to change the real_time_update_rate in the physics tab of the Gazebo GUI.

However, if you increase it and nothing happens, that means that your computer is not able to simulate it faster than what it already is doing.

[Sharan123]

Heya @klaxalk thanks for the reply and help!

I am a PhD student at Temple University, and we def like the CTU group's MRS system. We are currently doing research and trying to see if we can run many sims, using the MRS system as support and add-in machine learning as UAV control. To do this, we need to run many sims, as quickly and efficiently as possible (while having 2+ UAVs).

Is there a way to change the realtime factor without the GUI, programmatically, (by setting some environment param, or changing something in the scripts like I tried)? The goal is to run many automatic sims and keep track of UAV states, collect the data from many sims, and then test the system by using ML as a navigation tool. This is why I set gui:=false since the rendering takes quite a bit of processing power and time, and also why I try to change the real_time_update_rate programmatically as to be able to run many simulations in real-time.

I do understand that if we increase the real_time_update_rate, at one point it will cap since we do not have sufficient processing power, and I am fine with fine-tuning the parameter such that it is computationally feasible to run the sim under the current settings.

Thanks for you advice!

[klaxalk]

Hey @Sharan123, I think that the Gazebo Simulation with the PX4 SITL is not the best way to conduct learning. It can not go much faster than RTF=5 and that is without simulation of complex sensors. With sensor, it is gonna be rather < 1.0. We are also doing learning like this, but using another paradigm. We decouple the dynamic simulation from the redending of visuals and sensors and use a different tools for both. The dynamic simulation can be simulated by our standalone simulator (https://ctu-mrs.github.io/docs/simulation/mrs/mrs/standalone_outside_ros.html) which can be embedded and stepped directly in your CPP code. The rendering can be done by, e.g., Unity Engine / Unreal, which only provide sensor data for desired 3D pose of the UAV. Email me with more details and we can chat about your options.