Tubes: A Way Forward?

I've been thinking about chamber and nozzle design a good deal recently. My motivation was to try to come up with a different method of fabricating a thrust chamber. A method that doesn't involve machining the chamber and nozzle from solid, which I've always thought was wasteful. That said, it certainly works. A superlative example is Anders Johansson's long running thread at the Jet and Turbine Owners Forum:-

 http://jetandturbineowners.proboards.com/thread/49/n2o-ethanol-bipropellant-rocket-engine?page=1

So I just wanted to try something different, to see what was possible. You'll remember from my post on cooling that I posited a notional tube bundle chamber for my calculations. What if it wasn't purely notional? I decided to see what it would take to build a tube bundle thrust chamber.

My initial thoughts were based around bending the tubes to shape and stacking them together around a circular manifold, possibly using some sort of temporary centralising mandrel or jig. The idea was to braze the tubes, but my attempts at brazing did not go very well. I had much more luck TIG welding them. After a few false starts to get the TIG parameters right I produced a reasonable weld:-

I didn't use any backing gas here and got away with it; in a production unit I would have to set up an internal argon shielding flow in the tubes. However, cheered by this result I next looked at methods of manifolding the tubes and anchoring them to a manifold. Using 10mm dia. 2mm thick wall metric hydraulic tubing meant it was possible to turn down a portion of the tube to 8mm:-

I used a collet to hold the tube, as seen. Next I envisaged the manifold ring to have a series of holes on a PCD, into which the tubes would be welded. I decided to make a rough mock up of such an arrangement using just two tubes, to see how they sat together and generally get a feel for the problem.

I took a square block of mild steel and cleaned it up in the 4 jaw chuck. I then drilled two holes in it of the correct size and pitch for the tubes. I countersunk one end of these holes. This would mate with the chamfer on the tubes so they'd sit flush to the block/manifold. The four pictures below show cleaning up the block faces, drilling the holes, the countersunk portions and the tube/block fit up.

Centre drills are very rigid and are great for starting drilled holes (as well as for creating centres!):-

The countersunk ends of the holes:-

And the tube to block fit up:-

Ideally the hole for the tube on the right should have been countersunk fractionally deeper, but you get the idea. The number of required holes and the PCD they'd need to be on for the diameter of the projected chamber would put them closer together than shown here. The gap between the tubes in this mock up is about 0.25mm. The number of tubes and the PCD required for the chamber I have in mind would put this gap at just over 0.05mm. I might need to play with the diameter a little to get an adequate gap for the welding. This would also feed into the tube bending calculations to ensure that the throat diameter was correct.

Here is a close up of the machined end of one of the tubes. The chamfer is 45 degrees and this then mates nicely into the 90 degree countersink:-

The dimension from the start of the chamfer to the tube end is 20mm. Finally, here is a photograph of the opposite side of the block showing the tube exits. In the design under consideration this is where the fuel/coolant would exit and cross over to go down the next tube. I machined the block thickness to 20mm so that the ends of the tube would be flush with it. The holes would need to have a countersink to correspond with a chamfer on the tube end to get a nice weld. I tried to do this by hand on one of the holes and made a pig's ear of it; why is it always the last operation that wrecks your part?! Anyway, it isn't too much of a worry and I think you can see what I'm trying to achieve.

I'm back at work now so there will be no more practical updates for a few weeks. You might be lucky though and get a lot of meandering nonsense with some highly suspect calculations thrown in. I bet you can't wait.

Telemetry

In between calculations and doing development work on the engine itself, I have been looking at what will be required for the power and telemetry set up on the test bed.

I've built a few data acquisition and control systems, mostly centred on either the Basic Stamp or PIC type microcontrollers. Over the years I have formulated a set of guidelines to assist rapid system prototyping. These are as follows:-

Accretion

Each part of the design problem is broken down into manageable portions. The sub-assemblies produced are then combined to form a coherent whole.

Recycling

In 2002 the DEER report stated that due to rapid advances in component design, leading to rapid obsolescence, component recycling will be necessary in the future for repair of in service equipment.

Indeed, nowadays most electronic equipment is simply thrown away when it reaches the end of its useful life, containing hundreds of perfectly serviceable, usable components. These components can and should be re-used when possible.

Heterogeneous Architecture

This approach to control system design was first enunciated by Whitcomb and Yoerger, of Woods Hole Oceanographic Institute, in their 1993 paper on the Jason MK2 ROV. They argue that most control systems can be split into at least two computational subsystems, namely user interface and control.

The heterogeneous approach attempts to speed up system development by using standard, off the shelf hardware and software for generic system functions: -

“A better alternative for medium and large-scale fast-track development is to embrace heterogeneous architecture at the outset. Use general purpose machines for commonplace tasks such as user-interface and logging, use dedicated real-time machines for control.”

The case is made for the use of commercially available machines and software wherever possible. Whitcomb and Yoerger conclude that: -

“The metric of success in fast-track development is not the uniformity of design, but its rapid and successful implementation.”

Dr. AM Turing

Dr. Turing’s paper "Intelligent Machines" (King's College, Cambridge, 1947) is now widely regarded to have been the first introduction of the software control concept. Turing argued that software based control could produce an extremely flexible system in which very few hardware alterations would be required. Rewriting software would accommodate any problem that arose, or changes in operating parameters.

The basic design of the test bed control and data acquisition system will be guided by these principles. Use will be made of as many standard, readily available components, communication protocols and sub-systems as possible.

With the above in mind I decided to go with a laptop running a GUI that would then interface with a microcontroller based I/O card at the test bed end. Rather than build my own microcontroller board, I went for a kit solution in the form of the Velleman K8061 USB I/O card. The specification of this card is as follows:-

8 analogue 10 bit resolution inputs: 0…5 or 10VDC / 20kohm

8 analogue 8 bit resolution outputs: 0…5V or 10VDC / 47ohm

8 digital inputs: open collector compatible (connection to GND=0) with on board LED indication

8 digital open collector outputs (max. 50V/100mA) with on board LED indication

One 10 bit PWM output: 0 to 100% open collector output (max 100mA / 40V) with on board LED indication.

General response time: 4ms per command

USB Port: 2.0 and 1.1 compatible (USB cable included)

Further details may be found at www.velleman.eu

As can be seen the K8061 card has a fairly impressive analogue and digital I/O capacity. It took me an afternoon to build and test, using Velleman's own free diagnostic software. This was significantly quicker than had I programmed and debugged my own PIC based board. Here is a photograph of the completed board:-

The long narrow IC to the left of centre at the top of the board is the pre-programmed PIC that handles the USB communication to the laptop. The long wide IC below this is the second pre-programmed PIC that deals with all of the analogue and digital I/O.

The communication routines for the K8061 are contained in a DLL which the user is given access to. This enables custom control applications to be written in a variety of languages. That said, one of my chief reasons for wanting to use the K8061 was my choice of Profilab to develop the GUI on the laptop.

Profilab is a graphical programming language for the development of control systems. It is somewhat similar to NI LabVIEW. In the Profilab hardware library there is a module for communicating with and controlling the K8061. You can read more about this software at www.abacom-online.de/uk

My first step was to attempt to interface one of my K type thermocouples to the K8061 and obtain a temperature readout in Profilab. Initially I was going to design and build my own thermocouple pre-amplifier, based on the AD8495 IC. Whilst researching this I found another excellent kit designed and produced by Dr. Matthew Little of re-innovation, here in the United Kingdom. More can be found at www.re-innovation.co.uk The construction was straightforward, although I had to solder the tiny SMD AD8495's to the PCB by hand, something I'd never attempted before. Fortunately I quickly got the hang of "drag soldering".

I got four of these boards, here is a photograph of a completed one:-

You can see where this is going; any electronics design and construction I would do myself would be restricted to signal conditioning and driver circuitry. This is where the recycling aspect would come in as I have literally thousands of components in my workshop to use up!

I had to connect the thermocouple and AD8495 board to the K8061 via an op-amp buffer due to the relatively low input impedance of the K8061. I used an LM324. It has the great advantage of not requiring a split supply.

Here is a photograph of the test set up. The K type thermocouple is connected to the AD8495 board and thence through the LM324 buffer on the breadboard to the K8061:-

And here is a screenshot of Profilab displaying the temperature in my electronics lab (which my wife continues to refer to as the dining room):-

Now, you are all probably thinking, quite rightly, that a safe distance ought to be maintained between an untested homebuilt rocket motor and it's tester. And you'd be right. Of course, USB only has a range of 3-5 metres....but as Baldrick used to say "I have a cunning plan...." All will be revealed. That is, if I can do it...