SEDSAT-2 Payload Design Notes 20070416
From SEDSWiki
SEDSAT2: Payload Study
Contents |
Self-imaging the satellite in Space
This idea has NOT been recommended by the Payload team. Reason: Interesting idea, but not very useful. Quite demanding, as well as a potential hazard to other systems.
This is a short report considering the options around using either the on-board main camera module (together with a mirror on the gravity boom), or a second camera module to capture images of our satellite in space. Note: When I describe a gravity boom here, it’s purely hypothetical and only to make these options possible.
Alternative #1: Using the on-board main camera module for self-imaging
The concept: Mounting a mirror on the gravity boom would allow for self-imaging using the main camera module placed inside the satellite structure. I did the math on this, using the “XI-V” CubeSat mission as an example – with it’s FOV (“Field-of-View”) to be circa 35° x 35° 1, and the mirror would have to be placed at least 3,57 cm out on the boom. This is purely theoretical, but it shows that it’s possible.
The pro’s: We would be able to perform self-imaging using only one camera module.
The con’s: This option might not be possible due to optical zoom and focus difference required for earth remote sensing and imaging the satellite. It would also block the original camera view, so we would have to either release the mirror in some way after doing the self-imaging – this would intentionally create debris together with the possibility of hurting our satellite – or rotate/move it, but this would complicate things mechanically. This option could also remove our option of deployment imaging.
Alternative #2: Having a second camera module mounted on the gravity boom
The concept: Mounting a second camera module directed at the satellite on the gravity boom allowing self-imaging. The distance between the camera and the satellite would now have to be beyond 7,14 cm – still assuming the FOV of the camera to be 35° x 35°. The cables to the camera would be fastened to the gravity boom. We could use the same circuits as the main camera for the data processing, so the only addition in components would be another camera, mounting and cables.
The pro’s: We would be able to perform self-imaging without any zoom or focus conflict. Digital power switches would control it so only one camera is active at a time, so it would not be a power issue.
The con’s: The extra camera would add additionally to our mass.
Conclusion
Looking at both options I would say alternative #2 is the better if we are to implement self-imaging of the satellite – even though it would add the most to our total mass. The concept itself is feasible, but will of course make our system more complex together with requiring a gravity boom. The only real problem I see with this module is the deployment. Another issue to consider is that of bandwidth. Though we would not require these images to be of any “high” resolution, this is already a bottleneck. I understand the fact that these images could look very well in PR, and be an inspiration to ourselves.
Sources:
1: http://directory.eoportal.org/pres_CubeSatLaunch2.html - The information on XI-V, the site says it was provided by Nobutada Sako of ISSL, University of Tokyo.
Using the CubeSat as a Telecom Relay
This idea has been forwarded by the Payload team to the Comms team. Reason: Sounds interesting, but would be a comms thing.
The idea
The basic idea here is to have our ground-station communicating with a peer trough our satellite (or a peer to peer - it's all relative). The data exchanged could of course be of any kind (with the only limitation being bandwidth); text, images, voice etc – but the only feasible kind is text, as if you were wanting to make a phone call over a 9600 baud line; it would have to be streamed in 1/8th x real-time to get audible quality. Even then, the idea of a telecom relay is pretty cool – considering if you were able to access the internet from anywhere, as long as both the ground-station and yourselves are in the satellite field of view.
Latency
So how would your internet experience unfold over a satellite link? I’m guessing not as cool as shown on “24”. Still using the XI-V CubeSat mission as an example, with its orbital height of 686 km – your basic latency for a “ping” packet sent and response would be:
Tlatency = 4 * ((686 * 10^3 [m]) / (3 * 10^8 [m / s])) + 50 * 10^(-3) [s] + 2 * 5 * 10^(-3) [s]
This would add up to a 9 ms delay for the electromagnetic waves to travel from you (the end-user), to the satellite, to the ground-station and then back again. In addition, we have the delay between the ground-station and an internet server – which I put to be 50 ms. I also put up 10 ms in processing time combined. Roughly, this is 80 ms, but it shows that the time delay should not be the problem in theory.
Bandwidth
When it comes to text, it’s pretty easy to figure out what bandwidth will get you. If you are using ASCII, a character equals a byte (8 bit) – ergo you would get 1200 characters per second with a 9600 baud bandwidth (not taking any control data in mind). A normal web page (not including images/flash components etc) is somewhere around 30 kB. A normal web page would then take 25 seconds to download. Sound would be possible, but if you were to sample it at 8 kHz PCM mono (which is about the lowest audible) – a 10 second clip would take you around a minute to download at 9600 baud. Other audio codec’s could of course be looked into, but it should give you an idea.
The practical application
I am currently working on a link budget and looking at different end-user antennas to see if the idea is feasible. It’s of course the user to satellite link that might prove the problem, since most regular people don’t have access to a 3 meter antenna dish with auto-tracking capabilities – but I guess it would be harder getting a reputation as “normal” than ordering a new satellite dish.
Conclusion
The mission is feasible. It’s almost not an issue at all implementing it, because it’s all about the software. Basically it’s what we are doing all the way, the question is just how much bandwidth we wish to use relaying peoples messages. I think we should look more into this, since it could make our satellite more “open” for people to use.
Using a PAL-lens for imaging and ADS
This idea has been recommended by the Payload team as a possible primary or secondary payload for SEDSAT-2. Reason: PAL photos could be interesting compared to ordinary photos because of their 360 degree view. Could be used for attitude determination at some extra processing cost. Pro: Novel images. Con: Requires moving parts.
The “Panoramic Annular Lens” (“PAL”) lens was invented by Pal Greguss in 1984. It allows for a full 360-degree view of the optical axis surrounding it using just a single camera. The camera captures what seems a distorted “doughnut” image trough the PAL-lens, but then “un-wraps” it using computer algorithms – resulting in a full 360 degrees image ready to be analysed. This solution is now frequently used for robotic vision. An image showing the PAL concept 3
One of the things separating an image captured with a normal lens and one captured using a PAL lens is that a “normal” image is taken using a “See-Trough-Window” (“STW”) mapping, where you only get a flat view of the 3D world, like viewing only a part of a sphere – as opposed to an image taken with a PAL lens, which gives you an image mapped with “Centric-Minded-Imaging” (“CMI”) – the view is now the inside of a cylinder. The bonus of using a “CMI” mapping is that your system is in the centre of the coordinate system describing the 3D scene. Opposed to an “STW”-image, you now get depth information – and a real-time 3D view without having to move any mirrors or cameras. 2
Regarding focus; since the PAL uses such a small aperture the depth of focus extends from the surface of the lens out to infinity – so the PAL system will not require any focusing during operation.
There are several applications possible for a “PAL Imaging Device” (“PALID”) in our project, one of them is if we mounted it on a side 90 degrees opposed to the telephoto camera – so that when the telephoto camera is pointing towards earth, the earth will appear centred on the PAL optical equator. Not only is the PALID now in the position for determining earth and sun attitude, but also for determining attitude from multiple points on the earth – together with providing a solution of determining where on the earth’s surface the telephoto camera is directed.
Other applications possible could be using the PALID for capturing boom or antenna deployment, or for looking at the solar arrays positioning. All together, a PALID would be a great addition to ADS, together with providing us panoramic views.
Sources:
1: http://www-cs.engr.ccny.cuny.edu/~zhu/CSCI6716-2006/CVVC_Part2_OmniCameras.ppt - Contains information on different lens solutions.
2: http://www.bmf.hu/conferences/sami2007/32_Vamossy.pdf - Information on PAL theory.
3: http://www.unit-one.dk/nyhedsbrev/pdf/RPU-C3522-C2512(Brch).pdf - Sony PAL imaging device, where the concept image is taken from.
