KSP Community CubeSat

[Nicholander]

christok, here's what he said about the sim if you haven't read it:

In any case, I think next stage should be simulation. I've realized that I'm not entirely sure what the requirements for various missions are going to be, so I'm not sure how to properly budget solar panels, etc. This is the sort of thing that can be resolved with simulation. I'll write a simple orbital elements integrator that assumes reference ellipsoid for Earth gravity and supports things like magneto-torque simulators. I can make it work with off-the-shelf 8051 emulators, so that software can be tested on the same platform.

Edit: I'll set up a GitHub repo for it as soon as I have some basics down. I'll definitely want someone else to look over the mathy parts of the code to make sure I didn't leave anything out.

Mazon Del, I really don't have any more questions other then the bacteria thing, so all that can be said is that these delays are not good! (K^2 is busy, and Luis is on vacation)

[christok]

christok, here's what he said about the sim if you haven't read it:

Mazon Del, I really don't have any more questions other then the bacteria thing, so all that can be said is that these delays are not good! (K^2 is busy, and Luis is on vacation)

Oh I read it, I just plain don't remember it because this thread is too long. I'll start thinking about it the requirements. K^2, what's your language/library preference for this? Anyone else have an opinion?

[Mazon Del]

It is an unfortunate delay and for sure we want to keep as much forward momentum going as possible, however situations like this will occur. Considering that Luis is just a volunteer consultant with no stake in this project currently, I am not going to spam him with messages as I've lost such volunteers before through actions like that. So not much I can do there. I plan to do a little modeling to show the concept that I have for the growth trays.

[Nicholander]

Modeling? You mean that you're going to make a small little KSP mod of our CubeSat, or are you talking about something else?

[christok]

Modeling? You mean that you're going to make a small little KSP mod of our CubeSat, or are you talking about something else?

I mean modelling systems, as in simulation. My academic background is in statistics and I do some work with chemical/physical models in the real world (but that isn't the main focus of my job).

[Mazon Del]

For myself I was more meaning CAD. I was going to Solidworks up my proposed mechanism for holding the growth trays during launch and provide some images (perhaps video) showing what I was thinking.

[Nicholander]

I mean modelling systems, as in simulation. My academic background is in statistics and I do some work with chemical/physical models in the real world (but that isn't the main focus of my job).

Oh, sorry. My derp.

Anyway, did any of you PM K^2 about more info about his sim? Did you ask him if he could upload the work he's done so far on the sim?

[K^2]

K^2, what's your language/library preference for this? Anyone else have an opinion?

C++. And yeah, this would go faster as a team effort. I suppose, I can start writing short snippets of computational/physics critical code if you want to jump onto writing interface etc.

Ideally, I'd like to split the integration into the core code that's completely platform independent, and which we can turn into a DLL that can run on anything, and the shell with various UI, logging, et cetera, which would be written for a specific platform. That way, for example, if I'll want to do rendering with DirectX running the same simulation, it'd be easy to do.

[christok]

C++. And yeah, this would go faster as a team effort. I suppose, I can start writing short snippets of computational/physics critical code if you want to jump onto writing interface etc.

Ideally, I'd like to split the integration into the core code that's completely platform independent, and which we can turn into a DLL that can run on anything, and the shell with various UI, logging, et cetera, which would be written for a specific platform. That way, for example, if I'll want to do rendering with DirectX running the same simulation, it'd be easy to do.

Totally agree on splitting the UI/engine. I'm not overly familiar with suitable libraries for the interface but I guess it's always a good time to learn. I'd pick OpenGL over DirectX for portability reasons (not that I actually know either). A web interface may be best of all, since it's something that can come in handy during crowdfunding.

I can help out a little with physics programming (I'm not completely ignorant) but I'll need to brush up on some things first. I understand Hamiltonian mechanics is what's normally used? From your previous post I think I that you want to assume a Keplerian orbit and simulate mainly the attitude control system as the satellite moves through the varying magnetic field, or did I misunderstand?

[Nicholander]

christok, now I assume you (And K^2 cause he said that he can make some little snippets) are going to continue (From K^2's perspective)/ start making the sim, so when do you think a stable version will be done? (Done = can do the basics we need and doesn't crash all the time)

[Mazon Del]

That isn't exactly an answerable question at this time. We honestly don't even have a fully fleshed out concept of operations or equipment ideals. So there isn't really even a true idea of what the code needs to do. We can make a hello world program with empty functions that we refer to as 'attitude control', 'biocontainer management', etc and it would be quite meaningless, but stable. I think once Luis gets back after this week and we get a good idea of what sorts of data we will need/want to collect, we will be able to start figuring out the concept of operations, from that we can begin actually determining more information about hardware than some vague guesses about which processor to use. Additionally there will be two phases of stability in the software. Stable in that it can run on its own just fine. And stable AFTER it has been integrated with the hardware. There is going to need to be some significant effort to make sure the system can detect spurious data and take action on its own. After all, we are not very likely to have constant communication with the satellite. If anything we are going to need to spec it out so that if we establish several minutes of communication that we can download 2-3+ days of data (assuming for weather or whatever that we couldn't establish a connection) so we don't lose anything. But in general the satellite is going to be on its own, so this is going to entail quite a bit of systems testing on our part both in a simulated and 'real' environment.

[K^2]

Totally agree on splitting the UI/engine. I'm not overly familiar with suitable libraries for the interface but I guess it's always a good time to learn. I'd pick OpenGL over DirectX for portability reasons (not that I actually know either). A web interface may be best of all, since it's something that can come in handy during crowdfunding.

OpenGL is a bit finicky on Windows. Also, shader support on DirectX is better, and I have some working Earth-rendering code based on data from NASA. But it's more important to get non-visual aspects of it right. I think, it's going to be easiest to simulate everything on the level of physical elements. I'll look into it in a bit more detail, but there is a lot of code like converting GPS coordinates to and from orbital elements and time, etc. Things you need for interfacing with the simulation that aren't necessarily visual. That would probably be a better place to start. And if it has to run from command line for now, that's fine. So long as you can do things like query current location of the sat, tell the time to advance, query again, etc.

I can help out a little with physics programming (I'm not completely ignorant) but I'll need to brush up on some things first. I understand Hamiltonian mechanics is what's normally used? From your previous post I think I that you want to assume a Keplerian orbit and simulate mainly the attitude control system as the satellite moves through the varying magnetic field, or did I misunderstand?

There are two parts to it. One is for torques and rotation. That's pure Euler mechanics. There is nothing fancy there. The integration needs to be decent, but the sat will need to be able to correct for any drifts, so small numerical errors here aren't a big deal.

The second part is satellite's motion around the Earth. That stuff will be derived from Hamiltonian mechanics, yes, but by the time things like drag forces enter (or thrust, if we get to that), it will be just a set of differential equations to integrate. Now, this part's tricky, because we want to guarantee that integration isn't the weak link.

There are also two options here. I can either simulate Newtonian physics + corrections from gravity treated as inertial forces. (That's what KSP does, but I'll have corrections due to non-spherical Earth in there, plus, much better integration routines.) Or I can convert real forces on the sat to be taken into account in differential equations for orbital elements. I think, the later is more precise, because a lot of "hard" integration is actually the analytical solution for classical orbit + perturbations. So I feel like numerical errors will be much easier to control. But I'll have to read some orbital mechanics texts to refresh my mind on it.

In either case, the first step will be testing pure physics part against data from a real satellite.

And yes, I agree with Mazon Del. We won't know how long this will take until we're well into development, and have some hardware specs to play with. But basics we can probably put together soon-ish.

[Nicholander]

Okay, you guys are right. We don't know when this thing will be done. Though this has been sugested before, we really should make a video with KSP RSS which has our CubeSat, and it will surely make this more well known. Maybe even Scott Manley will notice this...

[K^2]

Agreed. But I think we should get some more specs down. Naturally, internals won't matter, but we need to be absolutely set on experiment and know power requirements before we know what sort of panel arrangement to use, for example. Cube + panel arrangement will give the most obvious features of the sat.

I like the idea that someone put forward earlier of having four side panels that open up due to centrifugal force once the sat spins up. That would give the sat a very nice look, and would be easy enough to replicate in KSP. Once we have CAD-ed parts, we can export these into KSP parts and make it look almost perfect. That + Sol mod should make for a great publicity video.

[dharak1]

How many panels could we deploy per side using the spin up? I know typically they have a panel per face but would it be possible to have two, three or even four folded per side? I don't think we would need that many but if we did would it be possible to do it that way?

[K^2]

In principle, two is doable, and three is pushing it. But I don't think we need that. The spin axis will be pointed towards the Sun, which means that all four panels will be at 100% illumination. That's more that most cubesats ever need. In fact, with this in mind, we might not even need four full panels.

[Nicholander]

Yes, we would only need 4 facing the sun. Also, would it be possible to see the pressurized area from the outside, or will it be completely encased?

[K^2]

I was thinking of having one face of the cube open, to expose the pressurized vessel to sun-light. Glass should block most of the UV, so you'd get natural sunlight for 45 minutes out of an orbit.

[Mazon Del]

I am just a little hesitant of the idea for the panels to open through the force of the spin alone. At minimum I think at least a locking system so once the panels are open, they stay open is necessary. There have been satellites that deorbited way before their time because they had parts flopping around mucking with their orbital stability. Honestly what we might want to look into is for the panels to be spring loaded (the springs are trying to keep the panels closed) and we have a simple cable pull (single motor, one cable to each panel) that pulls them open when it reels in, and the spring forces them closed when it reels out. We had discussed something similar to this earlier as we were hoping that if we operated with a window (which I vote for, especially if we manage to put a camera in this thing) that it might be a heat loss issue during darkside operations.

Ooh, fun thought. A few of my friends nearby do work with automated hydro/aqua-ponics. For our control, we could rig up a closed system or two that simulated the light/dark cycles, and if we had a relatively good model (or record from the sat) of the temperature curves, we could do that as well (for just the bio-container anyway).

[Rakaydos]

Ooh, fun thought. A few of my friends nearby do work with automated hydro/aqua-ponics. For our control, we could rig up a closed system or two that simulated the light/dark cycles, and if we had a relatively good model (or record from the sat) of the temperature curves, we could do that as well (for just the bio-container anyway).

Ask your friend what kind of expirimentation he could put into half a 10cm cube?

[christok]

I was thinking of having one face of the cube open, to expose the pressurized vessel to sun-light. Glass should block most of the UV, so you'd get natural sunlight for 45 minutes out of an orbit.

Some things to consider:

- Glass can be quite brittle. I don't think the launch provider would accept any old glass, if they allow it at all.

- Most types of glass do absorb UV, but we haven't done the calculation. We don't have much thickness to work with and it might not be doable.

- Sunlight up there is very intense. I'm still afraid of cooking the experiment if we get our design wrong.

I am just a little hesitant of the idea for the panels to open through the force of the spin alone. At minimum I think at least a locking system so once the panels are open, they stay open is necessary. There have been satellites that deorbited way before their time because they had parts flopping around mucking with their orbital stability. Honestly what we might want to look into is for the panels to be spring loaded (the springs are trying to keep the panels closed) and we have a simple cable pull (single motor, one cable to each panel) that pulls them open when it reels in, and the spring forces them closed when it reels out. We had discussed something similar to this earlier as we were hoping that if we operated with a window (which I vote for, especially if we manage to put a camera in this thing) that it might be a heat loss issue during darkside operations.

Springs I can live with but any motor adds tremendous complexity. A motor that has to work repeatedly is just asking for failure, and this would be a single point of failure for the entire mission. I am absolutely against such a scheme.

Concerning the night side, a forward-facing window will not need nearly as much insulation as it will receive considerable infrared radiation from Earth. LEO is fortunately not as harsh as solar orbit.

Ooh, fun thought. A few of my friends nearby do work with automated hydro/aqua-ponics. For our control, we could rig up a closed system or two that simulated the light/dark cycles, and if we had a relatively good model (or record from the sat) of the temperature curves, we could do that as well (for just the bio-container anyway).

I was thinking along similar lines. I was also thinking that we need to run a test before we launch anything, to see if we got something experiment-killing wrong. We should build a mock satellite and run the test in a homemade vacuum chamber for an extended period to see if our seals need work. I can't do it because the power goes out every so often.

K^2, I created a blank repository called "ksatsim" on Github for the simulator (same username).

I added the LGPL licence since I don't really care what anyone wants to do with it but I don't like the "someone slapped his copyright on a bugfix"-type scenarios that more permissive licences enable. If you have reason to prefer something else, speak up.

I'm also going to upload a basic C++ project outline (autotools files, main.cpp, etc.). I don't know your preferred toolchain but I certainly won't complain if you add Visual Studio project files.

[Mazon Del]

Well that is mostly my part on there, the real question we currently have for Luis is what sensors in specific should we try for. Obviously there are a few like humidity, temperature, those generally speaking are very small modules and shouldn't be a problem.

One thing I am curious about that may require some experimentation in mockups before we commit to a design is what in the way of humidity and CO2/O2 control we are actually going to need. It could be possible to make a very small dual use humidifier/dehumidifier if we think it would be necessary, we still don't have a good idea how to manage CO2/O2 levels and I think someone should look into that since it will likely be a problem we will have to deal with.

Incidentally, I spoke with a friend who is part of the HAM radio community, he says that in general it is quite easy to get operators to throw in assistance for cubesat communications. He says they occasionally toss up a cubesat themselves, so they actually have some experience with this. Someone could look into setting this up. We may want to set up a system so we can make a file, call it "Instruction 6" and pass it out. That way if it recieves a second Instruction 6 or a 5 or whatever, it knows to disregard these repeats. This way we can pass the file around to the various operators and have them try and send the instructions.

[Nicholander]

..., we still don't have a good idea how to manage CO2/O2 levels and I think someone should look into that since it will likely be a problem we will have to deal with.

Couldn't you just use an O2 tank to give air/O2, and a CO2 scrubber to get rid of the CO2? Both won't last long, but we are dealing with plants here, and they give off O2 when given sunlight, so we could just put some LEDs to assist in the life support system, though I don't know how much power that sucks out.

[Mr_Brain]

Couldn't you just use an O2 tank to give air/O2, and a CO2 scrubber to get rid of the CO2? Both won't last long, but we are dealing with plants here, and they give off O2 when given sunlight, so we could just put some LEDs to assist in the life support system, though I don't know how much power that sucks out.

As I understand it, you want to do the opposite: You want to give it more CO₂ to photosynthesize and remove the O₂. It would still work, of course, but I guess there are less devices to get rid of O₂ available. Regardless, even if there are none available, it would be possible to look into chemical reactions that consume O₂ and work sufficiently quickly and efficiently (and non-burningly) to provide the plant(s) with sufficiently high CO₂ concentrations.

EDIT: I'm not sure, but I think I remember reading on this thread that gasses under pressures greater than 1.2 atmospheres are prohibited on cubesats, but as I said, I'm not certain. Therefore, it might be problematic to include a gas tank.

EDIT2: Just found the post.

-snip-

So some atmosphere will get lost, replacing it is tricky as only low pressure tanks with inert gas (not oxygen, better CO2) is allowed.

"No pressure vessels over 1.2 standard atmosphere shall be permitted. "

-snip-

Edited August 13, 2014 by Mr_Brain

[Aethon]

A few of my friends nearby do work with automated hydro/aqua-ponics. F

Lol

K beginning to feel out of my league here but I have other things to offer. None of this may have any relevance but there you go.

Cheap vacuum chamber for testing on your own time. : http://www.scientificsonline.com/vacuum-bell-jar.html

Did any of you look at NASA GMAT tool I posted WAAAAAAY early on. From what I'm led to understand it should be very helpful for this. Plus NASA has approved it for use in its program.

Do you want to go Mars but don't know when to leave or how much to bring? Do you want to study Earth protection by planning a mission to a near-Earth asteroid? Do you want to place a telescope in an orbit that is always looking outwards from the Earth and Sun? The General Mission Analysis Tool (GMAT) is an open-source space mission design tool to help you answer these and many other space flight challenges. GMAT is developed by a team of NASA, private industry, and public and private contributors. It is used for real-world engineering studies, as a tool for education and public engagement, and to fly operational spacecraft.

NASA's G(eneral) M(ission) A(nalysis) T(ool). : http://gmat.gsfc.nasa.gov/

FREE! AGI modeling software.

STK is a free 2D and 3D modeling environment used by engineers, mission analysts, operators and decision-makers from more than 700 global organizations to model complex systems (such as aircraft, satellites, ground vehicles and their sensors) to evaluate their performance in real or simulated time. Built on a time-dynamic, physics-based geometry engine, AGI software answers fundamental questions essential to solving dynamic analysis problems, including:

• Where are my assets and how are they oriented?
  
• What can my assets “see†and what can “see†them?
  
• What is the quality of the relationships?
  

http://www.agi.com/products/

Like the idea of many members working separately and keeping the momentum going, but this ( sorry Nicholander ) could take years.

I remain confident however, that this will be our logo in space, someday.

Edited August 13, 2014 by Aethon