Sunday, May 23. 2010
Is there anyone out there?
It's a question that has plagued humans ever since we first looked up into the stars. What's out there? Statistically - so the argument goes - we can't be the only ones floating around in space. There are billions of galaxies out there, each containing billions of undiscovered stars. It seems almost impossible that we are alone, a single inhabited planet spinning around in all that vast emptiness.In fact, it was a long series of happy coincidences that gave us life. One great fluke after another is the only thing that sets us apart from all those other cold, barren stars. The chances of replicating the chain of events that created intelligent life are vanishingly small. If one were to set out to do so, however, it would look something like this:
Pick a galaxy sufficiently boring, so as not to be colliding with other galaxies. Your pick will need to be a third generation star so that there's a good smattering of good star-stuff like carbon and iron to play about with. Next, find a system in the boring part of that boring galaxy. A provincial place, like the unfashionable end of a spiral arm. You don't want to get too close to black holes, pulsars, and stars going supernova.
Once you've found the right galaxy, take one planet - not too hot, not too cold. Must have one good sized moon - not too close, not too far away. Ensure the local star (known locally as the "sun") is a slower-burning yellow star, and not a binary. It is good practice to locate the planet near some other, larger planets, to prevent any of the bigger asteroids from wiping the planet out before, or even after, life is born. The planet must have a molten iron core, and its moon must be able to push and pull that core. An atmosphere helps, too. It will interact with the convection currents and create weather.
Once you have found the perfect planet, maintain an evironment conducive to life for as many billions of years as possible. Eventually, something might — might — crawl out of the mud, and flop onto the shore. Wait another few billion years, and they might have legs, and have embarked on a mission to destroy the world that has sustained them.
Life, then, is perhaps much more rare than we would like to think. If just one step in the life-forming process had not occurred, or had a different result, then life as we know it could have been vastly different, or made extinct in an instant. There are many things that could have gone wrong. The moon is a planetary twin to the Earth, and it is extremely important to life here. If the moon had not broken free and settled into orbit where it did, we wouldn't have the tidal systems, tectonic plate activity, magnetic fields, or protection from the sun's radiation. Another possibility could have been Jupiter and Saturn fusing together. If that had happened, we would have had a second sun in our solar system. This could have any number of untold side effects, most of which would eventually be lethal to life on Earth.
Statistics might argue that out of the billions upon billions of planets out there, the possibility of life being on any one of them is high. But out of those billions, how many are able to support life? And out of those small few able to support life, how many could have evolved as far as we have?
Is there anyone out there? Will we know until we go and look?
(Image shared under a Creative Commons Attribution-Share Alike 3.0 Unported license)
Saturday, May 15. 2010
More Throttle Control progress
Under software control, Luke has demonstrated opening and closing the throttle +/- 10 degrees. This 'dithering' action is made using a simple algorithm and can be customised so as to prevent the super-cold liquid oxygen ball valve from sticking, prior to launch.
Luke's work is advancing nicely with a PCB layout for throttle control hardware. We'll attempt to make the make the board dimensions and positions of the mounting holes identical between the Rutex R2020 and the throttle control board, so they can be stacked together making them more space efficient.
After analysing design proposals, Roy suggested providing two sensing potentiometers for valve positioning. This would provide redundancy in case one is damaged and increase valve position accuracy when the results of both are combined. Roy's proposal is to have the two cams, which are connected to the throttle position sensing potentiometers, offset by 45 degrees. Nice throttle control work being done Numbatters!
Luke's work is advancing nicely with a PCB layout for throttle control hardware. We'll attempt to make the make the board dimensions and positions of the mounting holes identical between the Rutex R2020 and the throttle control board, so they can be stacked together making them more space efficient.
After analysing design proposals, Roy suggested providing two sensing potentiometers for valve positioning. This would provide redundancy in case one is damaged and increase valve position accuracy when the results of both are combined. Roy's proposal is to have the two cams, which are connected to the throttle position sensing potentiometers, offset by 45 degrees. Nice throttle control work being done Numbatters!
Saturday, April 3. 2010
Throttle Control work, progresses
Fortunately the variable throttle control technology we're developing for ASRI's Ausroc 2.5 is also transferable to the descent stage motor of the White Label Space lunar lander, so it's a win all round for our GLXP partner WLS, the Australian Space Research Institute, and us.
With parts for development provided by ASRI, Luke Weston has built a 60 V power supply for testing the motor which will drive the gearhead that will control the RP1 valve, and thus throttle propellent to the rocket engine.
After some simple testing, Luke has also tuned the Rutex R2020 servo drive board so as to give it full control of the motor / gearhead assembly, as seen below:
Along with this great work, Luke has also prepared some preliminary code for an AVR (Arduino) to control the throttle motor via the Rutex servo board, and done a marvellous job of updating the relevant documentation on the Wiki.
Ultimately, through Luke's and the rest of the build team's efforts, we'll prepare avionics to take instructions on a CAN bus and translate these to valve positions which will control propellant flow into the Ausroc A2.5 rocket engine, and thus thrust. All a bit exciting really
With parts for development provided by ASRI, Luke Weston has built a 60 V power supply for testing the motor which will drive the gearhead that will control the RP1 valve, and thus throttle propellent to the rocket engine.
After some simple testing, Luke has also tuned the Rutex R2020 servo drive board so as to give it full control of the motor / gearhead assembly, as seen below:
Along with this great work, Luke has also prepared some preliminary code for an AVR (Arduino) to control the throttle motor via the Rutex servo board, and done a marvellous job of updating the relevant documentation on the Wiki.
Ultimately, through Luke's and the rest of the build team's efforts, we'll prepare avionics to take instructions on a CAN bus and translate these to valve positions which will control propellant flow into the Ausroc A2.5 rocket engine, and thus thrust. All a bit exciting really
Thursday, April 1. 2010
Lunar Numbat at linux.conf.au
Wednesday, January 20. 2010
Jon to speak at LCA 2010
linux.conf.au (LCA) is one of the premier Free and Open Source Software (FOSS) conferences anywhere in the world, and this year build team member Jon Oxer will be presenting a talk on Lunar Numbat.Jon's talk will follow the arc described in the recently released GLXP Mission Concept Summary by White Label Space, and how Lunar Numbat's efforts as a partner, and Open Source technology will help make it happen.
The talk will be streamed live at 14:30 UTC+13 (01:30 UTC) tomorrow, the 21st of January 2010, so you can watch without even attending the conference!
As always we're certain Jon's talk will be great! We should be able to provide the talk notes and video after the event.
Monday, October 26. 2009
LN & WLS meet face to face
Andrew Barton of White Label Space was a great host in receiving me today, and we spent the whole day exchanging views and knowledge on issues related to Lunar Numbat, White Label Space, and the GLXP mission.After collecting us at Leiden train station, Andrew didn't delay in taking us on a tour of the European Space Research and Technology Centre (ESTEC). Here are many of the facilities that WLS will likely be using in preparation of the GLXP mission. ESTEC includes facilities such as the Large Space Simulator (LSS), acoustic and electromagnetic testing bays, multi-axis vibration tables and the ESA Propulsion Laboratory (EPL).
Following the tour we moved on to the White Label Space headquarters at AOES and settled down to some detailed discussions.
Later in the evening, I attended a WLS team meeting where the throttle control avionics, radar altimeter and HD Video and Stills compression and transmission that Lunar Numbat are developing for the WLS GLXP mission were poured over and examined.
It was really valuable to finally meet Andrew and many of the WLS team members face to face, and Lunar Numbat's commitment to exploit the goodness of Open Source technologies to assist WLS in our GLXP mission was well assisted by the get together.
Saturday, June 20. 2009
Building up capability and practical expertise
Monday, June 1. 2009
Playing with models
Example of Numbat motion in the vicinity of the Moon. In the left-hand panel, the craft approaches the Moon and enters orbit. Several orbits are shown, along with their corresponding "ground tracks" on the surface of the Moon. In the right-hand panel, the engine fails to produce enough thrust for the craft to enter lunar orbit.
The Lunar Numbat team have been developing a computer model for the
motion of a spacecraft in the vicinity of the Earth and Moon.
The model includes the gravitational effects of the Earth, Moon and Sun,
and a simple engine can be fired to accelerate the craft.
The positions of the moon and sun are approximated with internal functions,
although positional data for the Moon can be incorporated automatically
from JPL's Horizons web service. In this way, the program can use lunar
position data approaching DE405 accuracy.
This may potentially prove useful in testing avionics or other control
software. Information on the motion of the Numbat from the model could
be used to feed mock telemetry or other data to control software,
which would react (e.g., by firing an engine in a given direction)
and those forces would in turn influence the motion of the model Numbat.
Some examples of output from the model are shown at right.
The programs can be found here, in the lunarnumbat.org subversion repository.
A Google Earth screenshot, showing the locations of both the Moon and Numbat against the background stars, as seen from Earth. Output from the model can be easily converted into KML documents for viewing in Google Earth.
Monday, May 11. 2009
White Label Space Joins Google Lunar X PRIZE
White Label Space have been publicly announced as a Google Lunar X PRIZE Team, drawing congratulations and delight from Lunar Numbatters.It's with pride that Lunar Numbat acknowledges it's partnership with Team White Label Space, as well as the Australian flag on their patch, the only one of any GLXP Team.
White Label Space sees this as the beginning of an adventure that has far reaching consequences for all of humanity. For them the GLXP is the starting point of the next wave of space exploration where the common person can become a contributor and not just a spectator.
Lunar Numbat is keen to do it's side of the bargain and provide Team White Label Space with key technologies in an open and accessible way, to help bring about this next wave of space exploration.
Sunday, May 3. 2009
First class-C launches with Arduino telemetry payload
As a first step to building a more fully-featured payload package for class G and larger rockets, LN member Jonathan Oxer has been working on building a telemetry payload small and light enough to launch in a class C rocket. Because class C rockets can't lift much of a payload he had to keep the mass of the electronics as small as possible. You can get a sense of scale from this photo which shows a small white bundle in the bottom of the nosecone. Inside that bundle is an Arduino Pro Mini 5V/16Mhz, a 433Mhz transmitter module, and a Lilypad 3-axis accelerometer:
The Arduino runs code that reads the accelerometer values, pokes them out the transmitter using the VirtualWire library and waits for the message to go out, then loops back to the start. The result is a stream of values that is pretty much rate-limited by the 2Kbps transmission rate.
On the ground Jonathan had his laptop connected to an Arduino Duemilanove with a 433MHz receiver module:
Running on the laptop was a little piece of code that read values coming from the USB port and displayed them on screen while also writing them to a logfile. This shot shows the values scrolling on the screen while Jonathan holds the rocket and gives it a bit of a shake:
The launches worked really well, but the accelerometer data was truncated so didn't capture the whole flight. The values came out looking like this:
562047|326|328|395
562204|322|330|393
562361|327|327|397
562516|317|335|604
562673|325|331|590
562830|328|330|514
562985|328|331|506
563142|328|331|500
563298|328|329|501
where the columns are:
1: Time in milliseconds since the Arduino booted
2: X force
3: Y force
4: Z force
That data segment is from around the time of the second launch with the Z value stable at around 394 while the rocket was stationary then jumping to 604 and falling to 500 over the next 800ms. Comms failed right at that point, less than 1 second after launch: the cheap 433MHz modules just didn't manage to do the job. Future tests will instead use a pair of 60mW XBee modules supplied by SparkFun that are a lot bigger than the 433MHz modules but should be good for 1Km+ range.
The moment of launch:
The Arduino runs code that reads the accelerometer values, pokes them out the transmitter using the VirtualWire library and waits for the message to go out, then loops back to the start. The result is a stream of values that is pretty much rate-limited by the 2Kbps transmission rate.
On the ground Jonathan had his laptop connected to an Arduino Duemilanove with a 433MHz receiver module:
Running on the laptop was a little piece of code that read values coming from the USB port and displayed them on screen while also writing them to a logfile. This shot shows the values scrolling on the screen while Jonathan holds the rocket and gives it a bit of a shake:
The launches worked really well, but the accelerometer data was truncated so didn't capture the whole flight. The values came out looking like this:
562047|326|328|395
562204|322|330|393
562361|327|327|397
562516|317|335|604
562673|325|331|590
562830|328|330|514
562985|328|331|506
563142|328|331|500
563298|328|329|501
where the columns are:
1: Time in milliseconds since the Arduino booted
2: X force
3: Y force
4: Z force
That data segment is from around the time of the second launch with the Z value stable at around 394 while the rocket was stationary then jumping to 604 and falling to 500 over the next 800ms. Comms failed right at that point, less than 1 second after launch: the cheap 433MHz modules just didn't manage to do the job. Future tests will instead use a pair of 60mW XBee modules supplied by SparkFun that are a lot bigger than the 433MHz modules but should be good for 1Km+ range.
The moment of launch:
Sunday, April 26. 2009
A glance at Software Defined Radio
Software Defined Radio (SDR) is a concept where components that would normally be hardware are replaced with software in a radio communication systems. It has a couple of cool features, but also has some drawbacks for space applications.I will explain what that means shortly, but first a quick background in the components I will be mentioning.
When a radio signal is received by an antenna, it is amplified by a pre-amp, then converted from it original frequency to an intermediate frequency. The selection (tuning) of what frequency is received is part of the conversion process. The main reason to use intermediate frequency is that intermediate frequency is much easier to create electronics for and requires cheaper components. The intermediate frequency signal is then processed (demodulated) to create the output signal, be it audio signals, analog TV or digital data. The reverse process it used to send the signal out.
The most common component to replace is the function that turns intermediate frequency analog signal into the output signal and vis-versa. In SDR, the output of the original to intermediate frequency conversion is fed into a high speed (bandwidth of the signal, typically less than 20MHz) analog to digital converter (ADC). This gives digital representation of the signal, which is then processed by computer. The reverse is accomplished with a
digital to analog converter (DAC).
The computer then turns the digital signal into something useful. This conversion is requires a lot of processing power, so specialised hardware such as Digital Signal Processing (DSP) components are often used. GNU Radio (an implementation of SDR with some open hardware and software) has been used to decode AM and FM radio stations, digital TV and others. GNU Radio hardware uses cable modem components to tune into and convert the original signal to intermediate frequency.
The main advantage of SDR is it's flexibility. A single hardware unit can be used to tune into and decode a large number of different types transmissions. An example of this flexibility is being able to adapt from using 802.11b to
802.11g by tweaking some code, whereas with hardware new chips, components and circuits would be required.
There are two significant disadvantages for using SDR in space applications. They are the computer power required, and failure scenarios.
The significant (1GHz+) processing power required for SDR has three flow on effect: more mass, more power required, and more heat to deal with. More mass comes from the extra computer, which requires extra shielding as faster computers are more prone to solar radiation. Obviously a computer requires power so more electricity is needed. And computers produce heat which must be removed or it will fail, and removing heat in space is more difficult than in an atmosphere.
SDR creates new risks of failure. Because of it's software defined nature, any software problem will prevent the system from working. This is a key risk, as without the communication link, most space craft can't do anything. A second risk is introduced by it's flexible reprogrammable nature. Any upgrade or reconfiguration could prevent the system from working again. Both can be mitigated to a certain extent.
Software defined radio could have a place in space missions where there is a need for flexibility or adaptability in radio modulation and risks are dealt with.
Published under CC-by-sa
Wednesday, April 22. 2009
Arduino-based Rocket flight recorder
Jon Oxer has been very busy as a recent post on his blog attests. The fruit of his work? An Arduino-based rocket flight recorder no less!The image and quote are from Jon's post:
The bottom board is an Arduino Pro Mini 5V/16MHz from Sparkfun. Sitting on top of it is a 433MHz transmitter module from Jaycar, and the circular PCB to the right is a Lilypad 3-axis accelerometer breakout board. To give some sense of scale the entire assembly is about the same dimensions as a 9V battery, so it's very small and light. You're looking at it lying on its "back": the plan is that it will mount vertically in the nosecone of the class-C rocket that Marco provided so that we can log accelerometer data from a launch. When fitted into the rocket the round accelerometer board sits flat in the bottom of the nosecone so the Z-axis reading will align perfectly with the direction of flight.
According to Twitter posts Jon's also taken delivery of a 5Hz GPS module, and after experiencing some difficulties with the Locosys GPS module, it seems to be behaving.
With the two joined together hopes are to get the system transmitting x/y/z force plus lat/lon/altitude every 200ms. If everything works out well we may even get a nice flight track from the location points. Sweet!
Thursday, April 2. 2009
Working on Ausroc 2.5
Recently a fellow from ASRI, the Australian Space Research Institute and the Lunar Numbat build team enjoyed a productive conference call discussing the Ausroc 2.5 launch vehicle, and how we might assist.Ausroc 2.5 is an Australian designed and built liquid fuelled rocket, propelling a 10kg payload to an altitude of 20km on a ballistic trajectory, to be recovered intact after flight. Lunar Numbat agreed to collaborate with valve control avionics, and are delighted to be working with ASRI.
This is an exciting step along the road of providing our partner, White Label Space, with the technologies they need to get to the moon, while helping the already fine work of ASRI.
Thursday, March 26. 2009
Lunar Numbat now has a patch
Thanks to the fine work of Artist Gavin Jacobi, Lunar Numbat now has an official patch to represent us.
While the arrangement and execution of this patch pays honour to a previous historic lunar mission, it's unmistakeably fresh with New Zealand and Australia faithful represented.
Prominent in the centre is our intrepid Numbat mascot, poised both as having just arrived, and ready to boldly explore.
Faithful to the values of the Lunar Numbat endeavour, Gavin Jacobi has released the image under Creative Commons Attribution-Noncommercial-Share Alike.
The master image in SVG format is available on the mail list.
Monday, March 9. 2009
White Label Space, our partner
Alan Kay said "the best way to predict the future is to invent it", which is precisely what White Label Space is doing.
The Google Lunar X-Prize inspired the formation of White Label Space, a group that includes talented space engineers, scientists and technologists from within and outside of the traditional space industry.
What sets White Label Space apart is their vision of low cost ambitious Space Science missions enabled by innovative use of contemporary technologies which are now significantly more accessible, flexible and affordable.
This combined with the innovation of their missions as a vehicle also for marketing, so that sponsors with the "right stuff" can create a profound and enduring legacy by becoming the first private companies to land on the moon.
Lunar Numbat is proud to work with White Label Space, providing them with some of the technologies needed to make this Google Lunar X-Prize mission not only successful, but a precedent that can be followed. First stop, the Moon.
White Label Space are a genuinely International team with people from many nationalities, including Australians. They're geographically based in Europe.
While the Lunar Numbat Blog has a short RSS feed from White Label Space, you can follow their developments directly from their Blog, Twitter feed and Facebook group.
Lunar Numbat
Blogroll
LN Mail List feed
White Label Space
Mixing Music and Space
Torch Igniter Testing Update
First Integration Steps for Rocket Motor Prototype
WLS-J Introduces our GLXP Competitor Selenokhod
Space Ventures Investors Partners with WLS
Thursday, May 17. 2012
Torch Igniter Testing Update
Sunday, May 13. 2012
First Integration Steps for Rocket Motor Prototype
Sunday, May 6. 2012
WLS-J Introduces our GLXP Competitor Selenokhod
Tuesday, April 24. 2012
Space Ventures Investors Partners with WLS
Friday, April 13. 2012
