None of the three repositories on this page contain any code. skyhub_observer, skyhub_probe, and skyhub_carrier each hold exactly one README.md and one .gitignore — no source, no Dockerfile, no CI, no ECS service. They are name-claimed placeholders. Everything below about their role is inferred from the repo name and the single title line of each README, and is explicitly not a description of running software. Do not wire the Gateway, Dashboard, or deployment against them.
This page exists so a reader who finds these repos (or sees the names in a diagram) does not mistake them for live services like Janus, the WS Proxy, or SkyCore Drone OS. For the services that are implemented, start at the Ecosystem Overview and the Repository Map.

​
What “stub” means here

All three repos are byte-for-byte the same shape:
RepoPathTracked filesCommitsBranchesLast touched
skyhub_observer/home/skycore/Projects/skyhub_observerREADME.md, .gitignore2 (Initial commit → Update README.md)main only2024-08-19
skyhub_probe/home/skycore/Projects/skyhub_probeREADME.md, .gitignore2 (Initial commit → Update README.md)main only2024-08-19
skyhub_carrier/home/skycore/Projects/skyhub_carrierREADME.md, .gitignore2 (Initial commit → Create README.md)main only2024-08-19
Each README.md is a one-line title followed by a near-identical generic dev-principles boilerplate (DRY / KISS / YAGNI / SOLID) that seeds every new SkyHub repo — Observer and Carrier title the block “Software Development Principles” while Probe titles its “Development Principles”, with a few minor wording differences, but in every case it carries no architecture, API, or protocol information. The .gitignore is the standard GitHub Python template and is byte-identical across all three (diff reports no differences). That is the only forward-looking signal in the repos, and it is a weak one: it hints the authors expected to write Python, nothing more.
These repos have been dormant since August 2024. Treat any integration described elsewhere in these docs as aspirational until code lands and this page is replaced with a real service reference.

​
The three planned repos

Observer

Name implies a platform observability / spectator role. Intent unstated in-repo.

Probe (Prob-E)

A hybrid air + ground vehicle that flies and rolls, riding on the Carrier.

Carrier

A ground transport platform that carries the Prob-E vehicle.

​
Observer — skyhub_observer

The README title is just # SkyHub Observer. Nothing states its purpose. The name suggests one of two plausible future roles: a platform observability collector (aggregating metrics/events from Gateway, Janus, and drones) or a passive spectator client for watching a fleet without control rights.
If you are looking for platform observability that actually exists today, it is not here. Runtime telemetry and tracing are handled by the Gateway’s OpenTelemetry & SigNoz integration, and video plane observability by Janus event handlers. skyhub_observer duplicates none of that yet.

​
Probe — skyhub_probe

The README title is the most descriptive of the three:
README.md:1
# SkyHub Probe - It can fly and roll on the ground. Its using the carrier as a "carrier"
“Prob-E” is described as a hybrid vehicle that can both fly and drive on the ground, and that rides on the Carrier. If built as a drone-class vehicle, it would presumably run SkyCore Drone OS and therefore appear to the Gateway exactly like any other drone: a rosbridge WebSocket on port 9090 for commands and telemetry (see DroneControlService), video published through WHIP → Janus, and manual control through the WS Proxy. That is the pattern every SkyHub vehicle follows — but again, no SkyCore integration, ROS2 node, or firmware exists in this repo.

​
Carrier — skyhub_carrier

The README title:
README.md:1
# SkyHub Carrier - Its carrier for the prob-e ground vehicle.
A ground carrier / mobile base whose job is to transport the Prob-E vehicle. By analogy with the platform’s existing ground robots it would most likely be an ESP32/microcontroller UGV controlled through the gamepad path rather than rosbridge — the same class as the Rover/UGV firmware documented in Nexus AirHub & Ground Vehicle Firmware. Nothing in the repo confirms the controller, protocol, or drivetrain.

​
Where they would slot in (speculative)

The diagram below places the three planned repos against the existing platform. Dashed nodes and edges are the planned/unimplemented pieces; solid nodes are live services documented elsewhere. This is a design sketch to orient future work, not a description of current wiring.

​
For a future editor

Run git -C /home/skycore/Projects/skyhub_observer log --oneline (and the same for skyhub_probe, skyhub_carrier). If any repo has grown past its two seed commits or gained files beyond README.md / .gitignore, the service has started being built — retire this stub page and give that repo its own reference page under Ecosystem Services, mirroring ws-proxy or sitl.
There are no endpoints, env vars, Redis channels, or rosbridge topics to document because none exist. Resist the pull to “fill in” a plausible interface — the inferred roles above (observability, hybrid vehicle, ground carrier) are the only claims the source supports. Any concrete protocol claim must come from real code, not from the pattern its siblings follow.
Related live vehicles and hardware you can document today: Nexus AirHub & Ground Vehicle Firmware (battery-swap station + Rover/UGV ESP32 firmware) and SkyCore Drone OS (the ROS2 stack a real Prob-E would run).