Skip to main content

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​

  1. Namespaces
  2. Operations
  3. Executions
  4. Tasks
  5. API
  6. Onboard File Storage
  7. Examples
  8. FAQ

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.
danger

The pod run task is currently non-blocking. A pod can be scheduled while the task reports success, even if it has not started running yet (depending on the scheduled time). Subsequent tasks will continue immediately, which can cause failures like downlinking a file that the pod has not produced yet. A blocking parameter is in the works and we will address this as soon as possible. Until then, run pod tasks and downlinks in separate executions to avoid failed downlinks.