SEDSAT-2 Mission Concept Review
From SEDSWiki
Mission Concept Review for the SEDSAT-2 Mission Feasibility Study.
Many thanks to the Mission Concept Review Board -- Jim Burke, Jeff Cain, Ed Chester, J. F. Gauthier, and Gregg Maryniak -- for taking time from their busy work schedules to help the team. As a special note, all of the reviewers are either alumni or faculty of the International Space University. We appreciate your help in not just getting us to space, but in getting there in an operational manner. Thanks, guys.
Contents |
Jim Burke, Jet Propulsion Laboratory
It's a good document for a first start on the problem. My one comment at this stage is that the set of possible missions should be pruned down to only those that can seriously be considered for a cubesat.
One way to do this would be to focus on the demand for data rate and total data magnitude.
Dr. Jeff Cain, COM DEV
The document you sent me is quite interesting and I really like the idea of a student run project that designs, builds and flies a microsat. As requested, I have a few comments.
I wasn't clear as to the objectives of the document or the review. From the title I was expecting a review of the technical and cost feasibility of performing a specific mission. However, it seems to be discussing potential missions instead. I have since assumed that the objective of the document is to review the work performed and attempt to attract support for faculty advisors and other students to the cause.
I assume that the ultimate goal to the project is the experience and knowledge gained by the students. In order for this to happen, I would suggest that the mission goal be chosen early. This would allow the team to choose specific payloads and allow them to focus early in the process. I would hate for them to lose out on some of the detail design/test process due to schedule constraints. I think that this would also help in creating interest with possible contributors to the project.
The build philosophy seems to be consistent with that of a microsat approach. There has been no discussion of reliability or failure recovery and I am curious if any thought had been given to these aspects of the bus. For example, assuming the solar cells will be body mounted, are all three on the same face or will they be placed on different sides to allow recovery from a failure mode?
Attitude control has been identified as an area that has not been (and may not be) addressed. It was suggested that this would be looked at based on the payload requirements. The payload is not the only driving factor for this system. The build philosophy will also drive the approach. Continuing on the power example, if the solar panels are mounted on one face, the ADCS now has more demands than if they are mounted on all six faces as the spacecraft has to have one face always sun-pointing.
It would also be interesting to see a overall cost, power, mass budget for the mission.
It looks like the students should have an interesting experience as part this project.
Dr. Ed Chester, European Space Operations Centre
Here's my comments (warning – I might end up quite harsh-sounding, but only in a supportive way, and only because i've done this kind of thing, as a student, in industry and at agency level, and as a reviewer of phase A stuff). Feel free to pass this along, and I'd also be happy to be a general reviewer for later versions/sessions and/or other documents as and when they're available.
p1 s1 para3 – Introduction
"The MFS is not only remarkable for it contains but what it does not" word missing: "for WHAT it contains"
I think there should be some mention of how the communication works, project management etc. Apparently "These are not skills that can be expressed in text" - not true, and i think describing a bit about how it works will help with the interest and 'novel-factor' (but note that distributed teams collaborating on a spacecraft using the internet is not a new thing). This appears at the end of the report – consider moving it up front.
p1 s2 - Subsystems
Whoa. Here we have subsystems already on page 1. What are the mission objectives? How can we assess the feasibility (this is MFS) of a mission if we don't know what its for? I appreciate its constrained, the mission objectives are primarily the educational value and networking etc. etc., but these can be presented. This then takes some of the pressure off the need for mission objectives of the actual satellite (though it should have some):
- to establish 2-way radio comms with a cubesat
- to develop a cubesat system to survive N hours/days in space
- to deploy optical payload blah...
- to demonstrate effective 3-axis attitude control of a cubesat using blah
- to implement a functional mission design and implementation team using internet technologies to link distributed team members in academic institutions
- to promote space education as a multidisciplinary example encouraging students into technical disciplines etc etc.
I guess I am challenged by starting to read about subsystems for a system that's unknown.
By the same point - a summary of the cubesat systems envelope would be useful for the reader, and to demonstrate that the team later in this document is thinking about subsystems that fit within the budget constraints of the cubesat. I propose section 1.1. Project Management and Team Communications (or similar), 1.2 - Mission Objectives, 1.3 - Summary of Cubesat Requirements. This last then has "The SEDSAT-2 shall be a cubesat based upon the concept found at (reference). The external dimensions shall be XxYxZ mm, the maximum mass 1kg, with a target maximum power consumption requirement of 1W. (add any other requirements in). Then something like "The following MFS considers the design approach and subsystems appropriate to deliver the mission objectives of section 1.2, within the constraints of the cubesat in section 1.3.... then you're in a good place to move into taking about the hardware.
p1 s2 - Subsystems
I have a further problem with the subsystems appearing so soon. How can subsystems be discussed without any mention of the orbit or lifetime of this thing? I accept that the orbit of a cubesat is largely out of the hands of the designer, but there are some obvious choices and expectations. A choice of reference orbit is needed to then place requirements on the power/thermal/payload stuff selected. At a given altitude, what (ground) resolution would such-and-such CCD detector have with given optics? Is this OK? If launched as a deployable from a secondary payload into GTO (reasonable), are we more worried about radiation than if we have some very low near circular orbit? Just two examples - but the orbit determines everything – how much power you need/want, how the communications will have to work, the suitability of payload, the lifetime, the thermal and radiation environments, etc.
p1 s2.1.1 - Optical observation
"In the event of an imaging payload" - is imaging payload an event?
"Compression might need to be looked at" - depends upon your communications solution, and upon the mission objectives. If the mission is expected to deliver 1 image in its lifetime, compression is hardly necessary. If paragraphs are going to be introduced to discuss options for something, they should be tied to the actual project, mission, objectives, or something. As it stands this paragraph neither adds nor detracts anything, except that whoever wrote it can look up the URL about the JPEG standard. For a cubesat - my approach would be to implement the absolute simplest possible thing that can possibly work - and therefore avoid unnecessary hardware (costs you mass, power implementation complexity, and risk) - and probably avoid compression if you can. The comment about image degradation needs to be justified against what the image actually is. If you have a single pixel covering several hundred square kilometers of planet, do you really care about small losses in compression? If yes - that's fine. But say why if the answer then requires additional software/hardware on a mission.
On the upside - there's mention here of a polar orbit? where did this come from? And there's nothing wrong with polar orbits for looking at the sun - they're better than some alternatives i could imagine. Think about the geometry of the thing. Sun: my gut feeling is UV will be extremely hard in a cubesat envelope. Interesting to read about if you can do it. If the orbit is likely to be polar, is there any scope for some magnetic payload? The reference to laser observations from other stars should probably be removed, as it suggests the team has unrealistic expectations of both its payload and its accuracy of attitude determination and control. Getting the thing launched and achieving 2-way communications with it will be an amazing achievement; don't get too far out of scope.
"very small" camera module. how small? is it possible to interface this thing to whatever is flying the cubesat? The incomplete sentence about power consumption is useful, but should (a) be completed (b) be included into a single power budget table (appendix?)
p2 s2.1.2 - Radar detection
Consider the size of radar transmitters and receivers. What wavelengths are you talking about? Without any supporting info, this sounds unreasonable to me.
p2 s2.1.3 - Exposure to sunlight
Interesting. But - this assumes you know your attitude at release (usually tumbling). Therefore - you need batteries. The argument about shielding doesn't work. It also doesn't say what the shielding is for. This places requirements on your attitude control (and to a lesser extent, but still...) determination system. Suntracking is relatively easy. Getting launched into an orbit that allows this continuous light will be hard, but possible if you have the cash. Would be nice to actually have the orbit described (STK model?) to convince the reader that this can be done. It sounds like what you want is a mix between various standard orbit types. For sun-synch, how are you going to get launched to an orbit that precesses slowly enough to give you the 24h sunlight? Strongly recommend as an educational step to put a standard sun-synch low-ish orbit into STK (something like 97deg retrograde incl, 400km altitude, circular -- or look one up) and simulate it for 2 days. Should be able to plot sunangle or something, and then tweak the orbit params until you have something that achieves what you want. I can't quite see it in my head, and I'm a bit worried that if it was possible, somebody would have done it. Maybe they have. I dunno.
I'm not going to comment on the second or third para here, except that it needs thinking about again bearing in mind (a) a model of the orbit (b) conservation of angular momentum (c) it needs a diagram or several (d) if the orbit is assumed at 400km with roughly 90min period, then the plane is rotating constantly with respect to the earth. What does this mean for the angle between the plane of the orbit and the earth-sun vector? (put it into the model).
s2.1.4 - power beaming
it is unlikely you will be able to afford panels with efficiency over about 15%. the cubesat power budget is 1W. how is the beaming achieved? and where to? do you have the freedom to choose orbit, and the precision of attitude control to pull that off? what is the power loss through atmosphere, and how much of your 1W do you really have left? assuming the rest is feasible, would it be detectable? i would suggest removing this section.
p3 s2.1.5
Look up how interferometry works. What you describe is stereo imaging. Interferometry is a non-imaging method. That said, this idea of a split cubesat with physically separated payload elements is interesting, and could be taken further. Would this have applications for magnetic measurements? What about using the deployment as an attitude control mechanism? (akin to a gravity gradient boom)? What does this split 'long beam' configuration mean in terms of attitude control and power generation? If you considered a cubesat stack of 3 (i.e. one of your dimensions is 3x as long as standard cubesat but it can be launched in a standard tube launcher) - can this give you multiple booms/extensions - or a really long boom?
p3 s2.1.6 - pollution
All your survey applications need to consider the ground resolution of the kinds of imaging payloads you can reasonably fit in a cubesat. Without some numbers saying otherwise, I would think that 'survey' type applications are out of scope.
p3 s2.1.7 - WSN
interesting, but would have to be for tech demonstration reasons - there's not much justification for the cost, complexity or power consumption to wirelessly monitor something a few cm away when wires work quite well. tech demonstration of MEMs is important - and a challenge for the MEMs market. Kirk - consider sending them the (whole, or relevant part of) the TP-MiNI report about technology demonstration for a description of the problem and why MEMs aren't used in space so much yet.
p4 s2.2 - power
face it - you have to deal with eclipses like every other mission. also face it - you want to test this thing on the bench, and on top of the launch vehicle before flight. also face it - when you are deployed, you won't know your orbit or your attitude or where the sun is. you will also probably be spinning. You need batteries. Remove sections that suggest otherwise. "Power will be provided by body-mounted and (optionally) extensible solar cells of type X. Li-Ion (or similar) batteries will be used to store power for the launch and early operations phase before sun acquisition, and for periods of eclipse. The internal operations of the satellite will be designed to minimise power consumption during eclipse periods. To maximize robustness, a very simple coarse sun sensor has been designed to support rapid sun acquisition."
p5 s2.3 - structure
"If we use either Al-7075-T73, 6061-T6, these are the costs in America and UK." - there's no mention of costs, and this sentence seems not to make sense. Why not simply "The structure shall be made from Aloomnum ;) . However, various alloys are also under investigation to save mass without significant cost implications. For a simple aluminium housing, the estimated cost and mass is shown in the cost and mass budget tables in the appendices." (i.e. add these things!)
p6 s2.5.1 - antenna
- why is directional gain important to you? does this increase or decrease chances of successful communications? (think) also this section is confused. it starts off with one solution, then ends with the 1/4wave monopole. just choose something, say why, move on.
p7 s2.5.2 - txcvr
what factors drive choice of modulation? what are the implications of each type on the comms system on the satellite, on the ground receiving/transmitting equipment, and and on the overall performance/cost/complexity? do the simplest possible thing that will work. suggest talkign to amsat community about this - what is easiest/smallest to implement. nowhere is there mention of your required overall data rate on uplink or downlink, which would inform this modulation decision somewhat.
p8 s2.6
ground is a subsystem. how will you get and interpret the data? Which standards do you care about implementing, and which do you not? attitude control seems essential for your description of your payloads and your power generation. this section is therefore redundant. Make the report consistent, and be clear about what your requirements actually are. This will be easier if you get a reference orbit established and model it -> this gives you payload, attitude control, and ground subsystem requirements info.
I see there is some expertise already in the team, and i'm confident that this can make a great project. I know this is early, but diagrams for ideas, gantt charts for schedules, and tables for costs, power and mass budgets really help. Do not take the comments too seriously, this is a good start. However, you know you all have limited time for this, and the challenges are not to be underestimated. Focus on doing the simplest things well, and making sure it will work. Cubesats are not blessed with a great history of success - doing something overly complex increases your chances of failing your objectives.
I think you need someone/a team to look at options for attitude control (magnetorquers, reaction wheels, thrusters) because i think whatever you come up with, you'll want to try to be attitude stabilised. Is spin stabilisation an option for a cubesat? Praps not? I'd also suggest avoiding thrusters. Miniature wheels could be cool, or torquers integrated with the panels. Finally, as soon as possible - start a system requirements document, and keep it updated. This is continually undervalued in space projects, and continually causes problems.
Jean-Francois Gauthier, COM DEV
I looked over you Mission Feasibility Study and I think overall it looks like a great start to an ambitious program. I had the following comments on the document as a whole:
- If I understand the purpose of the document properly, it will be used to generate interest and get stakeholder to buy in. My comments are therefore made with this assumption in mind.
- There is a lot of great information on many different types of missions, but through it all there seemed to be a lack of focus. I realize it is very early in the process, but if you could define your mission more specifically this early on, it would be much easier to understand and be excited about what you are trying to achieve. For a CubeSat of the sort, the actual mission takes a back seat to the experience gained by the students. Choosing an interesting, worthwhile and reasonably challenging mission out of a wide variety of options should therefore not be dwelled on.
- Along the same lines, your schedule is quite aggressive so if your mission had guidelines that are firmer earlier, the early part of you effort (until your MDR) could be far better focused and perhaps even allow you to move the MDR to an earlier date. This would in turn provide some relief in the latter part of your schedule by providing some contingency and flexibility for the other milestones.
- If you can, try to emphasize heritage. It is not entirely clear if you are planning an entirely new bus or trying to build on the heritage from SEDSAT-1 or another CubeSat. This kind of information is very relevant when trying to get you Spacecraft on a launcher to piggypack on a primary payload. It can also relieve some pressure on the design effort by allowing you to focus on the payload and be confident the structure or some form of it has flown before.
- The budget information would benefit from providing the details. For example, the machining costs seem low, but it makes sense if it assumes that the machining time is donated by a university and only the materials need to be purchased. Such assumptions should be explained here. It would also be useful to see a consolidated budget plan showing total expected cost at the moment. It doesn't have to be accurate, but it shows they've been thinking about it.
As I said, I think this is a very good start. My comments are not meant to criticize the project or document but rather a summary of what went trough my head when I read it as if I was a stakeholder. With a more focused approach earlier in the process, I believe your group can put itself in a position to be very successful.
Gregg Maryniak, X PRIZE Foundation
Wireless Power Transmission
The suggestion of using the satellite to beam power to the Earth is laudable but not feasible. This is not because Wireless Power Transmission is impractical. Rather it is because the optics (antenna) required at any RF frequency are massive in order to get a usable beam on earth. Think kilometer scale (at 2.45 GHz). Even if you were to put a diode laser on the sat, the amount of power that you will be able to collect with a reasonable solar array will be so small (and your battery storage capacity so limited in the sort of orbit that you are likely to achieve that you probably won’t want to do this experiment on a sat of this size.
If you really really want to experiment with Wireless power transmission, you could beam some energy between a pair of small satellites, or use a spring to separate your satellite into a mother-daughter configuration. I participated in a Japanese-US collaboration which resulted in ISU’s first space experiment being launched in 1993. The mission, called METS (Microwave Energy Transmission in Space) used a mother-daughter system of two spacecraft to beam microwave energy from one transmitter to a pair of rectennas (rectifying antennas). One of these was built in Japan, the other, under ISU auspices, at Texas A&M. These spacecraft were operated in suborbital flight.
So as important as experimenting with Wireless Power Transmission in space is, it is probably not practical with birds of this size.
Power
In section 2.2 Power, you comment that power beaming from the earth would apparently shorten the life of the satellite. Please provide the basis for this contention at your convenience.
Suggestion
In section 2.1.3 you talk about using a small high efficiency thruster to maintain a constant solar exposure. This suggests a mission that would be of interest to the community. Many people have proposed using microsatellites (possibly operated in swarms or arrays for a variety of tasks.) However, such operations would generally require not only attitude control but propulsion for stationkeeping. Demonstrating very small satellite propulsion with long life high efficiency thrusters (and attitude control) would be a real service to the world. If your mission requirement includes returning scientific data, perhaps you might endeavor to measure the effect of your propulsion system on the spacecraft’s immediate environment to help gauge the practicality of using such propulsion systems on future scientific satellite systems.
