SEDSAT-2 Payload Design Review 20080406
From SEDSWiki
Contents |
Current state of subsystem
Development of a prototype imaging platform is currently underway having aqquired necessary tools and components for this purpose. Currently the team is working on communicating with and controlling the imaging device via the serial camera control bus(sccb) two-wire interface.
Progress since Design Review I
- Imager development tools aqquired
- Received donation of development tools for Atmel UC3 series microcontrollers from Atmel Norway.
- An abstract has been submitted to the International Astronautical Congress 2008 for consideration.
Timeframe for completion
We are currently planning for a functional prototype (this includes the image analysis algorithms) to be completed by IAC2008.
Design Choices Made
- Foreseeing the potential need for substantial processing power the team has decided to base their design around the Atmel UC3 series of microcontrollers. These offer a very good power/performance ratio consuming only a marginially larger amount of power compared to that of most 8bit microcontrollers (such as the Atmega8) when operating at standard clock speeds.
- Captured Images will be stored in a dedicated Payload Flash Memory device. Flash memory is cheap, small in size and robust and is ideal for this type of application. Substantial storage capacity can be easily implemented and data storage should not be an issue.
- For redundancy Payload has determined that the system shall be as autonomous as possible from the main Command and Data Handling controller. CDH will only need to interact with Payload via simple commands. If post-processing or compression of the capured images is to be implemented it will be carried out by the Payload Processing Unit.
- Payload will receive commands from CDH via the onboard I²C bus. CDH will have direct access to the Payload Flash memory where captured images are stored. Payload will provide CDH with pointers to the location of the images in the Payload Flash memory.
- The Payload subsystem will implement its own thermal control measures.
- We have determined that we will implement the imaging solution using an omnivision camera chip as opposed to the previously chosen Micron MT9D131C12STC. There were several reasons for this choice:
- The Omnivision camera control interface SCCBis well documented. This is especially important as we might not be able to obtain a full datasheet for the imaging device we intend to include in our design (as most manufacturers do not provide this unless you have signed a Non Disclosure Agreement).
- After several attempts at communication, Micron Technologies did not prove forthcoming in providing us with product samples or datasheets.
Preliminary Figures
- Mass: 200g (from mass budget)
- Dimensions: 75cm^3 (5x5x3cm)
- Operating Voltage: 3.3VDC
- Control Interface: Philips I²C
- Data Interface: Serial Peripheral Interface SPI
- Power Consumption: 150mW
Discussion
- The team is looking into implementing an image analysis and ranking system where each captured image is analysed and given a score based on a set of pre-selected conditions. The ranking of each individual image will then be stored in the Payload Processing Unit memory and will direct CDH to the images of most interest to the mission (as based on the scores). This could be implemented in a number of different ways:
- Analysing an uncompressed thumbnail of the captured image
- Analysing a compressed thumbnail of the captured image
- Performing on-the-fly image analsysis and capturing only if conditions are optimal.
- Image compression can be implemented through hardware compression by using a complete imager SoC solution such as the Omnivision OV3642or by performing software compression using the Payload Processing Unit (PPU).
- A standard plastic lens should be sufficient for the purpose of earth imaging. Thermal considerations might be an issue.
