Planning the mission and finalizing the Payload

From Satellite Wiki
Jump to: navigation, search

This step becomes quite crucial in deciding the fate of the project. After all, for the next 2-3 years, you will be working on a system whose characteristics will be determined by this step. Firstly, let's clear the confusion between mission and payload:

  • Mission: Your mission statement answers the question "Why are you doing this project at all?" It determines the overall objectives of the team and influences every action that the team takes. Our social goal is a part of our mission statement and that's how whether to make this wiki or not was hardly debated.
  • Payload: The payload answers the question "What will your satellite do in orbit?" The payload, to a great extent, helps generate the requirements on the other subsystems and helps decide the technical specifications of your satellite.

With this distinction clear, we can now now look at the general guidelines to be followed when finalizing the mission statement and the payload.

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 the space agency launching your satellite doesn't launch student satellites in orbits other than LEO.

Some examples:

  1. "Develop a maneuverable satellite to demonstrate the robustness of the ADCS subsystem" - A challenging and ambitious objective.
  2. "Learn how to build a satellite" - A typical objective for amateurs
  3. "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.
  4. "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.

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.
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:

More on payload selection is given in Payload Subsystem.

Once a number of ideas have been listed, they can be evaluated and shot down based on certain pre-defined criteria. Some criteria can be:

  • Conformance to mission statement
  • Availability of resources
  • Complexity
  • Budget required etc.

More on this is given in Feasibility Analysis of Payloads.

Step 3: Take advice/inputs/suggestions and act on them

At this stage, after the preliminary or detailed feasibility analysis, inputs from faculty members, alumni, research organizations like TIFR, ISRO scientists etc. should be taken. Their experience and expertise often give us perspectives we have completely missed out. Even if a payload looks very promising, it is generally a good idea to take opinions from experts before freezing it. At this stage, it is very essential that emotions don't hinder the payload selection process. It is very much possible that a payload looks very promising but it is eliminated thanks to a factor brought to light by a faculty member. The team should be able to reject that payload, even if a lot of time was spent on that payload.

Step 4: Document the rejected Payloads

Once the payload is decided, CELEBRATE. But don't forget to do your service to the next team by documenting the rejected payloads. The factors due to which you rejected some payloads might be irrelevant to the next team's mission and the work done by you on that payload before rejecting it can be helpful to the next team. You can follow the template given below to document your rejected payloads, or create your own.

  • Basic Concept of the Payload
  • Need/Application of the Payload
  • Points favoring the payload
  • Analysis done before rejection
  • Reasons for Rejection
  • Lessons Learnt
  • Tips for the next team
  • Summary

If you are done reading this page, you can go back to Starting a Student Satellite Project.