KickSat: open source spacecraft project
github.com
github.com
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!
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 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.
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?
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.
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).
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.
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?
What you describe is a good idea, and how most older sats work (just not modularized).
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 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
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.
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
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.
I would love to know if you could grow creeping vines in space, maybe around strands of led lights.
https://github.com/chrissnell/GoBalloon
I even wrote a curses-based flight control console for it:
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.
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
If LSF can assist you in any way possible (like SatNOGS access, don't hesitate to ping us)
Other open software software (not updated for two years) that was used for three nano satellites is here https://github.com/satellogic/canopus .
[1] http://www.clarin.com/sociedad/Hoy-espacio-Manolito-satelite... (spanish)
What data are you planning to collect from this cubesat network?