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
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 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. 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
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 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 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 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. 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.
P.D.R.-M.: original draft preparation, original draft preparation, investigation and software, methodology, formal analysis, writing—review and editing; J.C.P.P.: resources, project administration; supervision; writing—review and editing, and funding acquisition. All authors have read and agreed to the published version of the manuscript.
Not applicable.
Data is contained within the article.
This work is part of the Danish Student CubeSat Project, which is a collaboration between Aarhus University, IT University of Copenhagen, University of Southern Denmark, and Industriens Fond.
The authors declare no conflicts of interest.
Footnotes
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
![View Image - Figure 1. V-model methodology applied to the payload design. Process: [Forumla omitted. See PDF.]. Iteration: [Forumla omitted. See PDF.].](https://media.proquest.com/media/hms/THUM/2/uNZ9b?_a=ChgyMDI2MDMwNTIyNTgwMjM5NjozNDIyODkSBzEzODMzMjMaCk9ORV9TRUFSQ0giDjIxNi43My4yMTYuMTc4KgcyMDMyNDA0MgozMTUzNzk5MTg1OgtJbmxpbmVJbWFnZUIBMFIGT25saW5lWgNJTEliBFRIVU1qCjIwMjUvMDEvMDFyCjIwMjUvMTIvMzF6AIIBIFAtMTAwMDA4NC0yMDEzOTUtU1RBRkYtbnVsbC1udWxskgEGT25saW5lygEOU2VhcmNoUmV0cmlldmXSARJTY2hvbGFybHkgSm91cm5hbHOaAgdQcmVQYWlkqgIbT1M6RU1TLUZ1bGxUZXh0LWdldEZ1bGxUZXh0ygIPQXJ0aWNsZXxGZWF0dXJl4gIA8gIA%2BgIBWYIDA1dlYooDHENJRDoyMDI2MDMwNTIyNTgwMjM5Njo5MTAyOTM%3D&_s=1iQG%2F9kb0Q4Xwnthj0zS7G58UMk%3D "View Image - Figure 1. V-model methodology applied to the payload design. Process: [Forumla omitted. See PDF.]. Iteration: [Forumla omitted. See PDF.].")
Enlarge this image.Figure 1. V-model methodology applied to the payload design. Process: [Forumla omitted. See PDF.]. Iteration: [Forumla omitted. See PDF.].
Enlarge this image.Figure 3. PCB electronic design: SoMs’ connection with the USB switch and cameras.
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 | 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 |
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 |
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 | ✔ | ✔ | ✔ | ✔ |
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 | ✔ | ✔ | • | ✔ | ✔ | ||
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 | ✔ | ✔ | ||||
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 | • | ✔ |
References
1. Iuzzolino, M.; Accardo, D.; Rufino, G.; Oliva, E.; Tozzi, A.; Schipani, P. A Cubesat Payload for Exoplanet Detection. Sensors; 2017; 17, 493. [DOI: https://dx.doi.org/10.3390/s17030493] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/28257111]
2. Mhangara, P.; Mapurisa, W. Multi-Mission Earth Observation Data Processing System. Sensors; 2019; 19, 3831. [DOI: https://dx.doi.org/10.3390/s19183831] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/31487970]
3. Liu, X.; Gu, K.; Li, M.; Cheng, Z. Optimization Design of Large-Aperture Primary Mirror for a Space Remote Camera. Sensors; 2023; 23, 5441. [DOI: https://dx.doi.org/10.3390/s23125441] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/37420608]
4. Bayer, R.; Priest, J.; Tözün, P. Reaching the Edge of the Edge: Image Analysis in Space. arXiv; 2023; arXiv: 2301.04954
5. Thornberry, T.D.; Gao, R.S.; Ciciora, S.J.; Watts, L.A.; McLaughlin, R.J.; Leonardi, A.; Rosenlof, K.H.; Argrow, B.M.; Elston, J.S.; Stachura, M. et al. A Lightweight Remote Sensing Payload for Wildfire Detection and Fire Radiative Power Measurements. Sensors; 2023; 23, 3514. [DOI: https://dx.doi.org/10.3390/s23073514] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/37050572]
6. Aksoy, A.K.; Dushev, P.; Zacharatou, E.T.; Hemsen, H.; Charfuelan, M.; Quiané-Ruiz, J.A.; Demir, B.; Markl, V. Satellite Image Search in AgoraEO. arXiv; 2022; arXiv: 2208.10830[DOI: https://dx.doi.org/10.14778/3554821.3554865]
7. Zhang, X.; Liu, Y.; Duan, H.; Zhang, E. Weak Spatial Target Extraction Based on Small-Field Optical System. Sensors; 2023; 23, 6315. [DOI: https://dx.doi.org/10.3390/s23146315] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/37514610]
8. Program DISCOSAT. DISCOSAT. 2024; Available online: https://discosat.dk/index.php/about/ (accessed on 21 September 2024).
9. Sánchez-Sánchez, F.A.; Vega-De-Lille, M.; Castillo-Atoche, A.A.; López-Maldonado, J.T.; Cruz-Fernandez, M.; Camacho-Pérez, E.; Rodríguez-Reséndiz, J. Geo-Sensing-Based Analysis of Urban Heat Island in the Metropolitan Area of Merida, Mexico. Sensors; 2024; 24, 6289. [DOI: https://dx.doi.org/10.3390/s24196289] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/39409328]
10. Dideriksen, A.K.; Andersen, M.F.; Priest, J.; Eriksen, N.F.; Frandsen, M.T.; Melvad, C.; Rasmussen, T.F.; Nielsen, N.H.K.; Strømsnes, C.T.; Ahlebæk, M.J. et al. DISCO-2—An ambitious earth observing student CubeSat for arctic climate research. Front. Remote Sens.; 2024; 5, 1474560. [DOI: https://dx.doi.org/10.3389/frsen.2024.1474560]
11. Nigussie, W.; Al-Najjar, H.; Zhang, W.; Yirsaw, E.; Nega, W.; Zhang, Z.; Kalantar, B. Enhancing Coffee Agroforestry Systems Suitability Using Geospatial Analysis and Sentinel Satellite Data in Gedeo Zone, Ethiopia. Sensors; 2024; 24, 6287. [DOI: https://dx.doi.org/10.3390/s24196287] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/39409329]
12. Edwar,; Oktaviani, S.M.; Santoso, A.T.; Abbas, Y.M.O.; Purio, M.A.C.; Mardiansyah, G. The Development of Experimental Remote Sensing Cubesat Payload Integrated with On-Board Classification Feature: The Progress and Educational Aspect. Proceedings of the IGARSS 2023—2023 IEEE International Geoscience and Remote Sensing Symposium; Pasadena, CA, USA, 16–21 July 2023; pp. 253-256. [DOI: https://dx.doi.org/10.1109/IGARSS52108.2023.10282012]
13. Liu, Q.; Chen, L.; Li, S.; Xiang, Y. Hybrid Multi-Access Method for Space-Based IoT: Adaptive Bandwidth Allocation and Beam Layout Based on User Distribution. Sensors; 2024; 24, 6082. [DOI: https://dx.doi.org/10.3390/s24186082] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/39338827]
14. Nabeel, M.I.; Singh, K.; Afzal, M.U.; Thalakotuna, D.N.; Esselle, K.P. Dual-Band Passive Beam Steering Antenna Technologies for Satellite Communication and Modern Wireless Systems: A Review. Sensors; 2024; 24, 6144. [DOI: https://dx.doi.org/10.3390/s24186144] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/39338889]
15. Bashir, S.M.A.; Mughal, G.A.; Mahmood, R.; Khurshid, K. Design and performance evaluation of low cost, medium resolution imaging payload for nanosatellites. Proceedings of the 2017 Fifth International Conference on Aerospace Science & Engineering (ICASE); Islamabad, Pakistan, 14–16 November 2017; pp. 1-7. [DOI: https://dx.doi.org/10.1109/ICASE.2017.8374285]
16. Pérez, A.; Fabregat, P.; Badia, M.; Sobrino, M.; Molina, C.; Munoz-Martin, J.; Fernandez, L.; Rayón, L.; Ramos, J. RITA: Requirements and Preliminary Design of an L-Band Microwave Radiometer, Optical Imager, and RFI Detection Payload for a 3U CubeSat. Proceedings of the IGARSS 2020—2020 IEEE International Geoscience and Remote Sensing Symposium; Virtual, 26 September–2 October 2020; pp. 5986-5989. [DOI: https://dx.doi.org/10.1109/IGARSS39084.2020.9324458]
17. Iqbal, U.; Barthelemy, J.; Michal, G. An End-to-End Artificial Intelligence of Things (AIoT) Solution for Protecting Pipeline Easements against External Interference—An Australian Use-Case. Sensors; 2024; 24, 2799. [DOI: https://dx.doi.org/10.3390/s24092799] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/38732905]
18. Rashed, M.I.; Bang, H. A study of cognitive computing in nanosatellite constellations for synergic autonomy in CisLunar space. Adv. Space Res.; 2024; 73, pp. 5614-5664. [DOI: https://dx.doi.org/10.1016/j.asr.2023.05.039]
19. Nagarajan, C.; D’souza, R.G.; Karumuri, S.; Kinger, K. Design of a cubesat computer architecture using COTS hardware for terrestrial thermal imaging. Proceedings of the 2014 IEEE International Conference on Aerospace Electronics and Remote Sensing Technology; Yogyakarta, Indonesia, 13–14 November 2014; pp. 67-76. [DOI: https://dx.doi.org/10.1109/ICARES.2014.7024379]
© 2024 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.
Details
; Priest, Julian Charles Philip