Getting to know Clustergate-2
Clustergate-2 is our second mission, designed to provide a cloud-like computing environment in space. It enables engineers and developers to easily deploy and run their software applications beyond Earth.
Clustergate-2 offers a flexible and powerful combination of software and hardware options, including:
- An Arm Cortex-A53 microprocessor
- A Jetson Orin Nano NX
- An UltraScale+ Xilinx FPGA
Developers have the freedom to choose how and where to deploy their applications, depending on their specific requirements.
In addition to compute resources, Clustergate-2 provides a rich variety of telemetry data for onboard processing. This includes everything from orbital and satellite health data to wide-angle camera images and LiDAR sensor readings. These resources open the door to a wide range of possible applications. For detailed information, please refer to the Telemetry section.
An ollama server will be running on GPU to easify interactions with some preloaded LLMs, please have a look here to have more details.
Software payloads are deployed using Docker containers, making it easy to bring existing applications onboard. Next section will briefly explain Docker containers. Workloads are automatically scheduled using Kubernetes, which optimizes performance and enables condition-based triggers—such as orbital position or satellite orientation. For example, developers can configure their containers to run when Clustergate-2 is flying over Uruguay, during an eclipse, or when the satellite is pointing directly downward (nadir).
The system handles all the complexity behind the scenes, allowing developers to focus on building their applications rather than managing deployment logistics. For a quick introduction on Docker Containers, check out the Docker Best Practices in Space section.
Dashboard
The dashboard is the primary interface for building, testing, and running payload software on DPhi Space systems. It lets you organize operations, manage namespace files, uplink and downlink data, and execute containerized workloads on Clustergate-2.
At a high level, you define operations in YAML. Those operations are executed as executions, which run task-by-task and capture logs, outputs, and state transitions.
What you can do
- Create namespaces to isolate operations and files on the ground
- Create operation templates that you can execute multiple times
- Upload files to on-ground namespace storage and downlink results from the system.
- Run DPhi Pods with your images and parameters.
- Track execution state, logs, and outputs in a single place.
Core concepts
- Namespace: A logical container for operations, executions, and files that live on the ground
- Operation: A YAML-defined workflow (tasks, parameters, and target system).
- Execution: A single run of an operation with state, logs, and outputs.
- Task: An atomic action (uplink, pod run, downlink, file list, Docker build, etc.).
Get started
Important notes
- Namespace file uploads are limited to 5 GB. Uplink limits to the system can be lower depending on the target environment.
- Use the Engineering Model (EM) for fast iteration and validation before running on the Flight Model (FM).
- Whenever an operation or a file is created for a namespace that does not exist beforehand, the namespace will be automatically created for it.
- File versioning is only maintained on the ground storage. If a file is uplinked onboard with the same name as a pre-existing file, it will be overwritten by the new uplink.
- Deletes are soft deletes unless noted otherwise. Deleted items are usually hidden from normal views rather than physically removed.