A ROS 2 system is a graph of nodes — each one is a process that subscribes to some topics, publishes to others, and may call or expose services and actions. This section is the reference for which nodes exist in the claudeDrone stack, what they do, what they take in, and what they emit. If you’re trying to understand how a piece of sensor data flows from a TF-Luna reading to a motor command, this is the right place to start.
The node map is split into three subhubs. Core nodes are the central command-side nodes — takeoff_node, state_estimator, action_publisher — that handle the closed loop between perception and actuation. Sensor-processing nodes wrap individual sensor drivers and produce policy-ready features — lidar_processor_node, camera_vision_node. Custom scripts collects Python utilities that aren’t quite ROS 2 nodes but live in the same workspace — orchestrator.py, data_logger.py, plus Aleks’s first-ROS-node tutorial.
Two notes on scope. First, not every node has a populated reference page yet — some are stubs that point at the implementation file in the source tree. That’s deliberate; we’d rather have honest stubs than fluffy filler. Second, this map describes the runtime topology — the architecture-level why (why these nodes exist, why they’re split this way) lives one level up, in the architecture section root.
Contents
Auto-generated from child entries during build (update-indexes.mjs).