gz-ecs-overview

Explains the gz-sim Entity-Component-System architecture, system phases, and ECM query patterns.

Updated Aug 16, 2026
One-click install
npx skills add https://github.com/three1324/yeonjinautomotive --skill gz-ecs-overview-three1324
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: gz-ecs-overview
Source: https://github.com/three1324/yeonjinautomotive/tree/main/.claude/skills/gz-ecs-overview
Command: npx skills add https://github.com/three1324/yeonjinautomotive --skill gz-ecs-overview-three1324

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Developers working with gz-sim often struggle to understand where their code belongs in the simulation loop, how Entities, Components, and Systems interact, and which update phase is safe for reading or mutating world state. ## Core Features & Use Cases - Architecture Overview: Maps out how the Server, SimulationRunner, EntityComponentManager, EventManager, and System plugins fit together. - Phase Selection Guidance: Clarifies when to implement Configure, PreUpdate, Update, PostUpdate, or Reset hooks, including the read-only constraint of PostUpdate. - ECM Query Patterns: Shows how to use Each, EachNew, EachRemoved, and EachChanged views for efficient component iteration, plus the Cmd/state/Reset component triplet convention. - Use Case: When adding a new behavior to a Gazebo simulation, consult this reference to decide whether your logic belongs in PreUpdate (applying forces) or PostUpdate (publishing telemetry) and how to query joints efficiently. ## Quick Start Ask how gz-sim organizes its simulation loop and where to add a new system plugin that applies joint commands each iteration.

Frequently Asked Questions about gz-ecs-overview

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How does the gz-sim Entity-Component-System architecture work?

gz-sim organizes simulation state as Entities (uint64 IDs) with strongly-typed Components stored in the EntityComponentManager. System plugins implement phase interfaces like PreUpdate or PostUpdate, and a SimulationRunner drives the iteration loop under a Server process.

Where should I put my code in a gz-sim system plugin?

Use Configure for one-time setup like reading SDF and caching handles, PreUpdate for applying commands and spawning entities, and PostUpdate for read-only telemetry and publishing. Most user code does not belong in Update, which runs alongside physics.

How do I query components efficiently in gz-sim?

Use the Each<> view on the EntityComponentManager, which caches and reuses queries across iterations. Variants like EachNew, EachRemoved, and EachChanged support change-detection passes over entities matching a component signature.

Why is the ECM const in gz-sim PostUpdate?

PostUpdate runs after physics, so the ECM is const to prevent systems from mutating world state that physics has already finalized. Use PostUpdate only for reading state, emitting telemetry, publishing topics, or writing logs.

What is the Cmd, state, Reset component pattern in gz-sim?

It is a triplet where <X> holds the current value, <X>Cmd carries a user request consumed and cleared in PreUpdate, and <X>Reset holds the value applied at the next world reset. JointPositionReset and JointVelocityCmd are canonical examples.

Can gz-sim systems run in parallel threads?

No, PreUpdate, Update, and PostUpdate of different systems run sequentially within one runner iteration. For long-running work, spawn a thread in Configure, communicate via lock-free queues, and drain results in PreUpdate.