CubeSat Imaging Payload Design for Environmental Monitoring of Greenland

Abstract

Climate change affects the Earth’s ecosystem, and understanding human impact on sparsely populated polar regions is crucial, especially in glacial dynamics. Nanosatellites can play an essential role in monitoring remote regions due to their flexibility in adding remote sensors for Earth observation. However, they have hardware constraints such as physical space limitations, low power generation, and low bandwidth, as well as environmental challenges of vacuum, heat, cold and radiation. This paper details the preliminary system design of an imaging payload integrated into a nanosatellite for monitoring field study sites in Greenland. The payload is capable of supporting advanced image processing and Machine Learning (ML) applications. Key design elements, including the selection of imaging sensors, onboard processing units, and data transmission systems, which are optimized for the constraints of a nanosatellite platform, are presented. As a result, we presented a novel imaging payload system design, which shows a significant step towards leveraging space technology for environmental research.

1. Introduction

CubeSats have redefined the landscape of space exploration and technological innovation. These standardized cube-shaped nanosatellites, measuring multiples of 10 cm on each side, allow organizations and institutions of varying scales to participate in cutting-edge space explorations [1]. However, CubeSats face several challenges, one of which is the bandwidth limitation and short transmission windows from orbit to the ground station. In addition, power, thermal, and physical constraints require high standards to select the right electronic components given they are typically constructed from Commercial Off The Shelf (COTS) components [2].

CubeSats can be considered IoT devices that enable remote sensing applications to collect data for specific domains. For Earth observation, cameras are commonly installed in these satellites to meet their mission objectives, within the constraints of the platform. Multi-spectral imaging provides a comprehensive view of the targeted areas [3]. The wide-field camera captures larger geographic features, the telephoto camera covers targeted sites, and the infrared camera cab complement these with temperature-related imaging [4]. Together, these capabilities enable a multifaceted approach to data acquisition and analysis [5]. In addition, a processor unit must process images locally (on the satellite) or send them to the ground station. Furthermore, the development of the electronic part of the payload must take into account environmental considerations, ensuring the resilience of the payload to the harsh conditions of space [6]. Software integration must be meticulously planned to optimize data processing and transmission. The optics are engineered to meet exacting standards based on commercial machine vision cameras [7].

In this context, the Danish Student CubeSat Program’s (DISCO) second satellite design iteration is an Earth observation CubeSat (DISCO-2). The DISCO program is a collaboration between https://international.au.dk/ (accessed on 9 December 2024) (Aarhus University, Aarhus, Denmark), https://www.sdu.dk/en (accessed on 9 December 2024) (the University of Southern Denmark, Odense, Denmark), https://en.itu.dk/ (accessed on 9 December 2024) (the IT University of Copenhagen, Copenhagen, Denmark), and the European Space Education Resource Office Denmark, and pursues multiple objectives to cultivate expertise and interest within Denmark and in the wider field [8].

The broader goal of the DISCO project is educational, and aims to provide hands-on experience and to promote experiential learning within space technology [9]. Consequently, students at the bachelor’s, master’s and doctoral level are involved in all stages of concept development, design, production and operation of the DISCO-2 satellite. Nevertheless, the DISCO-2 satellite has a primary scientific mission objective, which was developed in collaboration with the Arctic Research Center (ARC) and the Interdisciplinary Centre for Climate Change at Aarhus University. DISCO-2 will provide temporal image data of designated areas in eastern Greenland, in support of ARC’s ground-based field research projects and ongoing glacier research activities, including photogrammetry of glaciers [10].

To do this, DISCO-2 will be placed in a Solar Synchronous Orbit (SSO) overflying Greenland up to eight times a day. The goal is to use capture and return only selected images containing relevant information for the mission, rejecting, for example, images with excessive cloud cover, fog, or without light. To enable these types of application, DISCO-2 dives into unexplored territory by testing machine learning image processing systems directly onboard the satellite, demonstrating a commitment to innovation and technological advancement [11].

The DISCO-2 satellite incorporates a range of modules, including the On Board Computer (OBC), which is responsible for system flight control, and the Power Distribution Unit (PDU), which orchestrates the operation of the other modules by power management [12]. The satellite includes an accurate Attitude Determination and Control System (ADCS) for orientation by using reaction/momentum wheels to counter-rotate through the conservation of angular momentum [13]. The ADCS is able to de-saturate the wheels by using magnetic coils, termed magnetorquers, to push against the Earth’s magnetic field. Solar panels and maximum power point tracker modules are used for power generation, a battery system for storage, and a power conditioning and distribution unit (PDU) is used for electricity management. The satellite has two radio modules, a UHF module for Telemetry Tracking and Command (TTC), and an S-Band radio for data transmission. Finally, the payload module is used for image capture processing and analysis [14].

This paper aims to present all the steps to design an imaging payload with the requirements needed to be deployed in a CubeSat. Therefore, we describe all components involved in deciding the cameras and the processor unit according to their specific tasks. Then, we describe all the functional requirements for benchmarking cameras and the process unit to find a suitable combination. As the electronics are designed to work in the harsh environment of Low Earth Orbit (LEO), we explore different hardware configurations to provide a redundant system. We include the capability to execute accelerated ML model inference onboard the satellite, with a sample use case of a model to discriminate ice or clouds in images, dismissing those below a quality threshold. Finally, the payload must interface with the other electronics in charge of operating the satellite and communicate with the ground station.

2. Materials and Methods

To define the hardware and software requirements along with the payload design and select the suitable cameras, we used the V-model software design methodology, which is a graphical representation of a system development life-cycle [15]. The V-model summarizes the main steps in conjunction with the corresponding deliverables at each stage and the way to prove that all the requirements will be satisfied. It describes the activities to be performed and the results that must be produced during device development. In short, the left side of the “V” represents the breakdown of requirements and the creation of system specifications. The right side of the “V” represents the integration of parts and their validation [16]. In this scenario, we modified some stages to match the satellite development and reduce the complexity of the V-model. Figure 1 shows the V-model designed for this project.

The CubeSat imaging system for environmental monitoring of Greenland aims to deploy a compact and efficient satellite payload equipped with three specialized cameras to capture data about the Greenlandic environment. This project combines cutting-edge imaging technology, data processing, and satellite communication to provide insights into Greenland’s changing climate and environmental conditions. These key components are presented as follows:

• Wide Field Camera: The wide-field camera is designed for panoramic imaging and captures broad overviews of Greenland’s landscapes. This camera provides context and an overall understanding of the geographical features [17].
• Telephoto RGB Camera: Focused on high-resolution RGB imaging, the telephoto camera captures detailed visual data of glaciers in Greenland, with the goal of creating time series of 3D models of glaciers by photogrammetry. This camera is therefore instrumental in monitoring changes in land cover, identifying potential environmental shifts, and assessing the impact of human activities [2].
• Infrared Camera: The infrared camera measures surface sea temperatures around Greenland. This crucial data help in studying the temperature variations, detecting potential anomalies, and understanding the thermal dynamics of the sea and rivers around glaciers [7].
• Image Processing Unit: The image processor unit is responsible for capture and real-time processing of the images. As well as traditional image processing tasks, such as cropping or compression, an ML model can be used to identify and tag relevant images for transmission or deletion. This intelligent filtering minimizes the amount of data sent to the ground station, optimizing bandwidth usage [18].

Given the harsh environmental conditions in space, the project adheres to strict benchmarking and requirements, including:

• Temperature Resilience: The entire system, including cameras and the image processor unit, must operate efficiently within a wide temperature range to withstand the heat and cold of Low Earth Orbit.
• Data Integrity and Security: The image processor unit should ensure the integrity and security of processed data, as any anomalies or errors in the collected information could compromise the scientific accuracy of the project.
• Power Efficiency: All components must be energy-efficient to maximize the instrument’s observational time whilst keeping within the power budget of the satellite.
• Communication Reliability: The communication system must be robust and reliable, allowing seamless transmission of image data to the radio module without interrupting other on board communications.

2.1. Hardware Requirements

To determine the most suitable camera for integration into the payload, we established specific preliminary requirements recognizing the pivotal role of the camera sensor as the core component. Our selection process was then guided by these criteria to ensure seamless interaction and optimal performance within the CubeSat system.

Table 1. Camera requirements.

ID	Requirement	Specification	Priority
Recam_1	Sensor size	4512 × 4512 px	High
Recam_2	sensor aspect ratio	(1:1)	High
Recam_3	Pixel pitch	≤2.7 µm	High
Recam_4	ADC bit depth	10 or 12 bits	Low
Recam_5	Color	RGB	High
Recam_6	spectral range	300 to 1100 nm	High
Recam_7	Resolution	20.4 or 16.2 mega pixels	High
Recam_8	Shutter	GS global shutter	High
Recam_9	Exposure modes	auto or manual	High
Recam_10	Processing features	binning, cropping	High
Recam_11	Operating temperature range	$-20\ge +65$ °C	High
Recam_12	Documentation	ruggedness vibration and thermals	High
Recam_13	Driver compatibility	linux	High
Recam_14	Lens compatibility	C-Mount	High
Recam_15	Lens mount face Interface	17.2 mm	High
Recam_16	Communication	USB2 OR USB3 and CAN	High
Recam_17	Camera control	GPIO or CAN	High
Recam_18	Power draw	<3.7 W	High
Recam_19	Sleep modes	<1 W	High

shows the most relevant requirements for selecting the suitable camera. Initially, we based our search on using the same camera model for both wide-field and telephoto cameras, but with different lens pairings. At the preliminary design stage, we did not calculate specific lens–sensor pairings.

The image processor unit (IPU) controls the cameras and collects and processes the images [19]. Then, the IPU is designed to process the image using ML to determine if the image contains relevant information, and then to send them to the radio for transmission to the ground station when the satellite passes over Denmark. Therefore, its dimensions, ML capability, and power consumption are some of the main requirements shown by

Table 2. IPU requirements.

ID	Requirement	Specification	Priority
Repro_1	Dimensions	10 × 70 × 80 mm	High
Repro_2	Hardware accelerator	TPU or NPU	High
Repro_3	Time to reboot	ms	High
Repro_4	Multi-camera setups	3	High
Repro_5	Operating temperature range	−20 ≥ +65 °C	High
Repro_6	Documentation	ruggedness vibration and thermals	High
Repro_7	Driver compatibility	linux	High
Repro_8	ML support	Frameworks	High
Repro_9	Nominal Power	<3 W	High
Repro_10	Peak Power	<5 W	High
Repro_11	Sleep modes	<1 W	High

. The requirements provide insights into selecting suitable IPU boards afterwards.

2.2. System Design

Several camera sensor brands can provide cameras and their corresponding support. For CubeSats, it is typical to use COTS components and we focused on industrial machine vision camera ranges for their small size and rugged specifications. In terms of sensors, we chose Sony’s IMX-series since they provide a high-quality CMOS image sensor. Furthermore, The IMX-series models are among the sensors most frequently used in industrial cameras. One of the reasons for the high image quality of IMX-series is the unique technology from Sony called Exmor, in which the noise-reduced analog signal recorded by the sensor is converted into a digital signal directly when the pixels are read out https://www.sony-semicon.com/en/products/is/camera/index.html (accessed on 9 December 2024), (Sony, Copenhagen, Denmarr).

The IMX series sensor provides different options regarding the target application; in this case, the IMX-541 fits all requirements, and the IMX-545 only lacks the aspect ratio requirement, which is affordable in the application and is also considered. As a result,

Table 3. IMX sensor evaluation. Fully covered: ✔, partially covered: •.

Requirement	Sensors’ Camera
	IMX304	IMX253	IMX545	IMX541
Recam_1			✔	✔
Recam_2		•	•	✔
Recam_3	✔	✔	✔	✔
Recam_4	✔	✔	✔	✔
Recam_5	✔	✔	✔	✔
Recam_6	✔	✔	✔	✔
Recam_7			✔	✔
Recam_8	✔	✔	✔	✔

shows how the IMX-series sensor fits the established requirements.

Once the camera sensor was targeted, several camera providers used these sensors to build robust cameras; we established contact vendors to obtain the camera datasheet and its support. It should be noted that we placed high priority on non-technical issues listed under Recam 12 and included vendor support, documentation and community activity in our deliberations. It is our experience that these factors have an outsized impact on ease of development and project timelines.

Table 4. Cameras’ model benchmarking. Fully covered: ✔, partially covered: •.

Requirement	Camera Providers
	U3-3990SE-C-HQ	U3-31L0CP-C-HQ	U3-31L1SE-C-HQ	mvBlue FOX3 2051aC	Alvium 1800 U-2040	Alvium 1800 U-1620	Alvium 1800 U-1242
Recam_9	✔	✔	•	✔	✔	✔	✔
Recam_10	✔	✔	✔	✔	✔	✔	✔
Recam_11	✔	✔	✔	✔	✔		✔
Recam_12	✔	✔	✔		✔	✔	✔
Recam_13		✔		•	✔	✔	✔
Recam_14			✔		✔		✔
Recam_16	✔	•		✔	✔	✔	✔
Recam_18			✔	✔	•	✔	✔

shows the cameras that best matched the established requirements. In this case, Alvium cameras provide the most suitable configuration, especially the power consumption requirement. Therefore, Alvium U-1242 matches all requirements, and its friendly software environment allows a feasible integration. In the first integration round, this camera was selected.

On the IPU benchmarking side, we rigorously evaluated the IPU’s processing speed, accuracy, and overall computational capabilities using a comprehensive set of benchmark results developed by another team within the project [4]. The benchmarking process encompasses a range of image-processing tasks, including image recognition, feature extraction, and real-time processing. The objective was to quantify the IPU’s ability to handle diverse workloads efficiently and effectively. Moreover, benchmarking considers the system’s responsiveness to varying levels of input data, providing insights into its scalability. Special attention was given to time-to-completion metrics, aligning with the stringent developing time requirements. Space limitations, hardware complexity, and power consumption are also factored in, ensuring a holistic assessment of the IPU’s performance within the confines of the electronic system. We targeted the i-MX 6 and i.MX8 from NxP semiconductors, since they are powerful processors where power efficiency, computational performance, and space constraints are critical. The i.MX 6 offers robust processing power with lower energy consumption, suitable for basic ML tasks and satellite functions. In contrast, the i.MX 8 provides enhanced processing capabilities and NPU acceleration, enabling more complex ML algorithms and real-time data processing in orbit. As well as chip-only designs, we also identified System on Module (SOM) systems using the target processors. The SOM approach can remove the need for complex high-speed PCB design from the project, leaving the more manageable electronics design tasks of interface and power supply. SOMs based on the i-MX6 and i.MX8 are designed by several industrial device manufacturers. Therefore, we looked for the smallest SOMs that also have integrated with ML modules. As a result, we identified Toradex and PicoCore as manufacturers who develop industrial SOMs matching the above-established requirements. Those SOMs were selected for the integration step.

Table 5. IPU benchmarking. Fully covered: ✔.

Requirement	Image Processing Units
	i.MX 6 UL	i.MX 8Xlite	i.MX 8M	Toradex	tqmA93 XXLA	PicoCore MX8
Repro_1	✔	✔	✔	✔	✔	✔
Repro_2	✔	✔	✔	✔	✔	✔
Repro_3	✔	✔	✔	✔		✔
Repro_5	✔	✔		✔	✔	✔
Repro_8		✔	✔	✔	✔	✔
Recam_9				✔		✔
Recam_11				✔		✔

summarizes the IPU benchmarking.

3. Modular Design

The ML payload is briefly described as follows. The IPU, which is the SOM, triggers image capture using the wide field and telephoto cameras. Then, it applies an ML model to recognize if each image contains relevant information to be sent to the ground station through the radio module. The SOM contains a co-processor that allows accelerated machine learning applications to analyze images. This procedure must be performed because the satellite has a limited bandwidth to download data. Furthermore, the satellite PDU has two channels available to provide power to the payload. The SOM modules that are capable of this image processing task use more power than can be provided by the PDU continuously. Thus, the SOM must be in sleep mode for the majority of an orbit to save energy, waking only during observation and transmission. These duty cycles are modeled in other work by the group. Furthermore, the CSP network onboard the satellite is based on CANBUS and has limited bandwidth, and the payload needs an extra communication network to send the images directly to the radio module. The software integration aspect tends to match the operation between the cameras and the image processing unit. Redundancy features are integrated to ensure robustness, providing fail-safe mechanisms in case of unforeseen circumstances. The system is engineered to minimize power consumption, promoting energy efficiency. Seamless communication integration facilitates data exchange between the cameras and the processing unit. However, some hardware designs were developed to reach the requirements mentioned above, which are described as follows:

• Design 1: It is the most straightforward configuration since it uses one single SoM, and the cameras are attached to it by individual USB ports. The PDU powers on/off the system and sends messages by CAN protocol. Finally, an extra communication protocol is set to send the images directly to the RF module. However, if the SoM fails, the cameras do as well.
• Design 2: This design aims for a fully redundant system where each camera and its images are processed in dependent SoM. Each SoM needs to be part of the CAN bus to exchange messages with the PDU and follow the same idea with the RF module. This hardware configuration demands a high power draw.
• Design 3: To obtain redundancy and keep the power consumption low, two cameras are connected to one SoM, and the last camera to another SoM. The PDU is the communication bridge between SoMs. Nevertheless, if one SoM fails, the other cannot take over the cameras.
• Design 4: The hardware configuration has two SoMs; only one is constantly running, and the other is sleeping and it can be awake only if the first SoM fails. However, it is necessary to build a USB switch to switch between SOMs, meaning there is one failure point in this configuration. Each SoM is part of the CAN communication, sending messages to the PDU and the radio module (RF).
• Design 5: It is the most robust configuration where the whole system is built from scratch without using any commercial SoM and designed as a fully customized board. However, it demands extra effort in the PCB design and software integration.

These hardware configurations (Figure 2) were evaluated by faculty members in electronic design, software integration, and IoT from the Danish universities mentioned above. They scored each configuration independently, and then we summarized those results to present them in

Table 6. Electronic design benchmarking. Fully covered: ✔, partially covered: •.

Requirement	Design 1	Design 2	Design 3	Design 4	Design 5
Developing Time	✔	✔	•	✔
Space limitation	✔	•		•	✔
Hardware complexity	✔	•		✔
Software Integration	✔	•		✔	✔
Redundancy		•	•	✔	✔
Power consumption	•		•	✔	✔
Communication integration	✔	•	•	•
Developer expertise	•	•	•
Device efficiency				•	✔

. As a result, Design 2 was assessed to be very complex, and it did not fulfill the hardware limitations. Design 3 failed to provide redundancy, and each SoM did not handle all the cameras. Furthermore, Design 5 was assessed to take longer than the required development time, and it could require extra knowledge in hardware design. As a result, Design 1 is the most straightforward configuration, and the team agreed to move forward with it to test the SoM and cameras. Then, when the whole hardware was tested, the target configuration was Design 4, which provides additional redundancy.

4. Results

The preceding sections describe the design development up until the preliminary design review. This section details the further design development stage in which the overall design and components are integrated into a full system design. Details of the later integration stage testing and completed development and integration of the payload will be addressed in a follow-up publication.

4.1. Design Development

The USB switch communicates with the SOMs so that both are connected using a single USB port. The selection of each SOM comes from the PDU, which has two independent voltage and signaling channels. This ensures that under no circumstances do both SOMs operate simultaneously. In addition, the USB switch has data flow control diodes to avoid collisions in the messages. After the SOM is selected, the USB switch has an internal two- to four-channel mux-demux so that the SOM can communicate with each camera. Its selection comes from a decoder of digital inputs to the output of the mux-demux so that only one camera can establish communication with the SOM. The decoder inputs are also multiplexed for the two SOMs using GPIO digitally. In addition, the cameras are powered by a voltage line from the PDU independently of the SOMs. However, this device is not commercially available, and it is necessary to develop it from scratch.

Each SOM is connected to the other modules on the satellite, including the OBC via CANBUS, and using the CSP protocol for communication. In order not to block the control channel during bulk image data transfer, each SOM must also be connected to a high-speed RS-422 bus to send images directly to the RF module. Ethernet is included on the SOM and was also considered for the data bus, but excluded for power consumption and complexity. RS-422 has sufficient data transfer capabilities compared to the radio downlink, and is simple, noise-tolerant and robust. Finally, a 3.3-volt converter is needed to power the USB switch and GNSS module. The GNSS communicates with the SOM using the SPI protocol. The electronic diagram payload is presented in Figure 3.

4.2. Integration Development

Once the electronic design was updated with part dimensions and footprints, the PCB and SOM dimensions were assessed to fit the enclosure’s space limitations. Based on this primary requirement, TORADEX SOM was too large and needs extra thermals to decrease heat. Conversely, PICO SOMs are small and compact, which matches our PCB design and the available space. Therefore, the Payload PCB is based on a highly modifed Evaluation Base Board PicoCore™MX8MP-V4I-LIN from F&S Electronics. We customize it by removing unnecessary components and adding our own for optimal functionality, and exposing interfaces with components that are verified to be compatible with the other satellite modules.

Figure 4 shows the 3D representation of the designed PCB within the physical limitations of the enclosure.

In parallel structural work, the payload bracket and enclosure were combined to produce a single 3D-printed part that houses the PCB and holds the cameras and lenses. A harness connects the cameras via USB to a single connector on the PCB. The enclosure design incorporates thermal chimneys, and a thermal solution is developed to manage heat dissipation for the cameras.

The power budget for the PCB is 6 watts peak, since the Alvium cameras need 3 watts, one PICO CORE running draws 3 watts, and the IR camera needs 1 watt, and only one camera and one SOM are used at once. This power is managed throughout the orbit with aggressive use of duty cycles with the SOM in sleep mode apart from during transmission and observation. Further, the iMx8 processor chosen has multiple cores, 4 × A53 for the Linux system, the NPU for ML acceleration and a low-power M7 micro controller. It was found that the M7 can suspend and wake the A53 cores whilst drawing 1W or less. The choice of SOM therefore provides a handy mechanism for keeping the payload operational in orbit within the budgeted nominal power budget of 1W. This solution is developed and further tested in the next stage of the project.

Figure 5 shows the full imaging payload ready for deploying into a CubeSat.

The software used on the DISCO-2 satellite and ground segment system is distributed with each module and processor being accessible as separate nodes using the CubeSat Space Protocol (CSP), which is a simplified TCPIP-like networking protocol stack designed for CubeSats. Onboard, this is presented over CANBUS and RS422, and allows communication between all nodes. Consequently, the Camera Control software, image processing pipeline and payload scheduler on the SOM are also designed to appear as separate CSP nodes. The A53 SOM cores run a custom lightweight Yocto GNU/Linux, whilst the M7 core runs libcsp on FreeRtos with software written in C and C++ drivers for the camera controller. Finally, the payload software stack features a flexible image processing pipeline that can be remotely configured for different image processing tasks including ML inference, and is capable of over-the-air updates whilst in orbit.

5. Discussion

The current article presents the design process for a novel CubeSat Imaging payload capable of high-resolution image capture, with on-satellite image processing including the use of ML accelerators. The article follows a clear design methodology and presents results up until the development stage of the project. Clearly, the detailed design work, test schedule and presentation of the empirical validation of the design are out of the scope of this article, and while they are in progress, they are detailed as future work, as is publication on the software development. The scientific case for the satellite and the processor selection benchmarking are covered elsewhere.

Typically satellite imagery is transmitted to Earth for processing and analysis, but in this design, we attempt to present a viable on-satellite analysis system that is feasible within the tight constraints of the CubeSat form factor.

As we demonstrate here, recent advances in embedded processors such as the iMx.8 are providing rich opportunities for powerful, compact and flexible systems, and multi-core systems such as the one demonstrated here can provide low-latency on-chip connection to both ML co-processor hardware, microcontrollers, and full operating system-capable microprocessors. This provides additional design flexibility in both software design and flight planning.

In CubeSat development in general, COTS parts from industrial or automotive vendors are used as opposed to the space qualified equipment found in larger space programs. The advantages are in the wide range of product options available, as well as much lower cost and lead time, while disadvantages are lack of clear Technology Readiness Levels or conformance to rigorous published space-related standards.

In particular, we find a proliferation of appropriate SOM module vendors. The use of SOM modules can reduce design complexity, development risk, and hence timelines by simplifying the custom electronic development needed to complete a module. Likewise, industrial machine vision cameras can provide a viable alternative to specific satellite imager designs.

This approach is distinct from highly customized development approaches often found in scientific instrument making, where a scientifc goal drives a highly specific instrument design. In the case of DISCO, we aim to provide a flexible platform for a range of future student experimentation, and the design approach focuses on building a system from a collection of existing hardware. In this case, a strong methodology of defining requirements and evaluating a wide range of devices is appropriate. It is our experience that it is not only the technical specifications that are important to recognize, but also what might be termed social aspects of vendor communication, documentation quality, lead times and user community. In future design processes, we would increase the range of this type of requirement, and also perhaps develop technical means to undertake systematic product searches.

A large number of functional, integration, system, environmental and qualification tests are either completed, underway or planned before launch. Our test suite includes thermal, vacuum, vibration, electrical, communications, radio transmission, optical calibration, software performance, power consumption, networking and in some cases radiation testing. We look forward to presenting the results in future work.

6. Conclusions

This work aims to develop an imaging payload for a cube satellite; this project is part of the DISCO program, in which three Danish universities are involved. The imaging payload has three cameras (i.e., wide field, telephoto, and infrared) and redundant image processor units. Hardware and software requirements were defined to select the suitable cameras and image processor unit. Alvium cameras proved to be an adequate selection due to their power consumption, robustness, and software integration. System on module devices were found to be a good match with the selected cameras, the software requirements and development timeframes. Consequently, the PicoCore brand, a compact SOM with an ML accelerator core to speed up the inference process, is the target image processing unit. Furthermore, to save energy and create a redundancy system to interact with cameras and the PDU, a USB switch was designed and developed to select the SOM and the camera. The proposed methodology proved to be an excellent reference for structuring the design process and checking the requirements of the developed system; also, it is helpful to document the system correctly for further interactions or later production runs. As a future work, once the satellite is completed and launched, the next step is to develop a range of ML applications and models that leverage the hardware and software capabilities of the system, and compare those to other approaches. We look forward to the forthcoming launch of our satellite DISCO-2 and to presenting an evaluation of these design methodologies with empirical data from the test series and in orbit operations.