 This session we're going to have a very interesting talk about rockets from Luke Weston, a physicist turned hacker. So please welcome. The intention of Lunar Number is to apply the philosophies and tools of open source to develop innovative, low cost, open source hardware and software solutions for space exploration and space technology. We want to encourage Australia innovation in space. We want to encourage basically a space program in Australia as part of what we do because that's something traditionally that has been really neglected, particularly in Australia, while other countries have been pretty much every other industrialised nation in the world has a space agency, for example, and Australia doesn't. And that's part of what we're interested in, that's part of what we're interested in and maybe changing. You've probably heard a bit about Lunar Number if you were at LCA last year, you would have heard about it from John Oxer. Since then we've been keeping busy doing a few new things and I want to tell you about those things. So some of the things that we're working on are radar altimeters which are possibly going to be used by White Label Space, which is one of the teams participating in the Google Lunar X Prize, because to land on the moon, to land a spacecraft on the moon, you need a radar to tell you how high you are when you're landing to get the altitude information. You can't use a barometer, you can't use a GPS, the only way to do it is by pinging radar off the lunar surface. Another area that we're working on is controllers for rocket engines, so servo valves, computer-controlled servo valves that allow us to throttle and control liquid fuel rocket engines. We're also interested in looking at multimedia compression, for example, JPEG 2000 and JPEG 2000 kinds of technologies for compression, where you're working with, say, a spacecraft on the moon and you want to get some video or some images and get that transmitted back to Earth, you may have a high rate of errors on your comms link and you will probably have a very, very limited... I wonder if I can kill that. You might have a very limited amount of communications bandwidth, so you want to have good compression algorithms and good error correction algorithms to make sure that you're getting your multimedia transmissions with the best possible quality and integrity. So we're collaborating with White Label Space, which I'll get back to in a moment, also collaborating with the Australian Space Research Institute on the OSROC program and the Zuni sounding rocket programs that they work with. So this is a nice piece of kit. This is OSROC 2. The one that we're focusing on at the moment is OSROC 2.5, which will look the same as that, it has the same size airframe. So that is a big rocket, it's about seven metres long. Here you can see it's being on the launch pad, they're being filled up with a big jar of liquid oxygen ready to be fired. I'm sure you all want to know one of the vital stats on this. The vital stats are basically Mach 3.3 at its peak speed, Apigee at about 30 kilometres, 35 kilonewtons out of the engine and it's about seven and a half metres long. Here we've got a simulated plot of the velocity profile for a typical launch of that rocket, so you can see at burnout of the engine it's doing about eleven hundred metres per second. This is a static test firing of the rocket engine, it makes nice, big fire, which is kind of nice. So basically we're working with ASRI and we're collaborating on providing low-cost, innovative open source technology to support Australian-made, in-house space launch vehicle research and development, which I think is really cool, because Australia was actually, I think the third nation to launch a satellite made in Australia from our own territory and we weren't one of the first nations to do that. And Australia, because Australia did have a fairly active space program back in the 60s, back in the Sputnik Apollo sort of era, but then it just kind of died. So we did launch a satellite back in the 60s, but it was launched on a British-made launch vehicle. So there has been no Australian-made, Australian-designed space launch vehicle and that's something that ASRI is interested in changing and that's something that we're interested in supporting. We're making a contribution back to Australian space innovation, which I think is really cool and it's something that I like to support and in the Lunar Numbak community that's something that we're big fans of. This is another rocket, an example of a rocket that ASRI works with. That's a Zuni military missile which has had its explosive warhead removed and just replaced with an electronics payload because the Australian Department of Defense a couple of decades ago decided that they're no longer going to use these and so they donated the stockpile of rocket motors to ASRI for civilian space or rocketry experiments. Now these rockets that we're looking at here, they don't go into space. So 30 kilometres is not space, but it's a very good test bench. It's a very good technology demonstrated platform in a suborbital rocket to develop and work your way up small steps towards going to the moon, going into space. So hang on. So these ones we'll do about maybe just over mark two. We'll go up to maybe about 800 metres high. When you push the button, this is a solid-fueled rocket motor, by the way, it's not liquid-fueled. When you push the button off the launch rail, one of those is going to do about 70G. It's very useful, for example, if you want to test how hard your electronics are against vibrations and accelerations and that type of thing. So one of the things that I've been working on in particular with Lunar Numbat is designing electronic controllers for servo valves that we're using or we're intending to use on OSROC 2.5 to feed fuel and liquid oxygen into the rocket engine on OSROC 2.5. That rocket engine that I showed you a few slides ago, it's running on kerosene and liquid oxygen. And so we have a pair of valves to feed those fuels into the engine, which we want to be able to throttle down and throttle up electronically. That lets us do things like, for example, make a controlled descent onto the surface of the moon. To do that, you have to be able to throttle down your rocket engine and you can also do things. If your flight computer on board the rocket gives you that kind of control, you can do things like stop the rocket engine and reignite it. So with this kind of technology that we're developing, we're using open source, of course, because free is good and open source is good. And we're using a combination of open software, open code, open hardware, electronics, mechanical hardware, which is open too. So we just, as far as I'm concerned, if every circuit and every nut and bolt can be made open, then let's do it because open is good. Just to give you an example, I don't know how well you can see that. It looks pretty terrible, but don't know how to do that. It's schematic up because it wouldn't fit in the acceptable resolution, but that's just a portion of the hardware system that I've designed for this project. That's just a CAN transceiver between the microcontroller and the CAN bus because we have this set of electronics in the throttle fairing of the engine of the rocket and it's connected over CAN, a control area network, back to the central flight computer in the rocket. And so this is just a microchip, the 2515 CAN transceiver that we're using to interface the microcontrollers to CAN. Just, that's an example of the sort of thing that we're working with. And for example, for all the electronics, I like to use the TAPR open hardware license. So it's all nice and open, which is kind of cool. So this is the hardware that we're working with. We have a big stainless steel ball valve and that stainless steel ball valves allows kerosene or liquid oxygen flow from the tank down into the rocket engine. And we have a large DC motor driving that through a reduction gear head. It's not shown in this picture, but that motor has a rotational encoder on the end of it, which is connected back to the electronics. So we're basically creating a closed control loop. So what we have is essentially a giant servo motor. But it's a servo. It's not like your little RC plane servo. It's a servo that'll whip your finger off. And so we have two of these. One is fuel, one is oxygen. And this is what it actually looks like in the rocket, in the valve fairing. So at the bottom of this image is the top of the rocket engine. And above the top of this image is the fuel tank. So we have two valves, two gearboxes, two motors and some electronics. And in between, and that basically just controls the flow of propellant into the rocket engine. And this is the prototype hardware that I've built. So what we've got is an 18-mega 328 from that now. Same chip that you'll find on an Arduino, pretty common stuff. It's interfaced to CAN as I said, it's via a microchip CAN chip set. And the CAN is cabled back up to the top of the rocket to the central flight computer. And you can see that underneath that top board we have a second circuit board. On that board there is a big H-bridge MOSFETs which drives the main motor. And we have some connections to an encoder and that kind of thing. And the main DC power supply for the motor. Where was I? One of the questions that we've kind of been thinking about at this stage, we're only looking at the Ozrock program so we're suborbital 20 or 30 kilometers. But we're also looking at collaborating in the future with White Label Space for the descent engine on the lunar lander for the Google XPRIZE entry. And one of the things that gets raised sometimes is radiation tolerance and that kind of thing that you have to consider when you're engineering in space. And an 18-mega 328 is a VLSI device, fairly high transistor density. And it's probably a little bit susceptible to cosmic ray bit flipping and that sort of thing, radiation damage. It's hard to say without actually doing testing for that kind of thing. But one of the things that we might be looking at in the future for in-space use might be moving to something like an 8051 core or something which has got a bit of a lower transistor to integration density because that gives you a bit, tends to give you a bit better tolerance to radiation effects. And when I started a new engineering project, one of the things I really like to do is just get on Google and you Google, Google, Google and see what everyone else has done first. And then, you know, see what the prior art is and sometimes if it's really, really nice, get some ideas out of that. So I did that actually. And what I found was a group in the AMSAT community, Amateur Ham Radio Satellite Community, have designed and built their own little can interface module for spacecraft use. And I was really impressed when I noticed that the project had been headed up by Bida Algarbi, who many of you will know. So I thought that was kind of cool because he's a pretty cool guy. Based on an 8051 core, which is core and they've already tested it and space rated it for radiation tolerance, vibration tolerance, heat, cold, so forth, all the things that you need to check to qualify a hardware system for space use. And I think maybe that's something that we're probably gonna go back and look at in the future. It'll be very valuable for the future White Label space effort. There's a picture of that little critter, by the way. And if you're interested in that, you can go to the website that the AMSAT guys have set up for that project and check that out. So I mentioned White Label space before, but I didn't really give you the context. White Label space is one of the teams in the Google Lunarex Prize. It's a team, it's the only team that has any real Australian involvement through lunar number. It's also made up of people from Japan, from Europe, people involved with the European Space Agency, people from the United States, some people from Japan who have worked on the Hayabusa probe, which sampled dust from asteroid. And there's a lot of space expertise in this group. We have guys from the Swiss Propulsion Laboratory who are designing the rocket engine for the descent stage of the engine and the descent stage of the lunar lander, sorry, and they've also been collaborating with ASRI on the design of their rocket engines. So the resources that we sort of have access to that we're working with, these guys are not amateurs. They're very serious space professionals. This image here is kind of cool. It's a mock-up of the proposed version, the current version of the lunar lander, the descent stage for their Google Lunarex Prize entry. So the Google Lunarex Prize, I'm sure many of you have probably heard of it, maybe not everyone, the Google Lunarex Prize is a $20 million prize funded by Google for a private non-national entity to put a spacecraft on the moon and drive around a rover and transmit back video and multimedia images. This was basically built on the success of the Ansari X Prize. The Ansari X Prize said, you get the prize if you go into space as a non-government entity. And so it was done. And so they decided, well, we need to up the ante a bit and do it again. And so we have the Google Lunarex Prize for going to the moon. Another thing that we're working on that I mentioned I touched on earlier is just building a radar altimeter because you need a radar altimeter to land on the moon. What we're looking at is probably a C-band radar altimeter, about 4.3 gigahertz, basic kind of heterodyne thing where you make a sweep of frequency through a Vessio when you add signal back and you read how much phase shift you get, that sort of thing. There's no hardware that you can get off the shelf to do radar that will work on the moon because in theory, like it's surprising, but in practice, in practice you actually can't because you need quite a high altitude range. You also need fairly high precision. So one way to do it is basically to build your own. Being at 4.3 gigahertz, you do need a bit of microwave magic in your electronics. So when you design the circuit boards and stuff, it's real black magic stuff. Usually you're working with Illumina or Teflon or something as your dielectric PCB substrate and you're usually working with micro strips and all that kind of really nasty complicated stuff. It's doable, but it's just fun to do. Some of you may have seen, maybe not everyone, but some of you may have seen, chat by the name of Vidmar from Europe, very, very interesting guy, a microwave hacking guru who tends to put up all this stuff online as open as you can. And this is very, very cool. This is a radar altimeter that was built for a light plane, just built from scratch. And it's a C-band, actually a C-band 4.3 gigahertz device. And it's very good to illustrate the basic architecture because this basic architecture is very, very similar. As I said, it's kind of, you go to start the new engineering project. The first thing I do is Google for someone else's prior art to just get a feel for what else is out there. Very, very similar to what I had in mind. Heterodyne system. You can see that gray, ugly looking PCB. That's Teflon. And you can see the VCO and the, all that type of thing is the IF stage there is built using micro strip architecture, surface mount, gallium arsenide, I think, high-electromability transistors because you need the transistors to be able to work at four or five gigahertz. So they're a little bit specialized. But that gives you a very kind of rough idea of the sort of thing that's sort of similar to what we may end up with in practice. Ours will be a bit different because it will need to have, probably have slightly different sweep frequencies. And we may do things like the ramp oscillator waveform might be digitally synthesized inside a microcontroller. But that's the same kind of deal that we'd be looking at for a radar altimeter. A bit of RF hacking on the RF digital signal processing inside a microcontroller, an arm chip, or a Linux machine or something. In case you're wondering, there is a bit of Linux involved in these projects. For example, the central main flight computer on OSRock 2.5 will be an embedded Linux machine. I'm not really sure, we're not really sure what kind of embedded Linux machine it'll be at this stage because we're probably gonna want something with can transceivers, preferably a couple of hardware can transceivers. And I'm not sure what's out there at this stage. Another thing I mentioned before that we're working on is video compression. This is not an area where I've been focused primarily. A lot of the work in this has been done by Lee Beg over in New Zealand. What we're looking at here is JPEG 2000 and JPEG 2000 to give us very good compression ratios on the fly, high speed to give us high definition multimedia transmitted over a potentially imperfect and potentially quite bad with limited RF connection. For example, on the moon. This will require a moderately powerful embedded computer running Linux on the spacecraft. You're not gonna do this on an 8051 or a Picker or AVR or something. It may require something like, I don't know, a Beagle board, maybe black fin, maybe not really sure. But again, especially since it's on the moon that hardware is gonna need to be integrated with the rest of the lunar land with white label space, it's gonna have to be thermally qualified, vibration qualified, radiation qualified, that sort of thing. And those kinds of things, in particular things like qualifying for ionizing radiation, it kind of gets harder to do that as you scale up the transit integration density on the chip. So the more powerful your hardware is because the transistors are smaller, the transits gates have less capacitance. You're more vulnerable to like cosmic rays flipping your bits and all that sort of thing. So it can be a bit of a challenge to qualify those things. I will skip over that and go to my appendix slides now. How are we for time? Okay, so it's true when you're looking at thermal qualification, vibration qualification, extreme cold, radiation damage, that sort of thing. It's true that you do have to think about your engineering. You can't just take any old electronics that you normally use for your electronics designs back on earth, take that, put it on the moon and expect it to work flawlessly without any testing. You do need to think about your engineering, but at the same time, it's not true to say that you can't go anywhere near space if you're not spending 100,000 bucks on a mill spec, officially rat-hardened, safe to put men in space kind of processor. You can use commodity hardware in space. You just need to think a bit about the designs you might tend to. There's nothing magical about space. It's not this thing that's just supernaturally dangerous to your electronics, to your systems. It's not just going to fry everything. You do need to kind of think about your design and maybe, like for example, you might tend to avoid very high transistor integration density and maybe go for an 8051 or go for something that's a little bit older, a little bit, the transistors are a little bit bigger, that sort of thing. For example, with regards to space radiation, damaging your chips and stuff, we know exactly how much radiation flux you're gonna get if you fly from the Earth to the Moon. For example, when we actually put guys on the Moon in the 1970s, 1960s, they had dosimeters. We know exactly how much radiation dose they got. We can plan for it, we can test it. We have a pretty good understanding of what's going on. So it's not a deal breaker for us. Transistor integration density, as I said, the lower your transistor integration density is that the less significant your radiation effects are on the chips. So ironically, this kind of issue was actually less of a problem in the Apollo era than it is today, because today we have millions of transistors on a chip and when we put men on the Moon in 1969, we had integrated circuits with a transistor count of six. Those are the chips that the Apollo guidance computer was built out of and six transistors, not 60 million, six transistors in one IC. And this was the cutting edge stuff, no expense. FPGA is also really cool for this kind of thing because you can build a radiation tolerant device just by configuring the software core that goes into the FPGA. You can design in redundancy, you can design in multiple redundant cores, all that sort of thing. There was a project done by the US government a few years ago by LA&L where they actually built a satellite which one of its purposes was to validate the use of commercial off-the-shelf Xilinx FPGAs in a space environment in a satellite and they found that it worked really well with their software FPGA cores designed for that use case. So that gives you another option potentially very useful for doing electronics, video processing, whatever you wanna do. If you can put it into the HDL and synthesize it into an FPGA core, then you have a lot of flexibility there. I'm gonna wind it up a little bit early and I'll just leave a bit more time for questions, I think, so we can focus on the things that the audience wants to focus on. So I'll take lots of questions, thank you. It's been some time since NASA was on the moon. Have they released any of the technology or open sourced, any of the technology that they developed for the lunar lander and for that mission so that people can build upon that? Yeah, that's a good question. I don't really think any of it has been open sourced. I think there's a lot more potentially available for other countries, for example, a few years ago. India deployed the Chandra 1 moon probe that landed on, sorry, that's the one I was thinking of, and their descent radar was actually apparently made available to white-label space and lunar number. So we're getting access to technology that was developed by India, but not so much, say, from the United States. And I guess it would be nice to see governments opening up some of their technology, especially if they're not using it, for example. If NASA is not doing anything with the moon, it would be kind of nice if they would help private space 2.0 kind of enterprises with some of their development, but I'm not really sure how much of that would go on. I guess if they did open Apollo-era technology, it wouldn't really be that much of a use to anyone, anyway, would it? Because it's so very different to the way we engineer things today, because obviously with digital electronics and so forth, things change so fast. That's basically all I have to say on that, thanks for the question. You mentioned that the rocket you've been testing with was about Mark 2.5 or so, and I think low Earth orbit is around Mark 25 or something. So do you anticipate that being the next thing that you start testing with, like that order of magnitude, higher speeds to test your equipment with? Yeah, so there will definitely be small steps. So the rockets that we have access to at the moment are nowhere near capable of reaching space and reaching the kinds of velocities that you would associate with going into space, but they're a good step up from your amateur hobby, solid-fueled rockets. So they're a good step, and in future there will be bigger steps, certainly. I might just correct that. It's not that the rockets aren't capable of delivering a payload to space, it's they're not capable of delivering to orbit. Why, or in Australia, and where the only country which has it, space begins at 100 kilometers. It's relatively easy to deliver a ballistic trajectory payload to 100 kilometers. However, that's a very long way from delivering a payload to orbit. So sending something into space is easy, keeping it there is a lot harder. Right, yeah. So for example, with putting a payload into space above the 100 kilometer line, we saw that done with the Ansari X Prize. That's putting a payload, putting a person into space, and then coming back down again in a ballistic flight. So as you said, definitely true. It's a completely different thing to go into orbit. Yeah, the stuff you are playing with has a potential dual use, and there is the missile non-proliferation treaty around. And years ago, there was a crazy New Zealander who wanted to build an open source cruise missile. And he started, and he got the engine going, and then he got the detailed tax audit, and I think he's in jail now or something. Thank you guys, Chris. Yeah, I did catch all that, but I think just at the end, when you've finished speaking, I think you may have lost the microphone earlier, but it's not a big deal. I did hear everything that you said. Yeah, so that's certainly a good point. And working with Ansari, one of the key things that they do in their charter, in everything that they do, is to abide by anything the government needs from them. Any obligations that we have in Australia with regards to, for example, the missile technology control regime, any of those things, we need to obey what the law says, work with the governments, do everything by the book. For example, if you want a GPS module that is not exempt from export controls, that is not locked out above 60,000 feet, you need to end use declarations, you need lots of paperwork and stuff to get access. To that sort of thing. But certainly, Ansari has good relationships already with the Australian government, the Department of Defense, because they're using defense surplus, so on fuel rocket motors, or the Oslo Rock program, that all the launches are done over at the warmer, instrumented range in South Australia. So they have range user permits and they have good links to the Australian government and to defense. And we try and preserve those relationships in a positive, legitimate way and make sure that no one's ever stepping over the line ethically. And if there's something that we really shouldn't be proliferating, then we should not proliferate it and not open it. But then again, if you think that Iran or North Korea or somebody does not have good physicists and good engineers and good scientists, you're deluding yourself. So to be honest, when it comes to talking about proliferation of missiles or nuclear bombs or whatever, it's the wrong way to go about that to say we should ban talking about science and technology. I think trying to suppress technology and science is the wrong way to do it and we need to create a society or create a world really where people just don't want to get into wars with each other. But certainly, that's what I think personally, but certainly we try and play ball with the government and do what they need us to do. Regarding its suitability for spacecraft, why Canbus? Why Canbus? Canbus has a long history of being used in, for example, in cars, connecting together all the embedded devices inside your car and your 20 different embedded computers or whatever it is in a modern typical car. Just for an example, it's widely used. It's fairly electromagnetically tolerant. It's fairly fault tolerant. It's a multi-drop bus. For example, in Iraq 2.5, with ADCs, pressure sensors, strain gauges and stuff throughout the body of the rocket, you've got the pyro-technics module that separates the nose cone when the parachute comes out. That's interfaced on Canbus in theory. There will be an independent Canbus just for the pyros, I think. A few things you could use. You could use RS-485. You could use Ethernet. You could use Can. There are lots of things that you maybe could use, but Can seemed like a pretty good choice. And when we saw the work that had been done in the AMSA community with Can, that reinforced to me personally the worthiness of Can as a seemingly good choice. Sorry. It sounds like a reasonable choice in terms of a protocol, but its reliability is order of magnitude below the reliability of, say, a relay and some wires. You don't get comms errors on relays. Yeah. Reading sensor data, communicating bidirectionally to these peripheral devices, I mean, I guess we just need more complexity than what we get from relays. For example, to position the servo valve, I mean, I guess you could do it if you wanted to run a whole bunch of wires down the body of the rocket. In fact, that's probably one of the best reasons why we're using Can and not just wiring up straight to the main central flight computer is because weight in this kind of technology is very important and Can just gives us a few wires in the wiring room instead of dozens and dozens. Have you tried, because you've got a number of these rockets from the Defence Department, they're no longer in use, have you tried strapping multiple of them together? Clustering Zuni rocket motors, I don't think it has ever been tried. I think if Asri ever wanted to try that, they would probably have to go through a whole bunch of paperwork with DoD just to validate that as a launch configuration and make sure it's not going to kill anybody. G'day. Just wondering, what is the Can software that's put on interface that's on the microcontrollers? The pieces of software that you put on the microcontrollers that does the interfacing? It's just a bit of code written on the AVR. In this case, hang on. Let's see if we can bring that back. There is a bit of code running on that AVR which is talking over SPOI to the MCP2515 Can transceiver which talks to the Can. Fairly simple stuff. It's basically just as per the MCP2515 data sheet. It's all the high-level Can stuff is sort of hidden inside the microchip chipset for Can. That's sort of why we're using it. There are actually two chips there. There is the Can transceiver and there is the Can interface to the differential pair line interface thingy. Have you looked at... I noticed that you're still launching rockets from the ground. You looked at, say, launching them from a high-altitude balloon instead to get it out of the atmosphere as it's the atmosphere that always seems to be more of the problem. Yeah, I mean, I know some amateur rocketry enthusiasts have tried to before the so-called rockooning, or whatever they call it, where you launch the rocket off the balloon. I'm not 100% sure how well that scales as you scale up the size of the rocket. You can certainly do it with smaller amateur-seller fuel rockets, but I'm just wondering how well it will scale up for bigger rockets, like, how big does the balloon need to be to lift the thing? Would it be safe? For example, with a liquid-fuelled rocket, it's probably going to explode. I'm not really sure at this stage I haven't really studied that and I think it would be a difficult process to sort of study that idea and validate it. But not to say that I never would think about it. I'm curious to look more into it. One more question and we might have to wrap it up and you might be able to talk to Luke afterwards. Any time this week. No worries. One point I was just going to make about, some people were asking about the reliability of CAN bus. This has been pointed out. You use quite predominantly in the automotive industry. One advantage it's got over things such as Ethernet is you've got guaranteed priority assignments so that different controllers, if too, try to talk at the same time, CAN bus more or less will ensure that the higher priority traffic goes through underlaid, whereas the other controller will sit back and wait and that would be a key feature in this. Well, I do wonder about the MCP 2515's reliability I've had some bad experiences with it in the past. That's probably you might explain to a few others why that sort of bus is used. That's a very good point about CAN. One of the reasons why CAN is really good. For example, in the automotive industry, when the brakes want to talk to the ECU, they can definitely have their message priority set higher than the messages from the stereo or something, which is kind of important. You don't want the stereo to override the braking or something on the CAN bus. But yeah, that's one of the key features of CAN is each message from each device on the bus carries with it a priority. And so different devices on the bus can be assigned to different levels of priority and that gets respected by all the devices. Let's all thank Luke and here is a gift from Luke and here is a gift from Luke and here is a gift from Luke and he is from 2011.