Projects:2015s1-01 LaunchBox

The development of Cube-Satellites is providing cheaper and easier access to space for purposes of exploration and experimentation. LAUNCHBOX and South Australian universities are undertaking the development of a Cube-Satellite that will be fit for use in the creation of a wireless ad-hoc network in space as part of the QB50 project.

This wiki covers the development of several aspects of a cube satellite. An On-Board Computer (OBC), Electrical Power System (EPS), Sun Centroid Sensor and Earth Horizon Detection Sensor.

Project Information

Background

Project Team

Morgan Smith

Aaron Williams

Jack Mclean

Mark Prodoehl

Supervisors

Commercial

Flavia Tata Nardini

Matthew Tettlow

Academic

Michael Liebelt

Matthew Trinkle

Launchbox

Launchbox was founded in 2014 by a group of scientists, engineers, and entrepreneurs with the primary aim of promoting Science, Technology, Engineering and Mathematics (STEM) careers to high school students. This would be achieved through enquiry based learning about the exploration of space . Launchbox is working in collaboration with South Australian Universities to develop a proprietary CubeSat that is to be used for educational, academic and commercial activities. The company has an educational arm and a commercial arm. The educational arm is focused on engaging with schools through the Mission 1 competition. The commercial arm has interests in the telecommunications industry and will not be discussed further here.

Educationa Arm

The Mission 1 competition will utilise the Mission 1 schools kit , the design and construction of which is detailed in this document. The Mission 1 kit is an educational kit that will be produced to sell to schools. The kit was designed to be simple to use and will enable high school students to learn about the basics of planning a space mission. Students will have access to five simple sensors that will emulate some of the hardware required for CubeSat operations and research experiments, and to explore some of the testing and constraints that are placed on the hardware.

Mission 1

Schools will be encouraged to use skills and knowledge obtained through experimentation conducted using the Mission 1 kit to design a more advanced experiment. Launchbox will judge a variety of school experiments and determine the best experiments to be adapted and integrated into a planned Launchbox CubeSat mission.

Cubesats

The CubeSat concept was first developed by students at California Polytechnic (Cal Poly) in 2001 as a means to reduce the cost of gaining access to space and as a cost effective method for proving new space technologies in space . Structurally, the CubeSat design consists of a metal frame with minimum dimensions of 10 cm in height, 10 cm in breadth, and 10mm in depth (a 1000 cm3 cube). This minimum size is referred to as a 1U (unit) satellite. Satellites can be expanded in a modular fashion by the addition of further units to construct 2U, 3U, 4U, etcetera, sized satellites. A typical CubeSat will consist of multiple subsystems. These include, at minimum a communications system; an electrical power supply (EPS) system; an on-board computer (OBC) with an integrated attitude determination and control system (ADCS); sensors for the ADCS; solar panels and battery for power generation and storage.

The communications subsystem consists of both downlink and uplink capacities. Downlink is used to transmit flight data (data from sensors embedded in all subsystems) and payload data. The uplink allows the ground station to relay mission commands and reprogram the flight systems. The electrical power system is responsible for regulation of input power from the solar panels, the monitoring and recharging system for batteries, step-up/down regulators for power supply, and switches for power supply to subsystems. Mission control and command is handled by the on-board computer system. The on-board computer is the brains of the satellite and controls communications and operations of all other subsystems. The duties of the on-board computer include data collection and storage from payloads including flight data from subsystem sensors, communications between subsystems, power-up/down of subsystems, and deployment of solar arrays. Attitude determination and control is often integrated into the command system for the on-board computer. The attitude determination and control system is responsible for maintaining the satellite in a stable orientation in all three axes (x, y, and z or roll, pitch, and yaw).

The project described below will work within the guidelines established by the CubeSat development team at California Polytechnic and is to be undertaken in collaboration with Launchbox. Launchbox is a small company that was formed in 2014 by Rocket Scientist Flavia Tata Nardini, Aerospace engineer Dr. Matthew Tetlow and entrepreneur Matthew Pearson. Based in Adelaide, the company aims to promote interest in space research amoung school aged children in Australia and provide a boost to the space industry in Austraia. A combined EPS/OBC subsystem and an independent ADCS subsystem including sensors and sensor control will be developed de novo. The project team will also assist in the design implementation of an experimental payload, the Measurement of Atmospheric Species based on Global Positioning Service Pseudo-range (MASP)

Space and the upper atmosphere are especially harsh environments and as such continue to pose significant technical engineering challenges. These include high levels of solar and cosmic radiation, temperature extremes, challenges posed by working in a vacuum, and the large distances from ground stations preventing repair and posing communications challenges. Working within these constraints will be the biggest challenged faced by the development team and proposed solutions will be detailed below.

QB50

The QB50 project is headed by the von Karman Institute, located in Brussels, Belgium. The project endeavors to launch a fleet of 50 Cube-Satellites 380km above the earth's surface, developed by a wide variety of independent groups.

The QB50 mission is significant as it enables the exploration of new areas in space experimentation. Positioned in the lower thermosphere, the satellite configuration will be used to further investigate the properties of the lightly studied section of the atmosphere, as well as facilitate GAMANET [4]. GAMANET is an experiment that aims to establish an advanced communications platform in the form of a large wireless ad-hoc network of multiple ground stations and CubeSats [5].

SUSat Project

The University of Adelaide is working in collaboration with the University of South Australia on a satellite that will be fit for launch in the QB50 project. The South Australian University collaboration Satellite (SUSat) must conform to the functionalities as well as electrical and structural limitations highlighted in the QB50 system requirements [6].

The University of Adelaide has been deemed responsible for the control, power and structure of the SUSat, concurrently; the University of South Australia is labelled responsible for the satellite communication systems. Not only does this present an opportunity for the staff and students to gain experience collaboratively working on a large scale project, but also the exciting prospect of contributing to a product that will be launched in an international operation.

ADCS sensors

The Attitude Determination & Control System (ADCS) is the sub-system responsible for maintaining the satellite’s orientation in 3 dimensional space. Typically the attitude from the space vehicle orbital reference frame is described in terms of roll, pitch and yaw [8]. In order to determine the craft’s current attitude the ADCS utilises a network of sensors. For a CubeSat these sensors typically include magnetometers (to measure the earth’s magnetic field), gyroscopes (to measure the crafts rotational speed with respect to its orbital reference frame) and some form of imaging device [8-10]. For the SUSat project the satellite will utilise two different imaging sensors, an Infrared (IR) camera based nadir sensor and a CMOS camera based sun sensor.

Nadir Sensor

The term nadir is often described as the vector pointing directly towards a body’s centre of orbit. The proposed nadir sensor solution utilises a camera orientated towards the satellite’s nadir. This camera will be angled such that it can image the thermal discontinuity between earth and deep space similar to a system developed by Soto-Romero et al. [11]. The sensor is being designed to satisfy the SUSat’s ADCS need to have an over specified position solution to determine its pitch and roll during the dark side of its orbit or during a solar eclipse.

Hardware There are several options for imagers namely CMOS cameras, Charge-Coupled Devices (CCDs) [12] and infrared cameras [13]. CMOS cameras were deemed unsuitable for the nadir sensor, as the atmospheric fringing in the image scene can have a significant detrimental effect on signal at or below the Very Near Infrared (VNIR) band (0.45-0.9 µm) [14] and the response of CMOS based camera drops off significantly after this band. CCDs were a popular choice in early satellites for ground imagery [13]. However these devices are limited by their response range, typically between the UV and VNIR bands especially in low light conditions for example when the device is in the earth’s shadow [15]. Fortunately advances in the development of micro-bolometer (micro-bolometers are the underlying detector that reacts to received Long Wave Infrared (LWIR) energy, it is discussed in more detail in [13, 16]) based infrared sensors have made it possible to purchase COTS LWIR imagers [13]. These LWIR cameras have excellent sensitivity and are relatively inexpensive.

Infrared cameras are also able to function in no light conditions as the earth is always radiating IR energy, this IR energy is also relatively unhindered by the lower atmosphere. As such LWIR cameras with resolutions of around 320x240 pixels are becoming very popular for earth imagery [11, 13, 16-18].

Image Processing As the main role of the sensor is to detect the discontinuity between the earth’s horizon and deep space, it will need to perform some edge detection and line extraction to determine the attitude of the craft. Edges in an image are essentially points in the image where the intensity values change significantly over a small number of pixels[19], this corresponds to the gradient of the image. There are several operators that can be convolved with the image to calculate these gradients, the most common being: Roberts, Sobel, Prewitt and Frei-Chen (according to Joshi S. et al.)[20]. These operators with the exception of the Roberts operator which is 2x2; are all based on 3x3 grids that can be convolved with an image easily. Images are also often corrupted by noise (this can either be inherent in the hardware or part of the scene being observed) and it’s imperative that an image processing system doesn’t falsely detect any noise as an “edge”. The use of blurring filters can help reduce the noise strength in the image, however these can also obscure weaker edges [21].

Sun Sensor

A sun sensor is a device that provides the direction to the centre of the sun (if visible) from the reference frame of the satellite. In terms of the SUSat and Launchbox projects, the sensor will be required to produce a unit vector directed toward the centre of the sun with an accuracy of ± 2º in azimuth and elevation. The sun sensor is significant as it provides the ADCS with an accurate and reliable input for attitude determination. In a sun-synchronous orbit, like that of SUSat, the sun sensor will be very reliable, as it will always have line of sight with the sun. A challenge is presented when a view of the sun is obstructed. In this case other sensors such as the nadir sensor and gyroscopes will be used to provide enough information for attitude determination. Several sun sensor solutions are presented in literature, each displaying trade-offs between accuracy, complexity, cost and power consumption. In 2005, sun sensor hardware for use on nanosatellites was developed in Sweden. This was a large step at the time as conventional sun sensors were quite large [10]. The paper detailing the project largely focused on the physical structure of the sensor and the properties of the photosensitive film used. While the time and facilities required to manufacture the sensor will not comply with the timeline of the SUSat project, they did manage to achieve exceptional sun detection characteristics within a small sized component. The mass of the sensor module was less than 30 grams, it had a tested accuracy of 1 degree, and its power consumption was around 100mW [10]. With the evolution and miniaturisation of COTS imaging sensors and processors, a simpler and more power efficient design can be expected in the modern day. A paper from 2013 from students and staff at Satyabama University in India describes another analogue implementation of the sun sensor [11]. Analogue sun sensors utilise output levels from photoelectric materials. The current output from a photocell is dependent on the incident angle of sun rays, hence, can be used to determine the angular position of the sun [11]. Their implementation heavily relied on a digital ambient light sensor to collect light data as well as an Arduino development board and environment. Their testing method combined with the use of photocells and ideal diode equations appear to have produced rather course results that were simulated but not experimentally quantised. In terms of size and power consumption the design would be suitable for the QB50 project. However, a greater accuracy is desired. In 2014 a student team from the University of Adelaide as part of the SUSat project, proposed a design for a fine sun sensor in their final year report [12]. This design involves the use of a COTS image sensor with a fish eye lens, and image processing provided by a microcontroller. The design was shown to have a calculated accuracy of ± 2º, current draw of only 10mA, and hardware simplicity in its combination of off-theshelf components [12]. The bulk of the work yet to be covered in this design lies in the development of software package for the microprocessor that enables communications between the image sensor, microprocessor and external devices.

Launchbox Cubesat

EPS

Electrical power supply is the life-blood of any satellite. The design goals of an Electrical Power System for a CubeSat are to maximize available power while minimizing power consumption and weight. The EPS consists of solar panels to collect and convert solar radiation into electrical power, a battery for storage, load regulators to control power supply to subsystems and a central controller to manage these tasks. The system design must provide solutions for the interconnection of all of these systems while maximizing power production. The EPS on board the Launchbox CubeSat will be responsible for providing power to the On Board Computer, the Attitude Determination and Control, subsystem including sensors, the Telemetry Communications Subsystem (TCS), the commercial arm transponder, and up to four experimental payloads.

Solar Panels

Supply of electrical power is a fundamental requirement for successful CubeSat missions. CubeSats utilize panels comprised of several photovoltaic cells to convert solar radiation into electrical energy. Because of the size and weight constraints of CubeSats, solar photovoltaic cells are the only real viable option for power generation [8]. These solar panels are mounted on the sides of the CubeSat. The surface area of the CubeSat determines the area available for solar panels and hence determines the total amount of electrical power that can be generated [9]. There are several solar cell technologies available, the most viable of which is the triple junction type. The key advantages of the triple junction type are its high efficiency and high terminal voltage (typically 2V) [8, 10]. The high efficiency means that the limited surface area available for solar generation can be maximized compared to less efficient cell technologies. The higher terminal voltage means that less cells need to be used to form panels with usage voltage levels [10].

The configuration of a CubeSat allows only three faces of the satellite to be in sunlight at any one time and the orbital inclination (angle of orbit from the equator) of a CubeSat may often cause the CubeSat to experience extended periods of darkness (~50 minutes for a 100 min orbit at 400 km altitude [9]). These are external factors limiting production of electrical power.

A recent paper describes the total potential power supply that could be generated from CubeSats of varying sizes ranging from 1U up to 12U [11]. The Launchbox CubeSat is a 12U satellite and will most likely be of a 2U x 3U x 2U configuration. The Launchbox CubeSat would allow for the use of four 20 mm x 30 mm solar panel arrays on its sides. This means that the Launchbox CubeSat’s panels could potentially generate up to 73.6W [11]. This potential generated power is based on a CubeSat utilizing Spectrolab 28.3% efficient cells of the triple junction type. The ends of the Launchbox CubeSat will not be covered with solar panels are they are required for the communication and sensor systems.

A CubeSat’s solar panels are a key consideration in EPS development with how to best extract the limited power from the panels most efficiently of primary focus [8]. When designing an EPS, attention must also be paid to the beginning and end of life characteristics of solar cells, as solar cells will loose efficiency over their lifetime [8, 12]. This ensures the EPS can deliver enough power to the CubeSat to throughout its operational lifetime.

Maximum Power Point Tracking

As the supply of electrical power essential for the operation of a CubeSat and the amount of power generated is limited by the CubeSat surface area it is therefore imperative, that solar panels of the EPS system are flexible to allow for peak power generation at all times when the satellite is in sunlight [5, [9]. The characteristic of the power output from cells making up the panels of a CubeSat is of a non-linear nature and is affected by the level of irradiance, cell temperature and loading [13, 14].

To maximize the power produced from the solar panels of a CubeSat, a technique called Maximum Power Point Tracking (MPPT) can be used. The MPPT technique is advantageous for satellites in LEO as the Maximum Power Point (MPP) of a panel changes significantly during the orbit [11, 13]. These significant changes in the MPP during orbit are due to the large changes in solar illumination and temperature of cells when the satellite comes in and out of sunlight. MPPT causes solar panels to operate at their maximum power point MPP and thus allows the maximum possible power to be produced from them [8, 11, 14, 15]. MPPT achieves this by tracking the MPP of solar panels and utilizing a DC-DC converter [14]. Maximum power is transferred when the operated panel voltage is equal to the voltage at the MPP. The DC-DC converter provides an interface between the panels and load and by varying the duty cycle input to the DC-DC converter the panel voltage can be altered to operate at the MPP [14].

To keep the solar panel operating at its MPP, the MPP must be tracked and the voltage corrected to ensure continual operation at the MPP. This tracking can be done with either the EPS on-board microcontroller running MPPT algorithms or using specialized discrete MPPT IC’s such as the LT3652 from Linear Technologies [9] [16].

The algorithm that is primarily used by microcontrollers to track MPP is the Perturb and Observe method [13]. In this method the microcontroller measures current and voltage output by the panel, it then multiplies the current and voltage together obtaining power. The microcontroller then changes the voltage of the panel slightly by varying the duty cycle input to the DC-DC converter and recalculates the power again. Depending on whether the power has increased or decreased since the last measurement the controller can determine the change voltage required to reach the panel’s MPP [8, 11, 13, 17]. For example if the power decreased since the last measurement the controller will know the MPP is in the opposite direction.

Particular attention needs to be paid to the sampling rate of the Perturb and Observe method. In LEO the method will fail to track the MPP, becoming confused as the MPP can change rapidly, due to the varying temperatures and irradiances found in LEO [8]. MPPT can be implemented using analog circuits but is only usually used for redundancy and was not further researched [8, 18].

When MPPT techniques are not implemented solar panels have to be carefully matched to the expected load. This has problems in terms of efficiency as the panel is connected to the battery via charging circuitry; this forces the panel to operate at the batteries voltage [8, 10, 13, 14]. Hence, with this connection method power produced is dependent on the battery voltage. Operating the panel at the batteries voltage can also cause the panel to not operate at its MPP resulting in potentially power generated being wasted. A poorly designed direct battery connection can also cause battery failure due to the lack of proper charging procedures [8]. Another advantage of using MPPT techniques over direct battery connection is that MPPT gives the option of having high efficiency when using different configurations of solar panels on the same satellite, as the output voltage is not pulled to battery voltage [10].

Load Regulators

Load regulators allow the EPS to provide different voltages from a single power source (the battery). Experience from previous missions and publications suggest that the use of synchronous buck (voltage step down) and synchronous boost (voltage step up) converters provide a flexible and efficient means of power regulation [11, 19] (Clyde space EPS).

An alternative solution is to use a single-ended primary-inductor converter (SEPIC) [7, 20]. A SEPIC converter allows for both step-up and step-down voltage conversion [15]. Both options have been used in commercial-off-the-shelf EPS boards with the former offered by Clyde space [18] and the latter offered by pumpkin [21].

Batteries

The solar panels of a CubeSat cannot generate electrical power during the dark portion of the orbit; therefore an energy storage device is needed to allow the CubeSat to continue to operate. CubeSats utilize batteries to fulfill this energy storage need allowing them to operate throughout the entire orbit. Utilizing batteries also allows the EPS to handle the peak power demands of a CubeSat when the input of energy from solar panels may not be sufficient to power all systems [8, 12, 22, 23]. The sizing of a CubeSats battery is dependent on the mission and is calculated using a power budget; the power budget calculates the average and peak powers consumed by the CubeSat [8].

Batteries are the most sensitive component of an EPS, they are quite susceptible to the temperature and vacuum effects of LEO, failing if not properly managed. Battery heaters are therefore often implemented in EPS designs to ensure the battery is operated within temperature limits[12, 24].

The battery chemistries most often implemented in CubeSat applications are the lithium ion and lithium polymer types. This is due to their ability to be recharged, reliability, compact size, low weight, high power density and low self-discharge [8, 9, 15, 23]. The low weight is an important factor as batteries account for a large portion weight in a CubeSat [11, 15]. Using lithium polymer batteries is quite new in CubeSat applications. They offer several advantages of the lithium ion type. They have better energy densities, are less flammable and have more compact form factors allowing for easier placement. However as they still new, data on their space suitability is often unavailable having to be tested before integration into a CubeSat [18, 24].

Microcontroller

To manage the operations of an EPS and ensure that all subsystems interface with one another, a microcontroller is used. The primary requirement placed on the microcontroller is the ability to perform Digital Signal Processing (DSP) in order perform the calculations required for monitoring charge and health of batteries using equivalent circuit battery models [11]. Several microcontrollers have been used in the literature ranging from the Texas Instruments TMS320F28335 [11, 25] to the Reneses RL78/G13 [9].

The microcontroller is also tasked with monitoring the health of the EPS system via communication with embedded sensors on the EPS board, the solar panels, and battery. Such parameters monitored are generally temperature, voltage, and current. The microcontroller communicates with the satellite’s OBC making measured EPS parameters available and allowing the OBC to turn on and off systems supplied by the EPS [7, 9, 11, 15, 25].

Protection Circuitry

Increased radiation levels at CubeSat orbital altitudes produce undesirable effects on any data stored memory circuits [26]. This radiation causes an increased probability of upsets within the memory where bits flip, changing overall values. This problem can cause latch ups and failure of computer system operations thereby creating situations where subsystems may draw excessive amounts of current [13]. It is therefore a key requirement of an EPS to provide protection to itself, the supplied subsystems and batteries from these events. If batteries are overcharged or discharged they can become damaged loosing valuable capacity or even fail completely. Therefore the EPS must protect batteries not only from over discharge but also over charge. The need for a battery protection is a requirement derived from the Cal Poly CubeSat specifications [27].

The EPS can provide protection using several methods. These methods are the use of current limiting circuitry, disconnecting of loads and fuses [12, 13]. It should be noted that some batteries may come with protection circuitry built in allowing battery protection circuitry to be omitted form the EPS board [12, 24].

OBC

The on-board computer of any satellite fulfils the vital role of command and control and as such, is required to communicate with all subsystems (Figure 1). This can be broken down into several tasks:

1. Command and Data Handling (CDH)
2. The collection, processing, storage, and transmission (via low frequency radio) to the ground station of health and monitoring data of all subsystems and peripherals (temperature, voltage, and current)
3. Retrieval, processing and distribution of commands received from the ground station by the telemetry communications system
4. The collection, processing, and storage of data from payloads (educational and commercial)
5. The issuing of power up and down commands to all peripheral subsystems
6. Timing reference and correlation
7. Satellite autonomous control and monitoring (for example safe mode, execution of time tagged commands etcetera)

Several companies supply “space-ready” commercial off-the-shelf (COTS) on-board computer system boards including Gom Space , ISIS , and Pumpkin however these can be quite expensive (upwards of $US10,000). As such many smaller development teams design their OBC de novo . This involves the selection of a microprocessor, selection of the types and number of communication buses, selection of the size and type of memory and whether or not to include redundancies.

Microcontroller

The core of the on-board computer is the microcontroller. In many ways, the limitations of the microcontroller become the limitations of the entire CubeSat and as such, great care must be taken in its selection. One development team began the selection process by conducting a review of the literature and a survey of available microcontrollers, focusing on those that had been used successfully in previous missions . A similar approach will be undertaken by this project team. Factors to consider in the selection of the microprocessor include processing power (clock speed, MIPS (million instructions per second)), power consumption, temperature tolerance, radiation tolerance, and the type and number of interfacing ports available. Given the driving principle behind the CubeSat standard is to reduce the costs involved in space exploration, one of the main considerations in selection of a microprocessor is cost. Another consideration is whether or not to design for redundancy. Redundancy can be built into the system at four levels :

1. At the system level, multiple redundant satellites can be built and launched. This is the most expensive and inefficient level of redundancy.
2. At the subsystem level, multiple interconnected on-board computer boards can be included on the satellite structure.
3. At the component level, the on-board computer board could be designed to house multiple redundant microprocessors.
4. At the software level, watchdog time outs and error detecting code can be implemented to catch any program data variable errors. These are generally single bit inversions and when they occur in a program variable are termed single event upsets (SEU). The software level incurs the least cost but is also the least effect.

As the last two levels of redundancy are the most cost effective these are the levels at which smaller development teams’ tend to focus . These will also be the levels at which the project team will focus.

Interfacing

There are several options for subsystem interconnectivity using various well established bus interfaces . These include

• Control Area Network (CAN)
• Inter-Integrated Circuit (I2C)
• R-S232 serial bus
• Universal Synchronous Asynchronous Receiver Transmitter (UART)
• Serial Peripheral Interface (SPI)

Typically, CubeSat on-board computer designs incorporate a range of these interfaces to improve adaptability of the system to a larger variety of peripheral devices . The Launchbox requirements call for UART, SPI, and I2C interfacing capabilities .

Memory: Primary

There are three common uses of memory in most CubeSat designs 1. Payload Data storage 2. Code Data storage 3. Temporary storage for telemetry and health data. Payload data storage tends to be the largest of these and will often incorporate external extendable memory in the form of flash-based secure digital (SD) cards. Code data storage is most often built-in to the microcontroller itself. Temporary data storage is external to the microcontroller and is used to temporarily store health data from peripheral subsystems while the satellite is out of communications range with the ground station. External memory is most often implemented using one of two (or both) technologies; Flash and/or EEPROM. Due to the nature of data storage it is particularly susceptible to solar and cosmic radiation. As such, it is prudent to consider methods to maintain data integrity. 1.3.2.3.1. Error Detection and Correction The increased radiation levels at CubeSat orbital altitudes produce undesirable effects on any data stored on board a CubeSats memory circuits. The radiation causes an increased probability of upsets within the memory where bits flip, changing overall values. As this problem can cause failure of OBC operations, error detection and correction (EDAC) techniques have been developed as an effective solution to radiation induced upsets within memory . Error detection and correction implementations aim to allow error free storage in memory and data transfer between the central processing unit and memory circuits of a CubeSat on board computer. Frequently used error detection and correction implementations include triple memory redundancy (TMR), Reed Solomon codes, and Hamming codes. EDAC techniques require the contents of memory to be regularly read to detect and correct errors, avoiding a summation of errors that become unrecoverable . Triple memory redundancy is a hardware based approach to error detection and correction whereby three identical memory modules hold identical data, and the correct data is determined by taking the majority value from the three memory modules. Hamming and Reed Solomon are software based EDAC implementations whereby errors and detected and corrected by placing additional check bits into memory. The check bits are organised in particular ways such that errors can be detected when decoding by comparing them with re-calculated check bits .

ADCS

Many Commercial off the Shelf (COTS) ADCS systems are available for CubeSats, however these are typically very expensive and have somewhat fixed requirements for input sensors. As such, it is in Launchbox’s best interests to develop a proprietary custom ADCS to suit their needs, specifically utilising only active (power consuming) actuators. However, it has been noted that these systems can be quite complex especially when utilising active actuators [10, 22].

In built Sensors

A CubeSat ADCS typically utilises a sufficient network of sensors such that the solution to determining attitude is always over-specified, this results in redundant sensors [8, 23] and increases the reliability of the system. The sensors described in section 1.2.2.2.1 will be utilised in the Launchbox CubeSat along with a GPS receiver, 2 sun sensors and a nadir sensor.

Actuators

There are two classes of actuators for CubeSats; Active components are “actively” controlled by the ADCS, where-as passive components do not require continuous control [8]. Some examples of passive actuators include permanent magnets and gravity booms [24]. The Launchbox CubeSat will only utilise active control methods as these are far more accurate [8], As such, these methods will be a focus in our studies. For satellites within the CubeSat size range, literature has suggested that due to size, weight and power consumption limits, the only two viable active actuators are Magnetorquers and reaction wheels [8, 10, 25]. A magnetorquer is essentially a coil of current carrying wire which optionally features a ferrite core [25], by varying the current flow the magnetorquer generates a magnetic field that interacts with the earth’s magnetic field, thus producing a torque upon the satellite [10]. The other common actuator is a reaction wheel, the reaction wheel consists of a small DC electric motor spinning a relatively large mass. The acceleration/deceleration of this wheel creates rotational torque about the satellites axis [26]. Magnetorquers are generally preferred due to their lower weight and power consumption [8]. However, during certain phases of deployment, (discussed in the next section,) the effect of the magnetorquers is too weak for time critical missions. As such reaction wheels are often required as well [25].

Autonomous System

The current generation of satellites developed for SUSat and Launchbox missions rely on the ADCS being integrated with the OBC. This is somewhat undesirable as it consumes a significant portion of the OBC’s memory and processing ability. As such Launchbox wish to move to a completely separated autonomous ADC Sub-system. This new approach will require the integration of a microcontroller into the ADCS Printed Circuit Board (PCB) that meets the yet to be determined system requirements. During the satellite’s orbital lifespan, it will go through various phases of orbit. The first phase immediately after deployment is called the de-tumbling phase. During this phase, the CubeSat will be out of control rotating around all axis at speeds of more than 10°/s [27] typically around the range of 50°/s to 90°/s [7]. Once the satellite’s ADCS has reduced these rotational speeds to a value generally less than 0.3°/s the ADCS moves into the fine-pointing phase, this is the typical operational phase. Literature suggest that the ADCS algorithms are based on a state measure and prediction architecture [9, 10, 23, 25, 27]. There are several varieties of these types of algorithm, Extended Kalman Filters [23] (EKF) rely on the use of Bayesian statistics to estimate the attitude of the craft, and compare this to the recorded attitude. This produces an error which is fed back into the system of equations in an iterative approach. The solution converges to a final value for the attitude. This is particularly useful after de-tumbling as it requires no initial information regarding the attitude [23]. Other methods of resolving several attitude vectors include the Triad method as described in [10] and the State-Dependant Riccati Equation (SDRE) discussed in [25].

Aims and Objectives

Mission 1 Kit

The aim of the Mission 1 kit sub-project is to develop a small kit that simulates the feel of working with a Cubesat. The kit should be easy to use, portable and robust. As described above, the Mission 1 kit will give high school students the experience of designing experiments to be conducted in space with all of the physical and environmental constraints that go along with it.

SUSat

ADCS sensors

Sun Sensor

The sun sensor aspect of the project will be comprised of two main objectives. A hardware functionality test, and an image processing software design. The Hardware test will involve ensuring that the sun sensor can be powered and is programmable. Connection to the on-board camera must be verified along with the ability to communicate with external devices using an I2C communication protocol. Secondly, a software implementation of a sun sensor algorithm must be implemented. The software will be required to: take an image from the on-board camera; use image processing techniques to determine the suns position; and pass the suns position to an external board through an I2C connection. Should tests fail, or the interfacing of the hardware become too difficult, an investigation into alternative hardware may be necessary. This will include investigation into various image sensors, buffers and processors. This process will come at a cost of both time and money. While money is less of a concern, the additional time associated with performing a trade-off analysis, purchasing, waiting for delivery, and integration of the new sun sensor hardware will place pressure on the project deadlines.

Launchbox

Proprietary OBC

A proprietary Launchbox on-board computer using selected commercial off the shelf parts is to be designed, built and tested in this project. The role of this OBC is to act as the ‘brain’ of the Launchbox CubeSat, interfacing with all other subsystems and facilitating the communication between them, as well as storing and processing the data from these subsystems. It will need to be designed such that it provides a cost effective way of integrating and interfacing school designed space experiment payloads on board the Launchbox CubeSat, without affecting overall satellite operations. Building a proprietary OBC will be of significant benefit to Launchbox as it will enable the company to have complete design control over the system which will lead to simplification of future improvements to the system.

Proposed Approach

Mission 1 Kit

The Mission 1 kit is intended to be sold to schools, enabling school children to experiment with 5 simple sensors that emulate hardware required for CubeSat operations and research experiments. The sensors will include a reed switch to ‘measure’ the presence of magnetic fields, a tilt sensor (to measure orientation), a force sensitive resistor to measure force (emulating G-forces), a vibration sensor (to emulate vibrational forces experienced during launch), and a reflectivity sensor which can be used to measure reflectivity’s of surfaces and as a crude proximity sensor.

Hardware Prototype Development

A prototype kit that resembles a 0.5 U CubeSat (100mm x 100mm x 50mm) will be developed. The kit will be comprised of two tiers of Perspex plastic separated by spacers and will be designed in such a way as to enable it to be portable. The lower level will house a Raspberry Pi A+, a 9V battery, and a power regulation and supply board. The upper level will house a breadboard to interface the sensors with the Raspberry Pi (through its GPIO pins) and an LCD display to provide feedback and sensor readings to the students.

Software Prototype

The software design for the Mission-1 schools kit must:

1. Auto boot the Linux operating system
2. Automatically run a script to launch the student interfacing software
3. Take in readings from the peripheral sensors and process them into a format that can be output
4. Output informative messages to the LCD display showing the readouts of the 5 sensors.

Hardware Integration and Testing

Once the software development has been completed, testing of the integrated system will be performed. Tests will analyse

• The lifetime of the 9 V power source in running the raspberry pi™
• The sensitivity of the 5 sensors
• Correctness of the readings displayed on the LCD display.

Once all tests have been passed successfully, a series of five instructional videos will be created by a collaborator in Queensland detailing the connection and use of the five sensors. Finally, the kit will be handed over to Launchbox for acceptance.

SUSat

ADCS Sensors

Sun Sensor

A sensible design for the sun sensor has been decided upon and a flight board prototype has been manufactured. The chosen sun sensor consists of a CMOS sensor with a fish-eye lens. A microprocessor is used to handle the data captured by the sensor and determine the direction of the sun through image processing [12]. The digital nature of the design provides a very small, simple implementation with low power characteristics, abiding by the main limitations presented in the CubeSat space application.

Hardware Functionality Test

Hardware Functionality Test There are four identified main functionalities that must be verified before the hardware prototype is sent for thermal and vibration testing. The sun sensor must be able to be powered by a 3.3V supply, be programmable through JTAG connection, able to communicate with external devices using the I2C protocol, and able to read an image from the on-board camera.

The image below displays the proposed experimental setup for testing the four functionalities. An mbed prototyping kit will be used to act as a master board, which will power and request data from the sun sensor hardware through an I2C communication link. The use of other development boards such as the Arduino Uno, and Maple development board from leaf labs was also explored. Due to its 5V output voltage, the Arduino Uno would require some form of regulator circuit in order to meet the 3.3V demand of the sensor. The development environment provided by Leaf Labs for the Maple development board was not well supported for Windows 8. As such investigation into the setup of a Linux based operating system would be required if this option was pursued. As the mbed development board has a 3.3V output, it can be used to verify the sun sensor 3.3V power criterion. The mbed online development tools have well abstracted I2C libraries, simplifying the communication test method. The sensor flight board is equipped with a JTAG connection for programming. The CooCox integrated development environment will be used in conjunction with the STMicroelectronics proprietary link utility to verify the programmable nature of the sensor hardware once it is powered.

Reasons for the use of CooCox are listed below. A program will then be implemented using this IDE to verify the sensors ability to pull an image from the on -board camera.

Software Implementation of Sun Sensor Algorithm

Software Implementation of Sun Sensor Algorithm The sun sensor software will be based on an algorithm designed by a previous student in a former year of the project life. From both a user and processor perspective, the algorithm is purposefully simple. Firstly the image is grey-scaled, and the relative intensity values in each row and column are summed. These sums are used to draw a virtual 'box' around the brightest area in the picture. The position of the box centre is then used to calculate the directional vector pointing toward the sun. Figure 2 provides a visual representation of this process. Working operation of the algorithm has been verified in a Java implementation using still images on a PC. The future challenge in this task lies in the embedded nature of the software and communication with both the CMOS sensor and the on-board-computer. There will also have to be an inquiry into whether calibration is required for the use of the fish eye lens.

The software will be developed using the CooCox integrated development environment. This program was initially chosen because it was free, contained the libraries required to embed programs on the sensors STM microprocessor, and had sufficient support for Windows 8. Upon using the development environment, it is clear that the software has a very user friendly interface, a simple, effective debugging tool and some additional useful libraries for I2C communications. The only outstanding critique for the program, lies in poor formatting of some of the 'help' documentation. This is likely due to CooCox encouraging open source contribution. Caution must be exercised when using the open source material as it can introduce algorithm and redefinition errors that may be difficult to trace.

Launchbox

Proprietary OBC

Needs identification and Requirements Document

Through discussion with the client (Launchbox), a set of requirements for the Launchbox OBC has been obtained. This set of requirements has been recorded in a Requirements document . The requirements for the OBC will be derived from the system requirement document of the Launchbox mission. These requirements are flexible and may be changed over the course of the project when new information is available on peripheral subsystems or with the changing needs of the client

Research

During the research phase, the literature (including product brochures and technical data sheets) has been and will continue to be surveyed to discover what solutions have worked in the past and to identify where there are knowledge gaps. One knowledge gap that has already been uncovered is the integration of the EPS into the OBC board. Literature surveys have not as yet uncovered any development team that has attempted to do this. Research will be conducted into the functional requirements that other CubeSat missions have encountered in relation to the operations of the OBC. Research will also be conducted into the physical and functional parameters offered by current Commercial Off-The-Shelf (COTS) OBC systems. These parameters will be compared and contrasted with performance parameters offered by currently available COTS microcontrollers and other components.

Trade-off Analysis

A performance trade-off analysis will be conducted in which the mission requirements, environmental requirements, physical requirements, functional requirements and component costs will be weighed against each other. This allows trade-offs that provide the best possible performance in all areas, thereby identifying the most appropriate components to be selected for the project. This is a critical step in the system engineering process.

Generate Feasibility Report

Following the trade-off analysis a feasibility report will be generated and recommendations will be made to the industry supervisors for discussion.

Generate Map of System Using Core

The CORE software package will be used to determine how best to integrate all of the functional requirements of the OBC and the EPS onto one board. The CORE package will keep track of all the requirements of all the subsystems and the interfaces among them. This tool will facilitate the requirement definition phase, the trade-off and components selection phase as well as the prototype definition.

Use Altium to design prototype of PCB for the OBC

Once component selection and system integration analysis has been performed, the ALTIUM CAD software package will be used to place and route system components onto a PCB layout to generate a prototype PCB design. Preliminary electrical tests can also be performed using this software package.

Fabricate Prototype PCB of OBC and Populate

The School of Electrical and Electronic Engineering’s PCB milling machine and reflow oven will be used to fabricate and populate a prototype PCB.

Prototype Testing

Depending on the progress of the project, software design will begin to enable preliminary testing of the prototype OBC.

Results

Sun Sensor

External Communications Development

The test setup validated the correct operation of the polled external communication ability of the sun sensor. The outputs on the PC terminal, the binary pattern on the LEDs, and the oscilloscope monitoring the transmission lines, verified that the sun sensor was successfully transferring valid data.

External I2C Communications Test Setup

The above image shows the operating test setup used to verify the correct operation of the polled I2C implementation. The mbed development board in the bottom left hand corner is displaying the values provided by the sun sensor board in the centre. The oscilloscope is monitoring the I2C clock (yellow) and data (blue) lines between the devices.

Further Developments

The polled implementation of the I2C was a basic concept. The sun sensor calculates the sun centroid, and holds the value until the master requests it, or a timeout occurs. However, the delay between the calculation and the request causes data to be dated and inaccurate. A solution to this problem lies in the use of the STM32F103 I2C interrupt capabilities. In this way the sun sensor constantly calculates and updates the centroid calculation until the master requests the data. At this point an interrupt stops the calculation process and transmits the most recent sun location information. A small test program has been coded that uses interrupts to port single bytes in the same way as the polled implementation. Code examples of slave transmission and reception using I2C interrupts were scarce. As such, an implementation was built from careful observation of a large section in the processor documentation. The documentation specifies certain processes that are required in order to clear interrupt flags and continue transmission, if this is not carefully handled, it is possible for a slave device to lock up the I2C bus through clock stretching. A state machine has been designed to provide a more secure mechanism for handling the interrupts and transfer processes.

I2C Interrupt Handler State Machine

The image above shows the states of I2C interrupt handler. Changes between states are dependent on the I2C interrupt flags that are set by hardware. For example, from the idle state, if the flag that indicates the slave being addressed is set high, then the state machine will reset required flags and proceed through to the start state. The state machine manages the master’s requests to send or receive any number of bytes. If an error is detected, the state machine clears all flags and returns to the idle state ensuring that the slave device does not lock up the bus.

Internal Communications Development

The test setup from the external I2C communications test was revised. The image sensor transfers image data to the buffer, the processor receives image data line by line, and sends the lines to the mbed development board through the external I2C link. The mbed device stores the image data in a text file as it is received. After the transmission is complete, a program coded in Java interprets the image data, converts it to a PNG format and saves the image.

Figure 18 - Images Taken in RGB (left) and YUV (right) Formats after Timing Issues Were Resolved Images taken after the timing issues were resolved produced expected output. Figure 18 shows two images of a flashlight in the lab in both RGB and only intensity values from the YUV image format. Note that the red pixels in the YUV image are overlayed in Java and represent the brightest pixels in the image. This was implemented to determine the suitability of the image for processing purposes. The YUV format was selected for use in the image processing due to its simple pixel information structure.

Sun Centroid Calculation Algorithm

The final of three algorithms developed uses a blob detection method. Firstly, the image data is converted to binary values. Pixel intensities with a brightness above a given threshold are given a value of one, dark pixels are set to zero. This decreases the size of the data so that it can be stored on the processor, allowing two passes across the data set. The algorithm identifies all the blobs in an image and then compares the size of each with the expected size of the sun which is adjustable and has been determined experimentally. If a blob around the size of the sun is detected, the average position of these pixels exclusively will be used to approximate the centre of the sun.

This algorithm has been trialled in MATLAB with some promising results. Figure 27 and Figure 28 compare the new algorithm implemented in MATLAB with the initial image processing algorithm using a photo of the sun, taken by the sun sensor flight model. Again, in Figure 27, the red pixels indicate the pixels that are above the threshold, and the small blue crosshair represents the approximation of the centroid pixel. In Figure 28, the white pixels indicate blobs detected that are above the threshold value, the green pixels indicate the blob that is assumed to be the sun and the red cross shows the new approximation of the centroid.

Figure 27 - Image of the Sun Taken by the Sun Sensor, Overlaid is the Result of the Initial Algorithm

Figure 28 - Same Image of the Sun Processed Using the Revised Algorithm in MATLAB It is clear that the revised algorithm boasts a greater accuracy in the presence of reflections has the ability to distinguish between the sun and other bright elements based on size. However, as a trade-off the revised algorithm requires a two pass process and a reasonable amount of data storage. This introduces error due to processing delays.

Conclusions

Sun Sensor

Project Outcome

The project successfully saw the development of the three software aspects required for the successful integration of the sun sensor into the satellite. Namely: the external communications interface; internal communications; and the centroid calculation algorithm. In Section 3.3 the development of the external communications interface of the sun sensor was described. It now provides a swift transfer of data through the use of interrupt flags and routines. As such, error due to the delay between image reception and the request of the sun location from the master device is minimised. Section 3.2 described the process behind coding, testing and debugging the internal communications on-board the sun sensor. This provided functionalities including: the ability to adjust camera settings; and port image data from the camera to the processor. Section 4 exemplifies several revisions of a sun sensing algorithm which explored the benefits and cons of various methodologies. An accurate method that uses a blob detection algorithm followed by averaging has been selected and demonstrated in MATLAB. Along the way, knowledge and skills were also gained through unexpected complications within the project. Namely: solving the problem of overexposure and the protection of the image sensor using solar safety film; and debugging electronic signals and communication protocols using an oscilloscope and logic analysis tools.

Future Work

Within this revision of the sun sensor hardware, the interrupt based external communications interface must be thoroughly tested to highlight any conditions under which it may fail. This may include: passing more data to the slave than it expects; not passing enough data to the slave and stopping communications at random times. The sun sensor must be able to recover and maintain stable operation throughout such events. The final revision of the sun centroid calculation must be implemented in C and ported across to the sun sensor hardware. Following this, substantial testing must be performed to ensure that the algorithm provides the 2 degrees of accuracy listed in the project aim in the presence of reflections and other bright objects.