Vệ tinh Swisscube - Chi tiết cấu tạo P1.

[ivfhongngoc]

Tài liệu tìm được sau 2 tuần vật vã. Share mọi người tìm hiểu. Đây là vệ tinh chuẩn đã được phóng lên của Thụy Sỹ. Chuẩn hơn vệ tinh F1 của FPT đang làm và Vệ tinh pico của Viện công nghệ vũ trụ đang làm. Ai có khả năng hãy nghiên cứu thử xem, các linh kiện cùng vi mạch, mainboard có thể pm mình để trao đổi thêm. Hy vọng sẽ có một ngày chúng ta sẽ làm được
Là tài liệu tiếng anh chưa dịch mọi người thông cảm. Ai có thể dịch được thì pm mình nhé.


1 INTRODUCTION
The SwissCube project is multidisciplinary project involving the EPFL (Swiss Federal Institute of
Technology), the University of Neuchâtel and three Engineer schools (Sion, Yverdon and St-Imier).
The SwissCube is based on the CubeSat specifications. CubeSat is a type of picosatellite with the
dimensions of 10x10x10 cm3 and weighting no more than 1 kilogram. But it’s also possible to build
double (20x10x10 cm3 and 2 kg) or triple (30x10x10 cm3 and 3 kg) CubeSat. The CubeSat standard
offers many advantages. Due to its low weight and dimensions, the launch costs are reduced.
Because many others universities around the world built or are building CubeSat, it is possible to
exchange information among ourselves.
CubeSats also offer the possibility to many students to work in a very interesting but complicated
domain, the space. In spite of its unique specifications, this kind of satellite has the same constraints
due to the special environment as other satellites. The SwissCube will essentially need the same
subsystems. The subsystems that we will find on our satellite are the EPS (Electrical Power System),
the COM (Communication with Earth), the beacon, the CDMS (Control and Data Management),
the payload and finally the ADCS (Attitude Control and Determination System).
I realized this semester project during the 8th
semester of my microengineering studies at EPFL. A
semester project gives 12 ECTS credits, which represent a work of 12 hours per week. The goal of
the project is to perform system engineering. The SwissCube System Engineer is the person that
coordinates and verifies the design at the system level. This task ensures that all subsystem or
elements of the SwissCube are compatible with each other and that they function under the
environmental constraints. The student will maintain mass, power and other efficiency budget. The
student will also establish the system level specifications, verification process and participate in the
elaboration of the system level test plan
The report will first present the objectives of the project, the driving requirements and the global
functions. The next part will describe the different options (trade-offs) at system level. Then the
mass budget, the operational modes and the power consumption are described. Just before the
conclusion the system level requirements are presented.
2 REFERENCES
2.1 Normative references
[N1] SwissCube Project Specifications, Noca Muriel
[N2] Vega user’s manual, Perez Edouard

2.2 Informative references
[R1] Space Mission Analysis and Design, 3rd
edition, W.J. Larson, J.R. Wertz
3 ABBREVIATED TERMS
ADCS Attitude Control and Determination System
CDMS Control and Data Management System
COM Communication System
DOD Depth of Discharge
EPS Electrical Power System
HK House keeping data
LDO Low-Dropout Regulator
PCB Printed Circuit Board
PL, P/L Payload
TM/TC Telemetry / Telecommand
DTS Daylight WITH transmission and WITH science
DTnS Daylight WITH transmission but WITHOUT science
DnTS Daylight WITHOUT transmission but WITH science
DnTnS Daylight WITHOUT transmission and WITHOUT science
ETS Eclipse WITH transmission and WITH science
ETnS Eclipse WITH transmission but WITHOUT science
EnTS Eclipse WITHOUT transmission but WITH science
EnTnS Eclipse WITHOUT transmission and WITHOUT science

4 SEMESTER PROJECT OBJECTIVES
The main objectives of this system engineering project were to make sure that all subsystems are
compatible with each other and that the baseline design of the overall system has converged to
satisfy the specifications. To fulfill these objectives, the following tasks were performed.
• Establishment of a Functional Block Diagram of the overall system
• Coordination with all subsystems to define and catalogue interface parameters
• Elaboration and coordination of system level trade-offs
• Establishment of a Mass Equipment List
• Definition of operational modes and power budget
• Definition of the system level requirements
• Establishment of hardware, data flow and cabling block diagram
• Documentation, preparation of end-of-phase review
5 DRIVING REQUIREMENTS
The driving requirements are those that have a particular influence on the design at the system level,
or in other words, those that influence all the subsystem or most of them. First of all, the CubeSat
standard gives a weight and volume limitation. The weight is limited to 1 kilogram, which implies
that the structure has to be as light as possible but also has to respect the launch constraints. It also
means, for example, that the magnetotorquers can not be bigger than a certain size although the
control is not optimal. For every subsystem this factor is constraint.
The volume or size is a second driving requirement. In fact they are only six faces available to have
solar array on. One of the faces has to have a solar free zone for the payload. The CubeSat size
limits also the size of the components that must be put in. For example, the ADCS could require a
lot of space to provide a sufficient attitude control or the PL has a limited focal length for its optic.
The kind of science mission defines driving requirements because depending on the observation that
is to be performed, the size, the placement of the device, the pointing accuracy and stability, the
power consumption, the amount of stored data have many influences on all subsystems. The size
and the placement influences directly the S&C and the ADCS, the power consumption the EPS, the
data amount the CDMS and the COM and the pointing accuracy and stability the ADCS and the
EPS.
The orbit altitude range is a multiple constraint on the system. The altitude defines the eclipse and
duration time, which influences the capacity of reloading the batteries and the duration they are
used. The lowest altitude (400 km) gives the longest eclipse (36 minutes) and the shortest daylight. It
is identified as the worst case for energy production and consumption. The altitude of 1000 km is
the worst case for the ADCS because the magnetic field strength decreases with the altitude. That
means that bigger magnetotorquers or more electrical power is needed to fulfill pointing
requirements.

6 SYSTEM FUNCTIONAL DESCRIPTION
The following diagram (Figure 1) gives a general idea of the functionality of each subsystem and of
the interactions between the subsystems. The power supply is represented in a blue dotted line and
the data flow in dark gray. These two points will be discussed more in detail in the following
sections. The EPS gives the electrical power to all the other subsystem, manages the batteries
reloading and sends a message directly to the RF Beacon. It groups the batteries, the solar arrays, a
control unit and diverse measurements devices (temperature, current, voltage). The COM, which is
the main communication unit with the ground station, is composed of a RF receiver, a RF
transmitter and a controller to communicate with the bus and to start or stop the transmissions. The
CDMS gives the subsystem a reference time and stores all the data that have to be sent to the
ground station between the communication sequences. It is composed of a controller, memories and
a clock. The PL is the science module composed of a controller for the data processing and detector
which depends on the exact wavelength that will be observed. The ADCS determines and controls
the attitude of the satellite. It has different kind of sensors and actuators and a powerful calculator.
The thermal subsystem is a passive system that regulates the temperature over the satellite with
thermal links. And finally the S&C has to maintain the subsystem together and provide the structure
to fix the loads.


7 SYSTEM LEVEL TRADE-OFFS
Each subsystem has its own problematic and solutions to resolve it. But some of the problems do
not only concern the subsystem itself but the overall system. The trade-offs performed at the system
level are summarized below and presented in a general point of view. The trade-offs are detailed in
the corresponding reports.
7.1 Computing architectures
After the phase defining the functionalities of the future satellite, a concurrent design phase was
realized in order to keep our ideas as open as possible and not to focus too early on a special variant
without a sufficient justification
In Figure 2, 4 of the very first imagined subsystem’s configurations are drawn. Two main options are
available for the controller architecture distributed and centralized. Version 1 represents a
distributed architecture. The advantages of this structure are the modularity and independence of
each subsystem. They can be tested independently and assembled at the end. Another advantage is
the possibility to replace one subsystem by a new one in case of failure or improvement. In these 4
versions, the RF Beacon is always represented with the EPS, but it isn’t fixed yet. The consideration
was that the beacon should be always enabled and that it will be easier and less power consuming to
command it from the EPS, which will always be on to feed the other subsystems with electrical
power. Problems could appear if the RF Beacon is commanded by the COM and the message sent
from EPS. It is more robust that one element has interaction only with one subsystem. A
disadvantage of this solution is the multiplication of the board and interfaces
In the second version the EPS, the CDMS and the beacon are grouped together. The CDMS is
supposed to be the “brain” of the satellite and in this way it will be enabled most of the time. Again
the EPS will anyway be on all the time and this trade-off save a controller in regrouping EPS with
CDMS. The other subsystems are kept separate for the same reason than before. One of the
disadvantages of this version is the loss of independence and modularity.
In the next version, the CDMS is now grouped with the ADCS. The reason to group them is the
intense need of calculation power of the ADCS. The idea is to take a powerful and reliable processor
and to use it as the central intelligence of the satellite.
In the last version the CDMS and the ADCS are still together on the same processor. The telecom
functionality was added to EPS and beacon. This option has the advantage of reducing the number
of boards and in that way it reduces the complexity of the connection between the subsystems. One
big disadvantage is the increased risk of failure due to the grouping of several subsystems on the
same board.
In the 4 different versions, the payload is always drawn as an independent component. This option
offers the possibility to change very easily this part and to reorient the scientific goals of an
observation project.



7.2 Structure and configuration
The CubeSat standards offer the possibility to build double or triple CubeSats. A double satellite is
just twice longer than a normal one. Because our scientific mission will occur during an eclipse we
need a lot of power. A double CubeSat offer more than twice the solar array surface. It also has
more weight capacity and space to place additional batteries. The biggest disadvantage of the double
is its launch price, twice the price of a single one. One of our objectives is to try to fulfill the mission
requirements with a single CubeSat.
The primary structure can be built in different ways, from the monobloc structure (one piece) to
“IKEA kit” structure with a large number of pieces. The monobloc structure offers the advantage to
weight less because there are less connecting parts like screws but it has the disadvantage that it is
more difficult to insert the boards in it.
The internal configuration depends mainly on the choice of the PL placement and how to arrange
the boards around it.
7.3 Data bus trade-offs
A lot of different kind of busses exists like RS family, I2C, CAN. They can be sorted in 2 categories,
the differential busses and the not differential. Differential busses, like the CAN, offer the advantage
to be more robust to perturbations but their consumption is bigger.
One trade-off is to choose one robust differential bus for the all the system, on which all the
subsystem are connected. It offers the advantage that all the controller use the same protocol. The
disadvantages are that the bus can be overcharged if all the subsystems communicate at the same
time and that there is a risk to have a failure and to lose the unique bus. An other trade-off is to add
a redundant “survival” bus or dedicated busses for less life-crucial subsystems like the PL.
8 SYSTEM DESCRIPTION
This chapter describes the system operational modes system baseline. The system baseline is a
compilation of the subsystem baseline.
8.1 Operational modes
This section details the principal operational modes in which the satellite will be during his in-orbit
lifetime.
8.1.1 Start
After the satellite will be ejected from the P-POD, it is required to wait 15 minutes before doing
anything. First of all the EPS will start and check the battery voltage. If this voltage is sufficient, it
will start the initialization sequence. If the battery voltage is not sufficient, it will wait TBD minutes
before it tries again to start. If the satellite loses all its electrical power or in case of reset, it will start
again from here.

8.1.2 Initialization mode
When the battery voltage is sufficient, the initialization sequence will start checking each subsystem
after each other. As it is shown in the schema, the battery voltage will checked after every
initialization step. If the voltage is not sufficient, the satellite will wait before it checks another
subsystem. After all the subsystems are controlled, the system will change to Safe mode.
8.1.3 Safe mode
In this mode only the EPS and the beacon are on. EPS switches off all other subsystems if the
battery capacity is under a predetermined threshold. Before switching off it should send a command
to the CDMS to shut down softly the subsystems. The EPS allows the system to go back in nominal
mode when the battery capacity is high enough
8.1.4 Nominal mode
The nominal mode is a general purpose mode. When the system is in this mode, it is possible to
control the attitude, to start a science phases (taking pictures) and to communicate with the ground.
In nominal mode, the satellite can always receive TC’s from the ground. 8 different cases have been
identified in this mode. They will be described in the in the power budget.




8.2 General block diagrams
8.2.1 Electrical BD
The following diagram shows the electrical power distribution in the whole satellite. The grounding
is not represented here. To see it in detail, the EPS report should be consulted. The green dashed
line represents the different boards



8.2.2 Data flow BD
The data flow block diagram represents all the connections for the information transfer between the
different subsystems. Several possibilities had to be discussed to choose the data bus type, the
number of busses and how to connect the subsystems together. Two important criteria to decide
how to group the subsystem on the bus are the importance of loosing the subsystem for the general
functionality and the amount of data generated by each subsystem. The EPS and ADCS will acquire
a lot of information through their sensors but most of them will just serve an internal use. They will
not be sent to CDMS over the bus. Both subsystems will only send a few HK and TM data to
CDMS, who will store them until the next transmission opportunity. The COM subsystem will also
send a couple of HK and TM



Còn nữa...
Discoverychange - HAS

View more random threads:

• Thiết kế căn hộ A2 chung cư khách sạn 110 Cầu Giấy
• Hưởng thụ cuộc sống đỉnh cao tại dự án Cầu Giấy Center Point
• suất ngoại giao dự án ban cơ yếu chính phủ mới
• Mô hình tên lửa tàu vũ trụ bằng giấy!
• Nghiên cứu làm chủ quy trình công nghệ điều khiển vệ tinh nhỏ quan sát Trái Đất
• Những lý do nếu mua nhà nên chọn 110 Cầu Giấy
• Bản vẽ chi tiết mô hình vệ tinh HAS
• Chung cư cầu giấy center point bán ngoại giao căn A3
• Dự án Tàu Vũ Trụ - Vệ tinh HAS ( Đội kỹ thuật xem thế nào )
• Trung tâm Vệ tinh Quốc gia chế tạo thành công Hệ thống mô phỏng và thử nghiệm ADCS cho vệ tinh nhỏ

[kevin_cn08b]

hic hic dài thế này dich bao h cho xong . Mà cái này phóng lên để làm gì hả anh quan sát các các sao và dải ngân hà 1 cách rõ hơn ah

[showhand79]

Bao h họp hả anh chả bao h thông báo cả

Không cái này không phải là kính thiên văn nó là vệ tinh thì không dùng để quan sát các sao và ngân hà, vệ tinh dùng để chụp ảnh Trái Đất, truyền dữ liệu, dự báo thời tiêt, làm hệ thống định vị... Buổi họp sắp tới có lẽ sẽ thao luận về vệ tinh, mọi người học các kiến thức về vệ tinh, cấu tạo, rồi có gì sẽ cùng trao đổi.

[showhand79]

Bao giờ họp cũng có thông báo cụ thể trước mà. Em cứ yên chí đi, chăm chỉ onl vào, chắc chắn sẽ có [IMG]images/smilies/71.gif[/IMG]

Theo kinh nghiệm của em thì em chưa thấy thông báo cuộc họp nào tỉ lệ onl là 6 ngày /7 ngày zz chỉ có mỗi event là thông báo thôi

Fspace là gì đấy hả anh . Nó như kiểu NASA việt nam ah

[canhovinhomes-1]

Fspace là gì đấy hả anh . Nó như kiểu NASA việt nam ah

[bacngoctuan]

Fspace là gì đấy hả anh . Nó như kiểu NASA việt nam ah

[kevin_cn08b]

Fspace là gì đấy hả anh . Nó như kiểu NASA việt nam ah