What is GT Cloud Robotics?¶
A Georgia Tech Vertically Integrated Projects team building the infrastructure for deploying learned robot autonomy in the real world.
Robot autonomy is becoming more capable and more opaque at the same time. Hand-coded behavior trees are giving way to learned policies; learned policies are giving way to monolithic models that decode motor commands directly from pre-trained video. Policy capability is scaling faster than our ability to verify it, so certifying the whole stack stops being the right question. The right one is what contract sits between the opaque parts and the parts you trust, and whether it holds when what's above it changes.
We treat this at two layers, and the same architectural argument shows up at both:
- Across platforms. The pidgin protocol is the wire contract that composes heterogeneous vehicles into a single fleet through a capability-aware Physical API. Vehicles advertise capabilities; the protocol validates commands against them before routing. New vehicle types plug in as protobuf extensions with no core changes. The protocol stands on its own; any autonomy stack, GCS, or middleware can adopt it without buying into anything else we build. Tower is our reference operator UI on top of it.
- Within a platform. MAF is a C++ mission and integration runtime built around the authority boundary between high-level autonomy and the trusted low-level controller. A runtime monitor decides what commands cross it, a single-writer adapter is the only module in the system permitted to write to the controller, and a crash-isolated recorder captures the full state at the boundary. The certified surface stays small while the policy above can scale arbitrarily. Whether it's a hand-coded behavior tree, a single learned BT node, or a monolithic policy replacing the entire autonomy layer, the monitor, adapter, recording schema, and admission step stay the same.
Same pattern at both levels: keep the seams small, and vehicles, transports, and autonomy can change without breaking them. The two aren't symmetric in stakes, though. The pidgin seam decides whether new vehicles compose into a fleet; the authority boundary decides what a learned policy is allowed to command, which is why we can field one without verifying it. If the policy crashes, the autopilot stays up. If the vehicle crashes, the recordings tell us which side failed.
The initial demo targets a ground rover on ArduPilot Rover SITL with Gazebo; the same authority split is intended for later aerial vehicles.
Still in beta, still useful
Tower is in beta but already stable enough to back multi-domain research.
Explore¶
-
Course Home
What the course is, how it's structured, and what you'll build.
-
Tower C2
Mission planning and fleet monitoring across heterogeneous vehicles. Still in beta, already useful.
-
Pidgin Protocol
The wire contract for multi-vehicle fleets. Adopt it independently of everything else here.
-
Modular Autonomy Framework
The authority boundary between your learned policy and the autopilot. Field the policy without certifying it.