Skip to content

SimCreate


SimCreate is the experiment orchestration and launch tool within the RflySim toolchain. It does not perform dynamics computation or 3D rendering; instead, it uniformly organizes the key aspects of a simulation experiment—such as “which vehicle models to use, which simulation mode to run, which software components to open, and how to launch them in batch”.

SimCreate three-level interface demonstration


Software Positioning

If the entire RflySim simulation suite is viewed as an assembly line:

  • CopterSim serves as the core for motion and flight controller interface
  • RflySim3D serves as the 3D environment and sensor platform
  • QGroundControl serves as the ground station
  • DistSim serves as the multi-vehicle deployment and scheduling engine
  • SimCreate serves as the experiment entry point

Its core value lies in two aspects:

  • Consolidating scattered software launch operations, mode configurations, and parameter combinations into a single experiment entry
  • Converting experiment entries into reproducible BAT scripts

Therefore, SimCreate functions more like an “experiment manager” rather than a standalone simulation program.


Role in the Toolchain

The typical output of SimCreate is neither imagery nor control commands, but rather a complete experiment launch plan:

```text SimCreate -> Reads configurations: vehicle model, scene, simulation mode, communication mode, etc. -> Generates BAT script -> Launches QGroundControl -> Launches RflySim3D / RflySimUE5 -> Launches CopterSim cluster -> Launches PX4 SITL or prepares for HITL -> Optionally loads Python scripts

This means:

  • It determines how the experiment is organized
  • It does not determine how the UAVs fly
  • It does not replace DistSim’s capability for cross-host distribution

How an Experiment is Organized

In SimCreate, an experiment is typically composed of five types of information:

Dimension Description
Vehicle Configuration Model type, quantity, ID assignment, layout method
Motion Model Default model, DLL model, or XML model
Flight Control Mode SIL, HIL, and their sub-modes
Communication Mode UDP, MAVLink, Redis, etc.
Scene & Display 3D software, scene selection, resolution, fullscreen, LAN settings

Therefore, what SimCreate truly manages is not a single “window”, but a reproducible set of experimental states.


Quick Start

Most Common Workflow

  1. Create a new experiment
  2. Select vehicle model(s) and quantity
  3. Choose scene and 3D display software
  4. Select simulation mode and communication mode
  5. Save the experiment
  6. Click “Start Experiment”

Ideal Use Cases

  • First-time setup of an RflySim experiment chain
  • Repeated execution of fixed-type experiments
  • Batch configuration of multi-UAV and heterogeneous experiments
  • Course instruction and lab standard process reproduction

Cases Not Suitable for Independent Use

  • Cross-host distributed script deployment
  • Fine-grained configuration of visual sensors
  • Ground station mission planning and parameter tuning

These are better handled by DistSim, VisCreate, and QGroundControl, respectively.


Three-Level Interface Structure

The SimCreate interface can be understood as having three layers:

1. Experiment Management Layer

This layer manages experiment entries, with common operations including:

  • Create
  • Copy
  • Rename
  • Delete
  • Export
  • Launch

2. Simulation Configuration Layer

This layer manages the runtime configuration of the current experiment, focusing on:

  • Which vehicles to select
  • Quantity of each vehicle type
  • Initial placement (layout)
  • Which scene to use
  • Whether LAN and Python scripts are needed

3. Vehicle Model Configuration Layer

This layer manages details of a single vehicle model type, including:

  • Flight control mode
  • Motion model
  • Communication mode
  • PX4SitlFrame
  • SysID
  • Baud rate, etc.

Understanding these three layers clarifies why SimCreate is especially suited for multi-UAV and heterogeneous experiments—not merely as a “launcher”.


Core Configuration Items

Vehicles and IDs

Common configurations include:

  • Number of vehicles
  • Automatic or manual ID assignment
  • Automatic rectangular layout or manual layout
  • Initial position and attitude

For multi-UAV experiments, ID management is more critical than for single-UAV cases, as subsequent MAVLink, logging, scripting, and visualization often depend on CopterID.

Scene and Display

This determines:

  • Whether to use RflySim3D or RflySimUE5
  • Which scene to load
  • Whether resolution is sufficient
  • Whether to enable fullscreen
  • Whether LAN broadcasting is required

If the experiment involves vision-in-the-loop, scene and display settings affect not only “visual quality” but also perception data fidelity and overall system load.

Flight Control Mode

SimCreate supports many software-in-the-loop (SITL) and hardware-in-the-loop (HIL) modes. For most users, the following classification suffices:

Category Typical Use
PX4_SITL_RFLY Most common PX4 SITL mode
Simulink&DLL_SIL Model-level simulation without flight controller
PX4_HITL Hardware-in-the-loop using Pixhawk
Other SIH / APM / External modes For specific links or extended requirements

Unless special requirements exist, it is recommended to first get the default recommended communication link working before switching modes.


Experiment Execution Mechanism

The key capability of SimCreate lies in its transition from configuration to execution.

What It Actually Does

After clicking “Start Experiment”, SimCreate typically:

  1. Reads experiment parameters from the database
  2. Replaces placeholders in a BAT template with these parameters
  3. Generates a temporary or exported launch script
  4. Launches in sequence: ground station, 3D software, CopterSim, and PX4 SITL

Why It Matters

Without SimCreate, users must manually manage:

  • Vehicle model parameters
  • CopterID
  • Scene names
  • DLL paths
  • Program startup order
  • WSL/SITL-related scripts

SimCreate unifies these frequent and error-prone steps.

Relationship with BAT Scripts

For many advanced users, the true value of SimCreate lies not in its GUI, but in the BAT scripts it generates. Once generated, experiments can be executed repeatedly, modified, batch-called, and even integrated with DistSim for distributed deployment—independently of the GUI.


Organizing Multi-UAV and Heterogeneous Experiments

This is one of SimCreate’s most significant capabilities.

Homogeneous Multi-UAV

Example: 8 identical quadcopters in formation:

  • One vehicle model configuration
  • Multiple vehicle IDs
  • Automatic layout
  • Unified scene

Heterogeneous Multi-UAV

Example: Air-ground or air-sea coordination:

  • Multirotors
  • Fixed-wing aircraft
  • Unmanned ground vehicles (UGVs)
  • Unmanned surface vehicles (USVs)

Each vehicle type can have independent models, communication modes, and layout strategies.

Relationship with DistSim

SimCreate describes the experiment clearly; DistSim executes it across multiple hosts. In practice, their relationship is typically:

```text SimCreate generates experiment scripts -> DistSim distributes and executes them across multiple nodes


Usage Recommendations and Common Issues

  • First, get a single-machine experiment running smoothly, then scale up to multi-machine.
  • By default, start with PX4_SITL_RFLY.
  • For multi-machine scenarios, prioritize using CopterSimNoUI.
  • Choose a 3D visual scene map that closely matches the mission, then adjust resolution accordingly.

Common Issues

Issue Likely Cause Troubleshooting Approach
No environment is launched after clicking “Start” Experiment not saved or not selected Return to the main interface and verify the current experiment status
Multi-machine experiment runs slowly Too many UI instances or overly heavy scene Switch to CopterSimNoUI and reduce scene complexity
Vehicle count or positions mismatch Inconsistent custom array lengths Simplify to auto-layout for troubleshooting
PX4 SITL fails to start WSL or environment chain issues First validate the SITL environment independently, then return to SimCreate
DLL model not taking effect Model path or type mismatch First verify the chain with the default model