There was a DARPA project called F6 for validating a similar concept. Spent a few million USD and ended with nothing much to show. Turns out formation flying is hard. Especially with satellites with limited orbital alignment capabilities, as the small uneven effects on the orbit from various sources (other planets, atmospheric drag, etc) eventually add up and you have to be able to correct the orbit from time to time to keep the formation. Apart from that, communications tech reliable enough for the kind of distributed in-orbit computation was still not there last I checked.
I wonder if anything has changed in the meanwhile.
What has changed since then would be scale of alternative launch options as well as progress in satellite/radio tech and a bit smaller or lighter, sure does scale in savings.
Perhaps with those factors it may well prove viable to revisit that. That an antenna's and phased arrays, been much progress even in the last ten years and might be that such visions need another ten years, but certainly seems a sound goal overall.
I completely agree that the goal is a good one. Downlink bandwidth is one of the most restricting bottlenecks limiting what we can achieve with satellites. It's absolutely worthwhile to revisit this idea from time to time. Someone should make a website 'are we async in orbit yet'.
I heard this secondhand from a colleague who somehow ended up with one of the F6 cubesats sitting on an endtable in his office, but my understanding was that formation flying wasn't really what killed F6. Over the planned mission duration the satellites wouldn't have drifted apart too much, and even without thrusters there's tricks you can use to tweak orbital periods to keep them lined up. Even that is a moot point, since for F6 they didn't need to be lined up, a cluster was acceptable.
The main problem came from the 4th F in F6, fractionated. The goal was to create a heterogenous network of satellites, built by a whole litany of manufacturers without even a common bus. That ended up being a solution in search of a problem. It made integration way more complex, which was exacerbated by the number of independent participants. The project spent a lot of time working on shared SDKs that would work across the constellation. In practice, there weren't really enough benefits over homogeneous constellations to make all the extra effort worthwhile. Instead of having 5 satellites with cameras beam their images to another satellite that determines which images are cloudy, it's easier to just have each satellite running identical code so it can figure out for itself which images are cloudy. On top of that, a homogenous network has advantages wrt survivability, manufacturing costs, maintenance, etc
I agree, this was the real reason why the project failed. Moreover, it was not clear at all that fractionation would bring any lifecycle costs savings, neither that any of the alleged extra flexibility (and maneuverability, resiliency, maintenability, and other -ilities) would result in any added value for the missions.
Fractionation is very hard,it introduces a lot of complexity in the design and interfaces, and it requires lots of coordination between multiple vendors. Project Ara by Google (a modular cellphone similar to Phoneblocks) also vouched for this idea of fractionation (and in fact was also led by Paul Ermenko) and was also cancelled.
Re: Communications tech, the 2nd generation of SpaceX's Starlink satellites are supposed to be able to communicate with each other via laser interlinks [1]. A friend of a friend works on the tech there and described the accuracy required for the lasers as being like shining a laser from LA to New York and hitting a specific window pane on the Empire State Building.
CubeSats are like the Raspberry Pis of engineering departments- fun to play with, but by the time you overcome their limitations (power, antenna size, heat) you've basically proved that small things can do small things.
However, if you got a cluster of them working together as a phased array - then you not only overcome the limitations, but surpass alternative offerings. But is the tech ready for that, maybe not and who knows - inter Cubesat communication may end up being a case of using lasers for that short few meter formation cluster. Certainly some interesting challenges and yet such things are within reach.
You can’t maintain a cluster of things in orbit without actively expending propellent. At best you can have either a long line of cube sats in the exact same orbit, or so many of them in different orbits that you can always communicate between orbits.
> You can't maintain a cluster of things in orbit without actively expending propellent.
Well, or physically connecting them with tethers. (Bonus: you no longer need wireless communications between them. Malus: pretty much everything else about this design.)
One can run astonishingly accurate near-SotA ML models on even the rad hardened space rated systems with scant resources. For example after 8-bit quantization, pruning, and compression a wake-word NN can take just 14KB. An RPi tier SBC can do quite a bit of inferencing!
Sure. I saw talks by NXP and Renesas at the ARM Dev Summit last week that demonstrated the use of the Glow ML compiler [0] and CMSIS-NN Library [1] to squeeze a Wake Word NN [2] from 20KB to 14KB (with much greater reduction possible on larger ML models). Both Tensorflow Lite and Pytorch is supported in this toolchain.
I look forward to the day we have orbital embedded ML. Comms take 3-6 magnitudes more energy than the rest of an embedded system so less comms use leads to a positive feedback loop of more energy and compute available for sensor reads, inferencing, and analysis.
I don't know enough physics to comment on the effect of different media on EM emissions but from what I understand any potential effects would not be significant enough to negate an order of magnitude difference due to the the nature of broadcasting or even beam-forming a stream of data v.s. sending it down a physical channel that is in comparison a point to point use of resources to manipulate bits (ALU ops, SRAM r/w, Flash r/w).
Might be able to find the paper I'm referencing. Will post tomorrow.
Downlink is the biggest bottleneck at the moment. Your satellite camera or SDR can produce thousand times more data than the amount you can download. You'd definitely benefit from in-space processing.
Downlink will pretty much always be the biggest constraint. You'll always want more data down than you can affordably downlink. And sensors will always produce more data.
There is a number of applications in development that will rely on in-space processing. Such as forest fire prediction, business intelligence from space (estimate the crop yields, oil reservoir levels, city planning and so on). Most of them use ML algorithms to extract valuable insights.
Is bandwidth from outer space so expensive that you save money by moving compute to the edge and only pushing down results to earth instead of the entire data set?
The bandwidth is not expensive. There is simply a lack of it.
Most LEO satellites have 10-20 minutes a day communications window assuming single ground station. Amount of data you can download from a single pass is a tens or hundreds megabytes per day. One high-resolution camera image can be easily over 10MB.
There is plenty of bandwidth to achieve more than 1 Gbps of throughput from a 3-U cubesat (see Planet with their latest X-band comms-system [1], which results in more than 50 GB per pass). If you really need more than that, new free space optical communications systems under-development will bring multi-Gbps to small-sats [2]. For me, the real problem with nanosats is that they generate barely no power and they are really volume-constrained compared to the bigger birds (so you cannot have high-resolution sensors, and cannot fit in there a good optical-comms system, you need to be mindful of your power consumption all time during the mission...).
Finally, note that nowadays Planet downloads 10 TB/day, and they could go up to 40 TB/day once they upgrade their fleet with the latest X-band antenna, which is comparable to the 80 TB/day that DigitalGlobe generates.
I remain skeptical as to the broad applicability of this approach. Some amount of preprocessing on on the space segment is valuable for certain mission types, but I don't know how generalizable it is.
By doing all your processing on the space segment you have eliminated the possibility for analysts to take the level zero / level one products and reprocess them manually, either for quality assurance purposes or to develop enhanced or entirely new capabilities with the data.
The other main problem I have with satellite-as-a-service type approaches is that it requires building generic spacecraft hardware by necessity, which means that you'll never be optimized for a particular mission type. When you build a mission from scratch, you get to carefully specify sensor parameters to achieve your remote sensing objective. Not so much when you're trying to build a generic bird that does everything. For most applications that benefit from generic data, what's the advantage over, say, downloading data from Copernicus (which already has pole to pole coverage at moderate resolution and revisit) or tasking a DigitalGlobe satellite to do the work?
I can think of some edge cases where realtime calls might be valuable (eg: dynamic re-tasking based on realtime image analysis, especially if you have a wide-view forward squinted sensor and a higher resolution nadir sensor), but I really don't see the broad applicability.
It's true that communications is definitely a bottleneck in high resolution wide-coverage missions, but there are other intermediate approaches that work before going all the way to doing the entirety of the processing including decisionmaking on the space segment. We have a lot of room to grow in the comms space, such as moving EO missions to Ka-band (and above) and free-space laser for missions without stringent data latency requirements. Sure, it's a crowded world if you're doing X-band from an isoflux antenna, but there's other architectural options to improve throughout. We can also look at doing selective preprocessing on the space segment (ie: up to Level 1 products) which may allow for better data compression.
I'm not saying there isn't room for space segment processing and dynamic tasking - I saw a really interesting mission proposal a while back that used it extensively. But I don't see the business case for it on generic satellites in all but particularly niche cases.
Well, that deserves a reply beyond the HN comment format. ESA hosted an event, called Phi Week, presenting many possible application cases in Earth Observation domain: https://livestream.com/esa/phiweek2020
If you don’t want to filter through 20 hours of videos, drop me an email to contact@exodusorbitals.com, I can send you a written summary. And some documents on our platform capabilities.
How much competition is there at that price point?
To me being able to outlay such a small amount to get some space stuff done creates a situation like early PCs. They look like weak computers but you when you get some capability into so many more hands people start figuring out unexpected uses for it.
The problem with intelligent early discard is the potential cost of missing something cleverly disguised, that might be seen by an analyst, but not by an AI program. Equivalently, were AI to advance to the point of dispensing with the analyst layer, it would probably run on physically large machines. Perhaps we should concentrate on very high bandwidth transmission to the ground.
49 comments
[ 0.20 ms ] story [ 97.5 ms ] threadI wonder if anything has changed in the meanwhile.
What has changed since then would be scale of alternative launch options as well as progress in satellite/radio tech and a bit smaller or lighter, sure does scale in savings.
Perhaps with those factors it may well prove viable to revisit that. That an antenna's and phased arrays, been much progress even in the last ten years and might be that such visions need another ten years, but certainly seems a sound goal overall.
The main problem came from the 4th F in F6, fractionated. The goal was to create a heterogenous network of satellites, built by a whole litany of manufacturers without even a common bus. That ended up being a solution in search of a problem. It made integration way more complex, which was exacerbated by the number of independent participants. The project spent a lot of time working on shared SDKs that would work across the constellation. In practice, there weren't really enough benefits over homogeneous constellations to make all the extra effort worthwhile. Instead of having 5 satellites with cameras beam their images to another satellite that determines which images are cloudy, it's easier to just have each satellite running identical code so it can figure out for itself which images are cloudy. On top of that, a homogenous network has advantages wrt survivability, manufacturing costs, maintenance, etc
Fractionation is very hard,it introduces a lot of complexity in the design and interfaces, and it requires lots of coordination between multiple vendors. Project Ara by Google (a modular cellphone similar to Phoneblocks) also vouched for this idea of fractionation (and in fact was also led by Paul Ermenko) and was also cancelled.
[1] https://wccftech.com/spacex-starlink-satellite-laser-test/
Well, or physically connecting them with tethers. (Bonus: you no longer need wireless communications between them. Malus: pretty much everything else about this design.)
[0] https://github.com/pytorch/glow
[1] https://arm-software.github.io/CMSIS_5/NN/html/index.html
[2] https://github.com/tensorflow/tensorflow/tree/master/tensorf...
Might be able to find the paper I'm referencing. Will post tomorrow.
https://people.csail.mit.edu/jrk/jrkthesis.pdf (Page 21)
Feel free to ask questions
Most LEO satellites have 10-20 minutes a day communications window assuming single ground station. Amount of data you can download from a single pass is a tens or hundreds megabytes per day. One high-resolution camera image can be easily over 10MB.
Would this issue be any way relieved with things like AWS ground station?
If you can only see a ground station from a satellite for 20 minutes, could you just add more ground stations?
Or is that 20 minutes window constrained by something other than having a ground station within receiving range?
In practice, this will depend more on my negotiation skills when talking to Elon Musk and less on any technical challenge :)
Starlink operates in portions of the Ku and Ka bands that are reserved for Earth-to-space comms, not for space-to-space comms.
The system costs a fraction of what Starlink will cost, as you only need 3 GEO satellites.
Finally, note that nowadays Planet downloads 10 TB/day, and they could go up to 40 TB/day once they upgrade their fleet with the latest X-band antenna, which is comparable to the 80 TB/day that DigitalGlobe generates.
[1] https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=4... [2] https://www.tesat.de/images/tesat/products/TOSIRIS_Data-Shee...
By doing all your processing on the space segment you have eliminated the possibility for analysts to take the level zero / level one products and reprocess them manually, either for quality assurance purposes or to develop enhanced or entirely new capabilities with the data.
The other main problem I have with satellite-as-a-service type approaches is that it requires building generic spacecraft hardware by necessity, which means that you'll never be optimized for a particular mission type. When you build a mission from scratch, you get to carefully specify sensor parameters to achieve your remote sensing objective. Not so much when you're trying to build a generic bird that does everything. For most applications that benefit from generic data, what's the advantage over, say, downloading data from Copernicus (which already has pole to pole coverage at moderate resolution and revisit) or tasking a DigitalGlobe satellite to do the work?
I can think of some edge cases where realtime calls might be valuable (eg: dynamic re-tasking based on realtime image analysis, especially if you have a wide-view forward squinted sensor and a higher resolution nadir sensor), but I really don't see the broad applicability.
It's true that communications is definitely a bottleneck in high resolution wide-coverage missions, but there are other intermediate approaches that work before going all the way to doing the entirety of the processing including decisionmaking on the space segment. We have a lot of room to grow in the comms space, such as moving EO missions to Ka-band (and above) and free-space laser for missions without stringent data latency requirements. Sure, it's a crowded world if you're doing X-band from an isoflux antenna, but there's other architectural options to improve throughout. We can also look at doing selective preprocessing on the space segment (ie: up to Level 1 products) which may allow for better data compression.
I'm not saying there isn't room for space segment processing and dynamic tasking - I saw a really interesting mission proposal a while back that used it extensively. But I don't see the business case for it on generic satellites in all but particularly niche cases.
If you don’t want to filter through 20 hours of videos, drop me an email to contact@exodusorbitals.com, I can send you a written summary. And some documents on our platform capabilities.
To me being able to outlay such a small amount to get some space stuff done creates a situation like early PCs. They look like weak computers but you when you get some capability into so many more hands people start figuring out unexpected uses for it.
Our vision is exactly like you described, giving millions of people first-class level of access to software development platform in space.