We are talking about two different prizes.
The good of this you mentioned is we are using same components to build a satellite able to control a mini-launcher and changing the software able to control a PicoRover. I know that eZ430 is not the best solution for a mini-launcher or for a Lunar Rover but if we can reuse this hardware, we will speed-up the development and validation of both projects: Lunar Rover for GLXP and Mini-launcher/wikiwikisat for the N-Prize. To win is in a second plane.
I like your adoption of the "meetup" for "could be a launch, depending on our schedules". Do you think that an all volunteer, open source methodology can achieve complex integrated space flight systems?
This balloon flight was designed to demonstrate / to learn how an small team from different countries can work in a complex project like a mini-launcher. Change balloon for mini-launcher and you will have a complex launch. I know that balloon launch is no so complicated. In fact two persons can do it but we want to split the project and trust one each other. Alex have the responsibility of the ground station. Tobias have the responsibility of build the structure. Anders have the responsibility to program the recovery system. Sonia have the responsibility of to take coverage of the events. Joshua have the responsibility of the electronics. Each one have a part of the cake to work with. If any part fails, the cake lose beauty but still a cake.
Are there any other subjects you think might be interesting for our first WikiSat article on ULSF?Yes, the key of success is KISS. We have to keep the team small otherwise it will be to complex to manage. I have some theories for this kind of open source project called MOLECULE. Molecule is a way to manage a team and is able to scale. This concept is based on the atom (a person) and the radical (a function) and every together forms the molecule (the small team). The schema of this concept follows an organic structure.- When you start a project you have only one Carbon atom. This atom is the only atom that can't be replaced during all the project (this is the weak part).- When the project increases this Carbon atom form a simple molecule with four more Hidrogens (Methane molecule). This small group forms a function. Hidrogens are in charge or realize small tasks commanded by the Carbon. If any Hidrogen fails, the Carbon will realize the task so Carbon don't need Hidrogens but the work will be too slow (this is the robust part).- When the project increases a bit more, one of this Hidrogens change to Carbon and adds two Hidrogens forming a molecule called polymer (Ethane, Propane, etc.). This molecule can grow as much as required and can be adapted to the number of functions that the project requires (Following any IUPAC nomenclature).- When the project is at the end we fire Hidrogens and converting Carbons into Hidrogens.- Finally everything ends with only one atom and the project conclude or remains in standby because some time there are projects that requires to continue after many years since the project was stopped. In this case this main atom will start the process again.
man, 26 10 2009 kl. 11:52 -0400, skrev John Pritchard:
>
> Questions...
>
> The WikiWikiSat shares electronics with the Picorover.. Can it be said
> that the WikiWikiSat is a balloon test version of the PicoRover
> electronics?
>
> The "Wikisat Balloon Recovery System" (WBRS) is an Android
> application. Is this installable on any Google Android phone? Or is
> your phone an unlocked developer unit?
Yes, WBRS is installable on any Android phone. The phone used for
development is a standard HTC Magic, as is the 'flight model' actually
used aboard the balloon.
With a few minor exceptions, I've found that the standard API is more
than enough for our needs, and by staying out of low-level territory, we
reduce risk that some unforeseen circumstance cause our quite literally
"mission-critical" application to break something vital in the middle of
a flight.
The downside is that we don't have as fine-grained control over things
like application life-cycle (does stuff we are relying on suddenly get
garbage collected?) and power management (can we be certain that some
obscure service isn't draining the charge from the battery we need to
run on for the whole length of time until the device is recovered?), but
generally Google has designed the system intelligently enough to suit
our needs too.
Best regards,
Anders Feder