SEDSAT-2 Payload Design Notes 20070429
From SEDSWiki
Contents |
Video
This idea has NOT been recommended by the Payload team as a payload for SEDSAT-2. Reason: Video is not a payload itself, it is just a matter of how the imaging payload is operated. Whether ordinary data will be, or if a mode of operation can be included that will produce data suitable for video or time-lapse animation will depend on factors such as available bandwidth, operating regime, etc.
Mike's note
As I see it, this could be accomplished in a number of ways. It has been pointed out that the cmos chip that would be used for taking images can also take video. It can also take infra-red. It has also been sugested that the satellite can be used as a telecom relay. Furthermore, it has been mentioned that flash drives have reached an enormous storage capacity using chips that could be small and light enough for us to include in the satellite.
My proposal would be to use one of these chips to store video and images taken during deployment (or at any other time, such as when attitude is being adjusted).
These videos could be accessed in a number of ways.
1) Direct download to ground station. -impractical
2) Download via telecom relay. -practicallity unknow, but probably more practical then direct download. Continuous downloading a possibility.
3) Alternate between taking visible and infra-red images. Record the average intensity of each image (both visible and infra-red). The launch vehicle should be bright in infra-red, if not in visible, and a program could be writen to find the images with the greatest average intensities in infra-red, and therefore the corresponding visible images that would contain the launcher/p-pod/other cubesats. It might be that the earth would be bright in IR as well, and the the average intensity of the earth image would be the same or greater than the intensity of the lancher image. the sun, if imaged, would be even brighter. The three objects could be distinguished by the number of images taken of each. The IR emission of the earth would be diffuse, where that of the launcher would be localized, so that the average intensity of images of the earth would vary gradually, where that of the launcher would be much more timewise restricted. The sun would be easy to identify because of the sheer intensity of it's emission.
3) If switching between IR and visible is not fesable, we could include a seperate IR sensor (if it met volume, weight and power limits) to provide the IR intensities we would need.
4) If a seperate IR sensor is not fesable, and if the PAL imager can take video (and both imagers are included in the satellite), use the "normal" imager to get the IR, and therefore the corresponding PAL images with the launcher.
5) We could include an extra standard imager (cmos?) in the place of the pal imager, to meet volume, weight restrictions.
I believe it would be very interesting if we were to begin taking video as soon as the satellite is deployed, as blured images, in the context of a video of deployment, could greatly inhance the interest value of the video. also, video taken from the instant of deployment could provide valuable information on the dynamical characteristics of the satellite immediatly post-launch, of value to further missions.
Per's note
When speaking of video, I feel that there has been some confusion as to the definition. Video (latin for: "I see") is a series of images creating a flow of motion. It doesn't matter at what interval the images are taken, at what resolution the images are captured, or in which stage the images has been assembled into video - as long as the motion and result is clear to the end-user. «Video» is not a separate payload – it is just one application for the images taken with our camera, which most likely will be our primary payload. Below I will try to explain our different options for obtaining video imaging.
Time-lapse
The concept of this idea is to take regular «hi-res» images with a fixed delay between, download them, and then put them together into an animation where you will see the clear orbit «fly-by» motion. Taking the CubeSat «XI-V» as an example, with it's «Field-of-View» being about 35° x 35° and an orbital height of 686 km providing images covering around 400 km x 400 km of ground, you would need atleast (40.000 km / 400 km) 100 images to cover one full orbit (not including overlapse). Depending on if we are able to keep the cube pointing stable towards nadir (towards Earth), this option could work perfectly – and it's really just a way of applying a new use for the images we already are going to capture. But for it to come out nicely, we would of course have to take the images at fixed times, so they would overlap each other correctly.
Continuous shot
This option is quite different. Here the idea is to capture «many» images at a «high» framerate. The resolution would be significantly lower, but getting «real-time» images from the satellite could give us a feel of how stable the satellite is, together with being a possible addition to attitude determination («Continuous Shot» was used for ADS on XI-V). A realistic «Continuous Shot» would be something like 120*100 pixels 8 bit monochrome grayscale at 4 fps. If we do a shot with 16 frames it would sum up to a data total of 192 kB RAW – and take us 160 seconds to download on a 9600 baud's RF link (purely hypothetical). This is without compression, and all of the parametres (resolution, color or non-color, depth and framerate) will be adjustable even in-flight depending our needs.
Conclusion
Remember; all of this is ruled by software. If we decide on having a camera in our payload, then video is a possible addition. Its not a separate payload, but something we can implement to an existing one. In my opinion, both of the concepts represented should be used. The time-lapse concept is pretty much something we are doing anyway, its just a matter of what we do take pictures of. I also think we should include the «continuos shooting» option, since it's pretty much haven't been done by other CubeSats – and because the results of it could prove interesting. The reason for the small resolutions when it comes to video, and images in general, is because of our massive communications bottleneck – where we, to be realistic, assume a downlink at 9600 baud.
ACS
This idea has been forwarded by the Payload team to the ADCS team. Reason: Not a payload.
This is an ACS concept I came up with while writing the design note for the video concept. It might not even be considered a payload, but part of the acs subsystem, but I will put it here anyway, as it is sufficiently "unsual" (this might also mean that it won't work). The idea would be to mount solar pannels on an extendable boom so that they would form the equivalent of the tail of an airplane.
This would only work if there is sufficient atmospheric drag to produce a meaningful torque. If not, the boom could be used as a gravity gradient boom, and the angle of the pannels controled for maximum insolation. The same device (mini electric motor?) that would control this angle, could also allow this boom to act as a momentum wheel, thereby decreasing the average insolation of the solar pannels by half, but contributing to attitude control.
If there were enough drag to produce a suitable torque, but radiation pressure were a significant concern, the "stabilizer flaps" could be made transparent, so as only to produce drag forces. The other option would be to instead make these flaps reflective so that they maintain the satellite pointing at the sun, allowing a minimum of one solar pannel to generate the satellite's energy. The benefit of this system would be that appart from deployment, which could in principle be made automatic, the system would be entirelly passive.
