Creating Modules
This guide walks through creating a new module from scratch using the SDK’s convention-over-configuration approach.Module Structure
Every module follows this structure:Step-by-Step Guide
Step 1: Create Directory Structure
Step 2: Create Configuration
Createconfig/MyNew.yaml:
Step 3: Create CMakeLists.txt
Step 4: Create Task Header
Createsrc/MyNewTask.hpp:
Step 5: Create Task Implementation
Createsrc/MyNewTask.cpp:
Step 6: Build and Run
What Gets Auto-Generated
When CMake runs, it automatically:- Finds config - Locates
config/MyNew.yaml - Verifies source files - Checks
src/MyNewTask.hppand.cppexist - Generates I/O code - Creates
build/generated/MyNewTask.generated.hpp:
Naming Conventions
| Component | Convention | Example |
|---|---|---|
| Module directory | PascalCase | MyNewModule/ |
| Config file | {Name}.yaml | MyNew.yaml |
| Task class | {Name}Task | MyNewTask |
| Task files | {Name}Task.{hpp,cpp} | MyNewTask.cpp |
| Port members | {name}_{input,output}_ | sensor_data_input_ |
Configuration Options
Task Configuration
Port Configuration
Logging Configuration
Best Practices
Keep modules focused
Keep modules focused
Each module should do one thing well. Split complex functionality into multiple modules that communicate via messaging.
Use meaningful topic names
Use meaningful topic names
Topic names should describe the data:
/sensors/lidar/points, /control/velocity, /status/healthChoose appropriate QoS
Choose appropriate QoS
- Use
RELIABLEfor critical data (commands, status) - Use
BEST_EFFORTfor high-frequency sensor data
Handle initialization failures
Handle initialization failures
Return
false from onInitialize() if setup fails - the framework will handle cleanup.Next Steps
Messaging System
Learn about pub/sub messaging and QoS