SEDSAT-2 Payload Design Review III

From SEDSWiki

Earth Imaging System (EIS) Design Review III

Contents 1 Current (active) members) 2 Timeframe for completion 2.1 Preliminary design 2.2 Prototyping stage 2.3 Software testing 2.4 Flight hardware design 3 Current State of Subsystem 4 Current Design 4.1 Requirements 4.2 Payload Processing Unit (PPU) 4.3 Flash Memory 4.4 Imaging Device 4.5 Optical System 4.6 Analysis and Ranking Algorithm 5 Preliminary Figures 6 Financial Situation 7 Personnel Situation 8 Command Set 9 Summary

Current (active) members)

• Tom Nordheim (subsystem leader)
• Michael Clarke
• Alasdair MacLeod
• Brynjar Larssen(?)

Timeframe for completion

Note: Analysis and ranking algorithm not included in this estimate

Preliminary design

Deadline: 15 March 2009

• 1.Decide on microcontroller
• 2.Decide on lens type and mounting (produce simple CAD drawing of subsystem)
• 3.Define preliminary command set together with CDH
• 4.Obtain development tools required for microntroller

Prototyping stage

Deadline: 15 July 2009

• 1.Implement Linux on chosen microcontroller platform (including drivers for on-board peripherals that are needed).
• 2.Implement interface between microcontroller and flash memory
• 3.Implement interface between microcontroller and imaging device
• 4.Develop functionality for capture and storage of images

Software testing

Deadline: 15 August 2009

• 1. Test basic EIS software

Flight hardware design

Deadline: 15 December 2009

• 1. Design PCB of EIS system (including optical system).
• 2. Assemble EIS system HW.
• 3. Test EIS system HW (temperature, shock etc).
• 4. Re-design of EIS system (if required).
• 5. Re-test of EIS system HW (if required).
• 6. Subsystem integration

Current State of Subsystem

No work has been carried out during the last 6 months due to the fact that there were no active team members. New team members have been recruited and a fresh effort to restart the design process has been initiated. Several issues related to the previous design have been identified and as a result the subsystem design has been changed significantly. Due to this a second cycle of subsystem design and prototyping must be undertaken.

Current Design

Requirements

• The SEDSAT-II Earth Imaging System (EIS) shall be capable of capturing and storing images on receipt of appropriate command from CDH
• EIS shall be capable of providing CDH with valid pointers to images stored in the EIS flash storage.
• Images shall be compressed by EIS either by hardware or software methods.
• (Secondary) EIS shall be capable of analyzing captured images and ranking these based on a set of pre-determined values related to image quality.
• (Secondary) EIS shall be capable of ranking captured images and placing these in a priority downlink que based on the quality of the image.

Payload Processing Unit (PPU)

Previously the AtmelUC3had been selected as the PPU controller. This approach was based on the development of a standalone embedded application for the UC3. As software development was undertaken on this platform it became clear that there would be several major benefits from employing an operating system rather than developing standalone code:

• Drivers for the selected Omnivision camera module were available for Linux. These could potentially be adapted with little added development effort.
• Memory management would be greatly simplified.
• The interface between the onboard flash memory and the PPU would be simplified as a file system would be present.
• Potential for significantly shorter development time as it would be possible to make greater use of pre-existing software libraries. This is especially significant for image processing application.

Initially it was planned to compile a Linux distribution to run on the AtmelUC3 but this proved to be a difficult task as:

• The AtmelUC3 does not possess an Memory Management Unit. It should be noted that as of the Linux 2.6 kernel there is now native support for processors without a Memory Management Unit.
• It would require the adaptation of the compiler (GCC), Linux kernel, development toolchain and the UC3 bootloader. This would require a significant amount of time and considerable effort.
• Even given that the above would be achieved it is likely that there would be a requirement for the adaptation/construction of drivers associated with the UC3 peripherals. This would require further time and effort.

It was identified that given the effort required to run a Linux operating system on the UC3, it was not sensible to continue development on this platform. Microcontrollers based on the ARM platform are relatively comparable to the Atmel UC3A and UC3B controllers in terms of both processing power and power consumption. Examples of such controllers include the Atmel ARM9 series microcontrollers such as the AT91SAM9261 thumb microntroller which is capable of providing 210MIPS with a dynamic power consumption of 50mA. This compares favorably to the Atmel UC3B0256 which is capable of delivering 72DMIPS with a power consumption of 23mA. Further studies are required but the following has been concluded:

• The PPU will run a Linux operating system
• The Atmel UC3 has proven to be unsuitable for this applicaiton. Alternatives such as microcontrollers based on the ARM architecture should be considered. The Atmel ARM9 series is a candidate.

Flash Memory

A standard MicroSD flash card will be used for image storage. The Secure Digital (SD) standard is well documented and support the use of the SPI interface found in most microcontrollers (including those evaluated for the PPU controller). These memory cards offer high storage density, acceptable operating temperature ranges and a well-documented interface. As retention of imaging data is not critical to the basic functionality of the satellite bus this is not seen as an area were increased robustness or redundancy is required.

Imaging Device

The imaging deveice will be an Omnivison CMOS camera. This manufacturer was chosen as the Omnivision Serial Camera Control Bus(SCCB) is well documented and secondly for the fact that Omnivision offers System-On-a-Chip (SoC) solutions that are well suited towards this application. Specifically the payload team has been looking at the 3.2m egapixel OV3642 and the 2.0 megapixel OV2640 imagers as these come in a convienient package (CSP2) and offer on-board hardware image compression. Currently prototyping is being carried out using an Omnivision OV6630 VGA CMOS imager.

Optical System

Currently there has been no research on what type of optics is to be used. As there are no requirements with regards to ground resolution it is not required to implement a high performance lens system. A basic plastic lens will most likely be sufficient, yet it is possible that a lens with an increased temperature range be used. In addition it might be advantageous to implement filters to improve imaging conditions (solar filter). Both the mounting for the camera optics and the lens itself will be required to survive launch and must therefore be robust. This part of the subsystem requires further studies.

Analysis and Ranking Algorithm

The onboard image analysis and ranking algorithm is a secondary objective for the EIS design and is intended to increase the quality of images downlinked from the satellite. The main reasons for this are:

• Satellite lifetime can be limited.
• Telemetry downlink capacity is very limited.
• High quality imagery is easily appreciated by the general public

Based on a set of pre-determined conditions captured or stored images are evaluated using the appropriate image analysis techniques. The aforementioned conditions can be based on the analysis of one or several types of image features, including:

• Brightness (very low brightness indicates empty space, very high brightness indicates that the camera is pointed at the Sun etc).
• Color (blue represents ocean etc).
• Sharpness.
• Geometric shapes (surface features, cloud patterns etc)

Based on the selection of these critera an image analysis algorithm will be constructed. The original approach was based on the implementation of these image analysis features as a standalone embedded application on the Atmel UC3B 32-bit microcontroller. This approach was abonded as the use of the UC3 implied that it would be necessary to develop all image analysis functionality from scratch, a process which would have proven time-consuming and less likely to yield results comparable to those obtained through the use of pre-existing computer vision libraries.

As the UC3 has been abondened in favour of an ARM-based platform running the Linux operating system, it makes it possible to use pre-existing computer visions librarie and provides the design team with the possibility of using a wealth of code developed for the considerably more popular ARM/Linux platforms.

Preliminary Figures

• Mass: 50-100g (200g allocated in mass budget ¹)
• Dimensions: 75cm^3 (5x5x3cm)
• Operating Voltage: 3.3VDC
• Control Interface: Philips I²C
• Data Interface: Serial Peripheral Interface SPI
• Maximum current drain: 150mA

¹ Spare mass allocated to secondary payload.

Financial Situation

The university has so far provided funding for the components and tools needed to develop a prototype. Additionally the payload team has been sponsored with development tools by Atmel Norway. Travel costs are not an issue as all team members are in the same location.

Personnel Situation

Given recent recruitment the current personnel situation is deemed to be adequate but minimal given the timeframe for completion of the subsystem. Further recruitment is being pursued.

Command Set

[Command] Response

• [wake up] pin signal
• [sleep] pin signal
• [ping] pong!
• [Capture single image (, with settings C) ] Image ID + Capture Time
• [Capture x images ( intervall y, with settings C) ] First Image ID + Capture Time
• [Request list of image files] image_count + list of image id and capture time sorted by capture time
• [Request metadata for image ID ] metadata
• [Request metadata for all images] Datastructure with metadata sorted by capture time
• [copy image file at ID] Succeed/fail/busy
• [copy most recent image] Succeed/fail/busy
• [copy highest ranked image in list] Succeed/fail/busy (optional)
• [Set default camera parameters] Succeed/fail/busy
• [Get camera parameters] camera parameters
• [Format] Succeed/fail/busy

Summary

Overall progress in the payload subsystem for the last 6 months has been very poor due to lack of manpower. As additional team members have been recruited this situation should improve considerably for the forthcoming period. Furthermore the microntroller chosen in the previous design review has been abandoned in favor of an ARM-based architecture running the Linux operating system due to considerable drawbacks identified with the use of the microcontroller that was previously chosen.