# Simulation Containers Reference ## Overview Chassy provides pre-built sample simulation containers that enable you to run robotics simulations in the cloud without managing complex dependencies. Each container includes a complete simulation environment, testing framework, and standardized interface for executing your simulations and retrieving results. You can use these as the basis for building your simulation containers, or make your own from scratch. ## Common Features ### Standardized Command Interface Every Chassy simulation container includes the simulate command-line tool that provides a consistent interface regardless of which simulator you're using. Chassy will automatically run all tests by executing simulate when the [Steps](/reference/workflow-components/steps.md#simulate) step of a workflow is run. ### Automatic GPU Detection Well designed containers should automatically detect and utilize available GPU resources for accelerated rendering. When running on GPU-enabled instances, simulations will use hardware acceleration for improved performance and generating different report outputs into Chassy SLAM, such as images or gifs. On CPU-only instances, containers seamlessly fall back to software rendering, ensuring your simulations always run successfully. This dual-mode capability means you can develop on any hardware and deploy with confidence, knowing the container will optimize for available resources. ### Headless Simulation Support All containers are to be configured for headless operation, running simulations without requiring a display. This enables cloud deployment without X11 forwarding, parallel simulation execution, automated testing in CI/CD pipelines, and sensor data capture in headless environments. The virtual display system can use virtual display servers like Xvfb to create a consistent rendering environment regardless of the host system configuration. ### Test Results and Reporting Test results are automatically generated in JUnit XML format and saved to `/opt/chassy/reports`. This standardized output format integrates seamlessly with CI/CD platforms like Jenkins, GitLab CI, and GitHub Actions, as well as test aggregation tools and custom reporting dashboards. ## Available Example Simulation Environments ### PX4-Gazebo for Autonomous Flight The PX4-Gazebo container provides a complete headless Software-In-The-Loop (SIL) environment for autonomous flight testing, specifically designed for drone and UAV simulation with PX4 Autopilot. The container includes the latest PX4 flight stack compiled and ready to run, Gazebo Harmonic for modern physics simulation with accurate sensor models, and comprehensive MAVLink support through both mavsdk and pymavlink for drone communication protocols. The container offers several pre-configured test suites to validate different aspects of your autonomous flight systems. The setup suite validates the PX4 and Gazebo environment, while the SIL suite tests basic SIL functionality. For more comprehensive testing, the gazebo suite runs integration tests between PX4 and Gazebo, and the flight suite tests actual flight operations including takeoff, landing, and mission execution. ### ROS2-Gazebo for Robotics Applications The ROS2-Gazebo container offers a full ROS2 Jazzy environment integrated with Gazebo Harmonic, making it ideal for general robotics simulation within the ROS2 ecosystem. This container provides everything needed for ROS2 development with a complete ROS2 Jazzy installation including essential packages like `robot_state_publisher`, `joint_state_publisher`, and `xacro`. The integration supports multi-robot simulation with complex robot models using URDF and Xacro formats, with pre-configured sensor message types and tf2 transforms for accurate robot state representation. The container uses CycloneDDS for optimized container networking performance and includes the complete ROS2-Gazebo bridge suite for seamless sensor and actuator data exchange. Network isolation is maintained through configurable ROS domain IDs, allowing multiple containers to run simultaneously without interference. The environment comes pre-configured with `ROS_DISTRO` set to `jazzy`, `ROS_DOMAIN_ID` defaulting to `0` (adjustable for network isolation), and `RMW_IMPLEMENTATION` set to `rmw_cyclonedds_cpp` for optimal performance. ### Isaac Sim for Advanced Physics and AI The Isaac Sim container leverages NVIDIA's Omniverse platform for advanced simulation capabilities, particularly suited for high-fidelity simulation with synthetic data generation needs. This container provides RTX rendering for photorealistic visualization with ray tracing, PhysX 5 for advanced physics simulation of complex interactions, and powerful synthetic data generation capabilities for computer vision and AI training. It's particularly well-suited for creating accurate digital twins of real environments. To use the Isaac Sim container, you'll need an NGC account and API key for container access. Authentication is handled through Docker login in a bash command: ```bash docker login nvcr.io Username: $oauthtoken Password: ``` The container includes optional shader cache warming for consistent performance in production deployments where first-run latency is critical. This feature can be enabled when building custom versions of the container for specific use cases. ## Hardware Requirements ### GPU-Accelerated Simulation For optimal performance with GPU-accelerated simulation, use instances equipped with NVIDIA GPUs with CUDA support. Ensure the NVIDIA Container Toolkit is installed on your host system, along with appropriate NVIDIA drivers: version 470 or higher for Gazebo containers, and version 525 or higher for Isaac Sim is recommended. GPU acceleration significantly improves rendering performance and enables real-time simulation of complex scenarios. ### CPU-Only Simulation All containers support CPU-only execution, making them accessible for development and testing on standard hardware. Software rendering is handled via Mesa OpenGL, providing reliable rendering without GPU hardware. ## Integration with Chassy Platform ### Source Code Management Chassy’s simulation step will automatically clone your git repository and have it available in `src` in your docker environment. ### Retrieving Results Simulation results and test reports are automatically saved within the container at `/opt/chassy/reports`. When running through the Chassy workflow simulation step, the contents in `/opt/chassy/reports` will automatically be ingested and viewable in the Simulation Step's details section. More information on results can be found on [Simulation Reports and Artifacts](/reference/simulation-reports-and-artifacts.md). \
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.chassy.io/reference/simulation-containers-reference.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.