nanosat programming questions

[GIThruster]

I'm pretty ignorant of what today's hardware and software is capable of and even what are the right questions to ask here. So I'll just stumble along and hope someone will be kind and fix the questions themselves.

Lets suppose you have a working, low thrust Mach-Effect Thruster that will fit into a cubesat, and you want to fly it around in deep space as part of a TRL7 demonstration of the technology. So you want to build a cubesat. And lets get crazy (because it's fun) and say that you have a radiation hardening technique you want to try out too, and if it works, you can fly through the Van Allen Belt unscathed. Since MET's don't run out of propellant, once you're clear of the VAB, you can go anywhere you'd like. You can for instance go cislunar. Cislunar is good. It's close enough to mother Earth that you can likely stay in touch and confirm the status of your spacecraft.

So that's 3 stages of mission. First to fly to equatorial orbit. Second to fly through the VAB. Third to fly to the Moon. And lets get all crazy and say forth you wrap around the moon, and fly off to Mars while its opposed to Earth. You cut across the system where there's lots of sunlight and say hello to NASA's first gen Elektra radio aboard the Mars Recon Orbiter as you flash by at a significant fraction of c. That's 4 phases.

Craziest I go is, if you still have control over the craft, swing it around Mars and bring it back to the Moon. If you can manage the really tight turns without aerobreaking in Mars' atmosphere, you could theoretically fly back and forth between Mars and the Moon until the thruster gives out. Eventually you'd be making transits in less than a day, and the thruster could well last for years. You want and need the data for duration flight so this final stage is actually more than a dramatic demonstration. It informs future thruster design work and makes the craft into a thruster lab all its own, out there contending with solar radiation and all sorts of other issues you'd like to get info on.

To do this, you need to steer the cubesat. It's got an array of hundreds of tiny thruster elements spread out laterally so you can steer the thing by switching them off. The question comes, how do you program such a thing? Is there anyone here who can comment on this task intelligently and say whether you think it even possible the GN&C here is capable of such a journey?

http://www.cubesatkit.com/

And who do you look for to develop such a system? Not just a "programmer". . .but what? How do you even screen people to see if they can do this kind of work?

[paperburn1]

The first problem I see is directional control. If you do not know your orientation, how can you program a flight path. you would need some sort of sensor array to tell you where you are and if your tiny little space craft is spinning, tumbling and relative to what. once you can answer that question. Then navigation becomes easy. you will know where you are and you will know where everything else is relative to that fixed point. How to do that in a small space would be the question
CCD cameras and star charts?

[GIThruster]

Most of the cubesat kit providers have star trackers in their inventory. Here' an example:

http://bluecanyontech.com/all_products/star-trackers/

So you ought to be able to point the thing. The question is where/how to point it.

[hanelyp]

Presuming you can reverse the direction of a thruster by phase shifting, a pair of thrusters could deliver thrust along a line or torque on an axis normal to the thrust line and the line between the thrusters. Three such pairs and you have full 6 axis control.

A digital camera and an on board database can serve as a star tracker with a ridiculously simple algorithm than involves finding a bright star near the center of view, then dividing the view into rings of equal area selected to have about a 50% chance of a star of a selected magnitude appearing somewhere within a sky patch of that size. With enough rings the presence or absence of bright stars in each ring becomes a binary code that in most cases uniquely identifies the center star.

Keep track of the direction to Earth, Mars, and the sun, and you have a decent idea of your current position. Radio round trip time to Earth can refine the position.

As far as gravity turns whipping around the moon and Mars, I very much doubt you could make a tight enough turn for anything close to a one day round trip.

[paperburn1]

On the Moon, the gravitational acceleration is much less than on Earth, approximately 1.6 m/s2
That would limit your top speed for return flight.

[paperburn1]

Maybe we should simplify. All we are doing is proof of concept.
A cube sat with a GPS chip and a transmitter. Stabilized by a conducting tether that has gizmo that can turn the developed voltage into a usable power supply for the thruster. you launch, record the position , unwind the tether , record the position for a while. Turn on the thruster and see what happen. If it works you just changed the state of space travel.

[93143]

I'm not so sure about that tether. It would produce thrust as well as power, neither one easy to predict exactly, potentially swamping the signal from the thruster.

Why not solar?

[paperburn1]

cube sat are small. A tether would supply orientation and stabilization as well as power, at least in theory

[hanelyp]

A tether producing power does so at the expense of drag. If energy is to be conserved, that drag would seem to necessarily exceed thruster output (unless you make special assumptions about the mass the thrusters couple to.)

A tether producing gravity gradient stabilization without a current flowing for power production or thrust could be viable for a spacecraft confined to Earth orbit.

[paperburn1]

If it was not for physics and law enforcement I would be unstopable
ok tether bad for power supply