1,212
edits
Changes
→Step 1: Reach a consensus on the Mission Statement
Remember this: Your payload governs the rest of the subsystems and your mission statement, or your objective, governs your payload. Hence, it is logical to think of your overall objectives first. The following guidelines should come in handy:
* The objective should take into account the current status of the project. If you are making the satellite for the first time, the objective should not be highly ambitious, because making a satellite is ambitious enough. If you have already launched one satellite, the objective should be influenced by the success of the previous satellite. One cannot aim for the moon, if the first satellite has terribly failed.
* The objective should reflect the capabilities and limitations of the team and also the constraints on the team. "To give IITB its first space exploration satellite (like Voyager)" would be a bad idea for our satellite mission if we haven't moved outside Low Earth Orbit in any of our past missions. Similarly, an objective of giving IITB its first geostationary satellite would be a bad objective if ISRO the space agency launching your satellite doesn't launch student satellites in orbits other than LEO.
Some examples:
# "Develop a maneuverable satellite to demonstrate the robustness of the ADCS subsystem" - A challenging and ambitious objective.
# "Make the cheapest satellite in the world" - Again, a challenging objective. Here, the decisions of the team will be very different from the rest of the objectives stated above. Payloads which require expensive instruments like X-ray detectors would simply be shot down brutally.
# "Make the cheapest satellite bus in the world" - Now, your objective can still accommodate an instrument like X-ray detector, because the objective doesn't affect the payload. But you'd like to keep the payload simple because a complex payload would do no good to the objective. <br />
Stick to a single objective throughout. It is very easy to fall for temptations and select multiple objectives for your project. Becoming too ambitious generally doesn't prove to be beneficial to the team in the long run.
== Step 2: Generate and eliminate payload ideas ==
At this stage, once every team member is clear about the objective, the hunt for a suitable payload can begin. If you are building a satellite for a specific purpose already, i.e. you already have a payload given to you, you can skip this step. This step is primarily for student teams who what to start a student satellite project in their institute, who don't have a payload given to them for their satellite. <br />
Every team member can be asked to come up with ideas for a suitable payload. Team members can even approach professors for ideas. Sometimes, professors would have a real need of satellite data for their research. Just to give a heads up, one can look into the following non-exhaustive buckets for payload search:
* [[Generating Payload Idea/#Domains to explore for suitable ideas/Ideas#Technology demonstrationDemonstration|Technology Demonstration]]* [[Generating Payload Ideas#Space Qualification|Space Qualification]]* [[Generating Payload Ideas#Remote Sensing|Remote sensing ]] * [[Generating Payload Ideas#Communication|Communication]]* [[Generating Payload Ideas#Exploration|Exploration]]* [[Generating Payload Ideas#Disaster Management|Disaster management]]* [[Generating Payload Ideas#Atmospheric Studies|Atmospheric studies]]
More on payload selection is given in [[Payload Subsystem]].
* Tips for the next team
* Summary
----
If you are done reading this page, you can go back to [[Starting a Student Satellite Project]].
