KickSat: open source spacecraft project(github.com)
github.com
KickSat: open source spacecraft project
https://github.com/kicksat
50 comments
I was wondering if it really was a good idea to spread so many little things in orbit, and was subsequently very happy to read this in the paper linked by jimsojim:
Due to their extremely low ballistic coefficient,
the Sprites are Expected to remain in orbit for only
a few days before reentering and burning up in the
atmosphere, alleviating debris concerns.Even with this rapid decay, I'd still be concerned about the probability of a collision with something - depends how congested that part of LEO is
This is something that is designed into pretty much all cubesat/nanosat missions, for exactly this concern.
Even the ones deployed from ISS (at around 400km altitude) have decaying orbits. I believe the hard rule is no greater than a 25-year expected life before re-entry.
Even the ones deployed from ISS (at around 400km altitude) have decaying orbits. I believe the hard rule is no greater than a 25-year expected life before re-entry.
It's amazing to think that the long-term plan for something is for it to move slower and slower around the earth and then just burn up in the atmosphere.
Really elegant design pattern that is highly reliable (gravity) as long as these things don't get pushed out into space accidentally (which I'm guessing is highly unlikely and would take a sustained force).
EDIT: but now I'm wondering about all of the space 'trash' I've read about. Why doesn't that stuff descend back into the atmosphere also? Or does it and it just takes a while so things get a bit crowded up there?
Really elegant design pattern that is highly reliable (gravity) as long as these things don't get pushed out into space accidentally (which I'm guessing is highly unlikely and would take a sustained force).
EDIT: but now I'm wondering about all of the space 'trash' I've read about. Why doesn't that stuff descend back into the atmosphere also? Or does it and it just takes a while so things get a bit crowded up there?
Now I barely know much about this, but I recall reading something that the space debris isn't actually that big of a deal. Since most satellites go in one direction (with the exception of israel, which has to launch retrograde orbits for political reasons), the actual speed delta between any 2 objects which are close to each other is fairly small. You really only need a bit of forethought about how to safely "deorbit" your crafts, and some working together to avoid trying to put 2 things in the same spot.
Combine that with the fact that space is still REALLY big (the surface area of any single orbit is still larger than the surface area of the earth), means that it's not as much of a problem as I thought it would be.
I don't mean to downplay it, it's still rocket science after all, but I think the worry of a massive wall of debris which makes it impossible for any craft to get past is closer to science fiction than it is to real life.
Combine that with the fact that space is still REALLY big (the surface area of any single orbit is still larger than the surface area of the earth), means that it's not as much of a problem as I thought it would be.
I don't mean to downplay it, it's still rocket science after all, but I think the worry of a massive wall of debris which makes it impossible for any craft to get past is closer to science fiction than it is to real life.
Interesting.
Just looked up why Israel launches them retrograde (counter to the Earth's rotation which costs more energy to launch). It's so launch debris doesn't land in populated areas, it lands in the unpopulated Mediterranean instead. Make sense.
Also these fully orbit the earth in 90 minutes, so theoretically you could get more time-resolution out of retrograde orbiting satellites (though I'm guessing there are other benefits of going with the Earth's rotation).
Just looked up why Israel launches them retrograde (counter to the Earth's rotation which costs more energy to launch). It's so launch debris doesn't land in populated areas, it lands in the unpopulated Mediterranean instead. Make sense.
Also these fully orbit the earth in 90 minutes, so theoretically you could get more time-resolution out of retrograde orbiting satellites (though I'm guessing there are other benefits of going with the Earth's rotation).
The energy requirement is the massive reason why launches are primarily prograde.
Even the time resolution you mentioned isn't much of and advantage of retrograde because a prograde satellite can get the same period at a lower altitude.
Even the time resolution you mentioned isn't much of and advantage of retrograde because a prograde satellite can get the same period at a lower altitude.
Certain classes of satellite (like remote sensing) use sun synchronous orbits which are slightly retograde. It allows the orbit to precess slightly to keep tracking the sun as the earth rotates on its axis.
Orbital debris do have decaying orbits, but they can take quite a while depending on altitude (with estimates for a existing systems in LEO anywhere from several months to several centuries):
http://www.nasa.gov/news/debris_faq.html
http://www.nasa.gov/news/debris_faq.html
> I was wondering if it really was a good idea to spread so many little things in orbit
Something I've been wondering: why are all small cubesats designed as stand-alone satellites that are detached from a launcher? Why not instead build one big satellite, with shared solar panels and a deorbit engine, and sell "shelf space" for numerous small scientific modules that remain attached to it?
Something I've been wondering: why are all small cubesats designed as stand-alone satellites that are detached from a launcher? Why not instead build one big satellite, with shared solar panels and a deorbit engine, and sell "shelf space" for numerous small scientific modules that remain attached to it?
Most of the small sat stuff isn't for science work. Commercial entities want to reorient on demand, manage their own coms and antenna direction, etc.
What you describe is a good idea, and how most older sats work (just not modularized).
What you describe is a good idea, and how most older sats work (just not modularized).
https://www.astrobotic.com/ is doing it for the moon.
Lots of open-source initiatives going on in the (small) satellite world at the moment. We're hopefully going to be releasing an online platform for preliminary design and trade-off analysis in the next few months. I know of a few other companies that are working on open-sourcing different parts of the technology stack. Predicting New Space to look quite different in another 5 years, with hopefully next to no barriers to entry.
Do you have any examples of open source initiatives you are excited about?
I used to work in small sat. Two open source projects that were exciting to me when in the industry: http://cosmosrb.com/ https://cfs.gsfc.nasa.gov/
I used to work in small sat. Two open source projects that were exciting to me when in the industry: http://cosmosrb.com/ https://cfs.gsfc.nasa.gov/
Great links
I founded an open-source library for orbital mechanics during my PhD, which is still going strong: https://github.com/tudat
We're developing a new set of modular libraries based off of Tudat: https://github.com/openastro. We're also building an open search engine for satellite subsystems: https://satsearch.co.
Some other interesting open-source stuff going on:
- https://librespacefoundation.org
- http://www.kubos.co
- https://github.com/esa/pykep
- https://gmat.gsfc.nasa.gov
I founded an open-source library for orbital mechanics during my PhD, which is still going strong: https://github.com/tudat
We're developing a new set of modular libraries based off of Tudat: https://github.com/openastro. We're also building an open search engine for satellite subsystems: https://satsearch.co.
Some other interesting open-source stuff going on:
- https://librespacefoundation.org
- http://www.kubos.co
- https://github.com/esa/pykep
- https://gmat.gsfc.nasa.gov
On a tangential note, I was happy to see that they're using Solidworks files within git. There are precious few examples of this "in the wild", and after guiding my previous (small, <20-person) company to using git for hardware version control, I always get a bit happy seeing other projects doing the same.
Git gets a bad rap with binary blobs like Solidworks files because merge conflicts are extremely opaque, but that's really not much worse than anything else you've used as a mechanical engineer (at least not in my experience). And, unlike other options -- like the litany of built-in solutions that are "integrated" (if you can call it that) with the CAD program itself -- you get the benefit of branching and sandboxing. Really the only downside (from my perspective) is that you have to be very careful about communicating who is working on what, and being absolutely meticulous about sizing subassemblies in a way that minimizes work conflicts. Beyond that, the biggest hiccup is that Solidworks assembly files are rather... poor abstractions... and that changes to individual files within them will result in changes to the assembly file, even if the assembly itself never changed [1].
Tools like openscad get a lot of love from software engineers, but programmatic definition of geometry like that is just orders of magnitude less productive than, for example, the Solidworks UI. I think the primary reason they get as much appreciation (aside from using a familiar interface to software devs, namely code) is their compatibility with source control and collaborative work, which is in just a profoundly abysmal state with mainstream CAx tools. The CAx world is in dire need of a software-independent, merge-friendly formats.
Note that STL, IGES, STEP, etc don't count; they're package independent, but only transfer the "compiled" final geometry of the part, and not the history ("source code") you used to create it, so they're essentially immutable snapshots. That makes them great for sending a release to manufacturing, but utterly unusable if there's any design left to do.
[1] This is a result of the assembly file also storing a "compiled" version of the final assembly geometry, in addition to the various rules -- Solidworks calls them "mates" -- that define the relationships between the parts. So if you change the geometry in any of the parts, the assembly file changes, even though none of the mates did. Very frustrating.
Git gets a bad rap with binary blobs like Solidworks files because merge conflicts are extremely opaque, but that's really not much worse than anything else you've used as a mechanical engineer (at least not in my experience). And, unlike other options -- like the litany of built-in solutions that are "integrated" (if you can call it that) with the CAD program itself -- you get the benefit of branching and sandboxing. Really the only downside (from my perspective) is that you have to be very careful about communicating who is working on what, and being absolutely meticulous about sizing subassemblies in a way that minimizes work conflicts. Beyond that, the biggest hiccup is that Solidworks assembly files are rather... poor abstractions... and that changes to individual files within them will result in changes to the assembly file, even if the assembly itself never changed [1].
Tools like openscad get a lot of love from software engineers, but programmatic definition of geometry like that is just orders of magnitude less productive than, for example, the Solidworks UI. I think the primary reason they get as much appreciation (aside from using a familiar interface to software devs, namely code) is their compatibility with source control and collaborative work, which is in just a profoundly abysmal state with mainstream CAx tools. The CAx world is in dire need of a software-independent, merge-friendly formats.
Note that STL, IGES, STEP, etc don't count; they're package independent, but only transfer the "compiled" final geometry of the part, and not the history ("source code") you used to create it, so they're essentially immutable snapshots. That makes them great for sending a release to manufacturing, but utterly unusable if there's any design left to do.
[1] This is a result of the assembly file also storing a "compiled" version of the final assembly geometry, in addition to the various rules -- Solidworks calls them "mates" -- that define the relationships between the parts. So if you change the geometry in any of the parts, the assembly file changes, even though none of the mates did. Very frustrating.
Also, check out the paper here:
https://zacinaction.github.io/docs/KickSat_SmallSat.pdf
This is incredible!
So are there are any cool applications?
Maybe I'm having a lack of imagination... but I have no idea what I'd do with one even if I wasn't constrained by size. Even on the ISS they seem to have run out of interesting things to do (last I heard they were growing lettuce in space...). Just wondering if anyone has got any cool ideas
Maybe I'm having a lack of imagination... but I have no idea what I'd do with one even if I wasn't constrained by size. Even on the ISS they seem to have run out of interesting things to do (last I heard they were growing lettuce in space...). Just wondering if anyone has got any cool ideas
> last I heard they were growing lettuce in space...
And that is not interesting ... why? Growing food in space is an incredibly fascinating area of research and vital for human spaceflight beyond cis-lunar space. Additionally, micro-gravity offers a unique opportunity to study the core mechanisms for growth, with the necessary spin-off of helping develop more robust crops back on Earth.
And that is not interesting ... why? Growing food in space is an incredibly fascinating area of research and vital for human spaceflight beyond cis-lunar space. Additionally, micro-gravity offers a unique opportunity to study the core mechanisms for growth, with the necessary spin-off of helping develop more robust crops back on Earth.
Yes, it is fascinating and eminently useful for space exploration. The whole domain is a fascianting optimisation problem. Do you use natural light, and require a large surface area. Or is it more efficient to use electricity and have a larger volume fo growing space?
I would love to know if you could grow creeping vines in space, maybe around strands of led lights.
I would love to know if you could grow creeping vines in space, maybe around strands of led lights.
It's interesting but it's also already being done, and there is (presumably) also a long list of other upcoming projects being developed by folks with big-money (e.g. NASA, ESA). The question, then, is what might small-money folks do with a satellite like these?
Okay, growing lettuce in space is better than not doing it at all... but how many billions of dollars are you willing to pay for it? Lots of research helps with "beyond cis-lunar" exploration. Maybe building a biosphere in antarctica? While I'm glad it exists, the ISS is a very expensive project that seems to do rather insignificant research
What's so uninteresting about growing lettuce in space? Isn't it at least a little bit awesome that they're able to achieve some small aspect of self-sufficiency in orbit?
Fitting into a bulk launch with hundreds of other tiny craft makes the hardest part -- getting into low earth orbit -- relatively affordable. Once you're there, by being small and patient you can gradually lift your orbit using slow-and-steady methods like solar sails or electrodynamic tethers.
I wrote a payload controller in Go for a high altitude balloon. Like KickSat, it included a native KISS/AX.25 implementation along with an APRS library for sending and receiving most packet types. It was my very first Go project and as such, it's pretty dreadful and embarrassing to review but it did work:
https://github.com/chrissnell/GoBalloon
I even wrote a curses-based flight control console for it:
https://github.com/chrissnell/gophertrak
https://github.com/chrissnell/GoBalloon
I even wrote a curses-based flight control console for it:
https://github.com/chrissnell/gophertrak
Also there is an open source cubesat: https://upsat.gr/
Hey UPSat member here!
Getting ready to share some good news on the project in the coming couple of days regarding the successful integration to it's launch system and some details on the launch and delivery to ISS.
Getting ready to share some good news on the project in the coming couple of days regarding the successful integration to it's launch system and some details on the launch and delivery to ISS.
Hi Everyone,
This is Zac from KickSat. I'm glad there's interest in our project. We have KickSat-2 almost ready to go. It was supposed to launch this summer but got held up by the FCC (long story - not our fault). We're currently working with NASA to get on another launch, hopefully in the next 6 months or so. If anyone has any questions, feel free to reach out by email (not hard to find if you look for me on GitHub) or find me on twitter (@zacinaction).
- Zac
This is Zac from KickSat. I'm glad there's interest in our project. We have KickSat-2 almost ready to go. It was supposed to launch this summer but got held up by the FCC (long story - not our fault). We're currently working with NASA to get on another launch, hopefully in the next 6 months or so. If anyone has any questions, feel free to reach out by email (not hard to find if you look for me on GitHub) or find me on twitter (@zacinaction).
- Zac
Zac I think I can speak from the whole team of the Libre Space Foundation that you are doing great work.
If LSF can assist you in any way possible (like SatNOGS access, don't hesitate to ping us)
If LSF can assist you in any way possible (like SatNOGS access, don't hesitate to ping us)
What is the point of having thousands of these things floating around? (Serious)
Those folk interested in receiving telemetry signals from this and similar satellites may be interested in SATNOGS [1], the DIY Satellite Ground Station, likewise open source.
[1] https://satnogs.org/
I would love to receive data from kicksat using the SatNOGS groundstation network
KickSat was launched in 2014 (piggybacking on the SpaceX CRS3 ISS resupply mission). The launcher failed to deploy the sprites and eventually re-entered the atmosphere.
The main cost of this type of initiatives is sending them to space. In this case they were awarded by the NASA but will cost millions otherwise.
Other open software software (not updated for two years) that was used for three nano satellites is here https://github.com/satellogic/canopus .
Other open software software (not updated for two years) that was used for three nano satellites is here https://github.com/satellogic/canopus .
Millions is a bit high for the cost of a cubesat launch. A number of places estimate 1U cubesat launch prices as low as $40k, but probably 1U-3U you can expect to pay low hundreds of thousands.
Yes, It is not on the millions but on $ 60k per kg according the Satellogic CEO [1]. The millions number is if you want to launch a constellation of satellites.
[1] http://www.clarin.com/sociedad/Hoy-espacio-Manolito-satelite... (spanish)
[1] http://www.clarin.com/sociedad/Hoy-espacio-Manolito-satelite... (spanish)
Doesn't cost millions. CubeSats take up extra cargo capacity on other missions. They cost ~50k to launch.
Arduino probably won't stand radiation for a long. In case people interested, in Russia there is a crowdfunded project running to send a space probe to the moon.
Congrats! Stunning animation of the orbital deployment ;)
What data are you planning to collect from this cubesat network?
What data are you planning to collect from this cubesat network?
Why is there a gyro? for proper sunlight to the solar receiver?
How to Launch nano sats ?
this going to let us “listen” to signals that have traveled lightyears much better than ever before. i think we’ll find there is life (intelligent) everywhere you look. that the universe is literally infested with life everywhere you look once you look correctly. And the notion that humans are the only intelligent ones around we'll be like the earth is flat.
i.e. the real space travel is not elon musk bigger and bigger rockets to go further and further into space. We are already IN space. WAY out there. The earth is a spaceship. The real space travel is just listening to all the signals comes to us _better_.
But it was a super fun opportunity to get involved with with tracking the carrier satellite and decoding telemetry. And with a really inexpensive setup based around a $20 software-defined radio dongle.
I blogged about here: https://dolske.wordpress.com/2014/04/21/satellite-radio/
As a bit of a followup, I was successful in capturing and decoding a number of its passes over the following weeks. Including what seems to have been the last received signals from it, on 5/13/2014: https://groups.google.com/d/msg/kicksat-gs/U_svX4f2xY8/StfEl... Shortly after that it burned up upon reentering the atmosphere, likely over Africa.
AIUI the Kicksat-2 re-flight is close to launching; the last Kickstarter update said it missed the upcoming (September) OA-5 launch to ISS due to a last-minute issue with a radio license. fingers crossed soon!