Wednesday, 25 March 2015

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:-

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.

Thursday, 12 March 2015

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.

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...

About this blog

This blog describes the research, design and construction of a Liquid Rocket Engine.
As such it will include information regarding the design and construction of rocket engine components.
This will encompass theoretical and performance concerns, as well as machining, welding and manufacturing techniques used to overcome the various problems encountered.
In addition, my interests in this direction include control and data acquisition. So there will be posts regarding electronic systems and microcontrollers.
It is my hope that as well as being of interest to the rocket engine community, it should also become a repository of general amateur engineering information.
I was inspired to create a blog by the groundswell of interest that I have had in my project from people I have met. I have found that their reactions tend to go from perplexity to enthusiasm rapidly! The main question most people have is not to do with the technical obstacle to be overcome. Most of those who have asked me about my project have wanted to know "Why are you doing this?" So I will try to give some answers to this and to explore my motivation to think, research, create and construct.