CopterExpress/clover
1
0
Fork 0
mirror of https://github.com/CopterExpress/clover.git synced 2026-06-09 02:54:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs/simulation_usage: Performance suggestions (#262)

Browse Source
This commit is contained in:
Alexey Rogachevskiy
2020-07-31 16:25:44 +03:00
committed by GitHub
parent 3b19346a44
commit ebeb3f58d6
4 changed files with 80 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/en/simulation_usage.md
View File

@@ -47,3 +47,43 @@ If you wish to add additional sensors or change their placement, you will have t
### Changing the default world
Gazebo plugins for the drone currently require the `real_time_update_rate` world parameter to be 250, and `max_step_size` to be 0.004. Using other values will not work. Consider using `~/catkin_ws/src/clover/clover_simulation/resources/worlds/clover.world` as a base.
## Performance suggestions
Gazebo simulation environment is resource-intensive, and requires a fast CPU and a decent GPU for real-time execution. However, the simulation may still work on less powerful systems at slower-than-realtime rate. Below are some suggestions for running Gazebo on hardware that does not allow realtime execution.
### Use `throttling_camera` plugin
By default, Gazebo does not slow simulation down for visual sensors. This can be remedied by using the `throttling_camera` plugin from `clover_simulation`.
You can enable it for the drone by changing the `maintain_camera_rate` argument to `true` in `clover_description/launch/spawn_drone.launch`:
```xml
<!-- Slow simulation down to maintain camera rate -->
<arg name="maintain_camera_rate" default="true"/>
```
The plugin will collect publishing rate statistics and slow the simulation down so that the camera publishing rate is no less than requested. However, large slowdowns may negatively affect non-ROS software that connects to PX4. If your simulation is being slowed down to values lower than 0.5 of realtime, consider using the next suggestion.
### Set simulation speed
Since v1.9 the PX4 SITL setup supports [setting the simulation speed](https://dev.px4.io/v1.9.0/en/simulation/#simulation_speed) by setting the `PX4_SIM_SPEED_FACTOR` environment variable. Its value is picked up by PX4 startup scripts, which in turn reconfigure it to expect a certain speedup/slowdown.
You should set its value to the actual real time factor that you get with `throttling_camera`. The real time factor may be found in the Gazebo GUI window at the bottom:
![Real Time Factor](../assets/simulation_usage/05_real_time_factor.png)
In this example you should set `PX4_SIM_SPEED_FACTOR` to `0.42` when launching the simulation:
```bash
PX4_SIM_SPEED_FACTOR=0.42 roslaunch clover_simulation simulator.launch
```
> **Note** If you are using the VM, it may be convenient to put the value in the Gazebo desktop shortcut. Right-click on the Gazebo icon, select "Properties..." and add `PX4_SIM_SPEED_FACTOR=0.42` to the Command field as follows:
![Gazebo PX4 launcher command](../assets/simulation_usage/06_gazebo_px4_launcher.png)
### Allocate more resources to the VM
The virtual machine may benefit from several CPU cores, especially if the cores are not very performant. In our tests, a four-core machine with only a single core allocated to the VM was unable to run the simulation, with constant interface freezes and dropped ROS messages. The same machine with all four cores available to the VM was able to run the simulation at 0.25 real-time speed.
Do note that you should not allocate more resources than you have on your host hardware.