Disclosure: I work with SOLARTODO LIMITED, the team behind SKYHUB. I’m posting here as a vendor to share how we approach ROS 2 integration on an air–ground system, and to get the community’s input on a few design questions we’re still weighing.
The setup
SKYHUB pairs three assets at one site: an STT 1S MAX drone, an STT-HUB1101 four-bay battery-exchange hangar, and one bipedal humanoid ground robot, either the compact STTBOT-S1 or the larger STTBOT-T1. The drone gives an overview. The robot gives the close, ground-level view the aircraft can’t: behind a parked vehicle, inside a doorway, the far side of a wall.
The core idea is one record, not two machines. A single event ID is attached to the aircraft route, the hangar’s battery-exchange record, the robot task, every alarm and the final report. If the drone and the robot disagree about what they saw, the operator console shows both observations rather than silently picking one.
The robot side
Both STTBOT models carry a layered perception stack:
- RGB up to 1920 × 1080 @ 30 fps
- Stereo depth up to 1280 × 800 @ 30 fps (recommended working range ~0.26–3 m)
- 3D LiDAR, 360° horizontal, −7° to +52° vertical, up to 200k points/s
- Six-axis IMU plus joint and balance feedback
Onboard compute has 16 GB of memory and module peak performance of up to 78 dense / 157 sparse INT8 TOPS. Connectivity is Wi-Fi 6, Bluetooth 5.2 and Ethernet/USB. SDK, motion-control and ROS/ROS 2 integration are available according to the supplied configuration and authorized access. In practice that means ROS 2 interfaces are a configuration item scoped per project, not a fixed default.
Charging is a 200 W contactless dock, separate from the aircraft’s battery bays. It only energizes after dock alignment is confirmed, a foreign-object check passes and the BMS grants permission. Charge status is reported over UART or CAN.
Safety rules that shape the architecture
These are the rules that most affect how we split responsibilities between nodes:
- Separation: the robot doesn’t enter the landing and rotor exclusion zone while the hangar is receiving or releasing the drone.
- No inherited permission: a robot following up an aerial event doesn’t inherit the aircraft’s clearance. Physical contact with infrastructure or a person needs a separate operator decision.
- Local control stays local: balance and contact control run on the robot. If a person enters the path or balance confidence drops, the task is held for supervisor review instead of being re-planned remotely.
- Energy priority: an urgent ground finding never justifies delaying a low-energy aircraft return.
The event flow itself is simple: trigger → operator review → dispatch (aircraft, robot, or both, separately or in sequence) → execution under the shared event ID → closure with a recorded disposition.
Questions for the community
We’d really value input from people who’ve built multi-robot or heterogeneous systems on ROS 2:
- Shared-event coordination: How do you model a cross-robot “event” in ROS 2? A dedicated event-manager node exposing actions per asset, a lifecycle-managed state machine, or something like a shared event topic with each robot publishing status against the ID? How do you handle conflicting observations without one asset overwriting the other?
- Local vs. central authority on humanoids: For balance and contact control, we keep everything on-robot and let the central side only hold or release tasks. Has anyone found a clean ROS 2 pattern (e.g. lifecycle nodes, behavior trees, safety supervisors) for expressing “the planner can request, but the robot can refuse”?
- Middleware for air–ground links: With the robot on Wi-Fi 6 and the aircraft/hangar on a separate link, what DDS/RMW choices and QoS settings have worked for you across intermittent wireless segments? Zenoh bridges, discovery servers, or partitioned domains?
Happy to share more detail on the event model or the safety rules if it’s useful. Critique very welcome.
— Cinn, SOLARTODO LIMITED · cinn@solartodo.com