Technical, Techniques, Hints, and Tips > Microprocessor control

Turret Rotation

(1/10) > >>

dreadnought72:
 
As promised, this thread will be the home for my attempt to create a microprocessor-based system for turret control. I'm going to kick off with a pile of text first, not least because I need to define and explain some of the basics, and my reasoning behind it all.

Over the next few weeks I'll dip into the hardware and the tech, and then we'll look at the software as it develops towards a (hopefully) all-singing, all-dancing system. If you have any (on-topic, please!) comments or questions, fire away!

A DEFINITION OF THE SYSTEM

The very basics: I want to develop a system to control the movement of turrets on a capital ship. My desire is to control the turrets on a 1/72nd scale HMS Dreadnought whose hull is still awaiting completion. Bob K re-ignited my interest in this subject with his recent acquisition of a 1/96th scale HMS Agincourt.

The system will simulate the training of turrets from a set 'parked' position,to acquire and follow a chosen bearing to a designated target, independent of any change in the capital ship's heading.The system needs to control fore and aft turrets, along with wing turrets that, in some circumstances, may have had opportunities to fire across the deck:  this will enable me to implement the system on any historical capital ship with any arrangement or number of turrets.To prevent the appearance of robotic operation, individual turrets will be equipped to have variable start times and training speeds.The ability to 'park' turrets after training, and alter the target bearing during operation, must be included.

The system must output information that allows or precludes a turret's ability to fire once 'on target', depending on the physical layout of the vessel it's implemented on.

Fire effects (smoke, noise, flash) will notbe modelled or expected, but – as a separate system – could be combined with the output to allow this. Similarly, gun elevation (typically 0-20° for WW1 equipment) will not be part of this system, nor any changes in elevation during 'reloading': all that's for the future. This system is for realistic turret motion only.
The system will rely on a microprocessor, a MEMs compass, stepper motors and a typical transmitter. Battery draw will be minimal compared to shaft power, smoke generators, etc. Total cost, excluding RC gear, is to be under £100. User control must not take up unnecessary channels.

Finally, software must be easily editable and re-definable to allow it to work on a variety of capital ships.

A QUICK LOOK AT TIME

Model ships generate correct wakes in water following a formula well-known to modellers: scale time = time / sqrt (scale factor)
For a 1/96th scale model, scale time is just about one-tenth of real time. That is, a ship capable of 20 knots will, if built to 1/96th scale, generate a realistic wake at about 2 knots. One scale minute will pass in six real seconds. Back in the days when models were used in film-making, cameras would be overclocked by the inverse of the scale time to produce (more or less!) realistic motion when slowed down on screen.

As capital ship turrets of the WW1 era could typically train from three to five degrees per second (½ to 5/6 rpm) the system should, if following the above, be capable of rotating turrets at around thirty to fifty degrees per second (5 to 8 1/3 rpm). However, motion that is 'too fast' on a model, while 'correct' in terms of  the maths, can look as bad as the 'robotic' element of pure, unadulterated, digital stepper motion that the system is anxious to avoid. As a result a compromise is needed: a top training speed of 4 rpm appears to be suitable, both at 1/72nd and 1/96th scales.

One last comment on time! Microprocessors are just small computers; but even so, they have blisteringly fast clock speeds and can handle enormous amounts of data extremely quickly.
Programs written for them typically use loops to minimise code and increase efficiency.
Human senses are not so fast. To provide an illusion of smooth motion to the eye, especially when using stepper motors with digital jumps between angles, the system is expected to run its main loop a few hundred times a second. Fast enough to trick the viewer, easily slow enough to chew on the maths. We'll see!

A THEORY OF RELATIVITY!

Imagine a boat containing rotatable turrets which are pointing at a bearing in a lake. The bearing can change. The boat might alter course. The turrets can move. There's an obvious need to define a fixedframe of reference which will enable us to convert between these various (and variable) angles quickly and easily.
Mathematically, any frame of reference is as good as any other. Practically, it's a different matter.
At first glance, as we're relying on the output of a compass, it might be thought that the lake, being static, is the best choice. Surely everything is relative to that?
Or perhaps taking the point of view of a turret could work: let's face it (!) there's little more obvious to us than thinking we need to turn left or right to point at a particular target.

Both these systems have some benefits and would work, but – after a lot of thought – it's become clear to me that the primary frame of reference should be that of the boat: our target bearing should be set relative to the boat at some time-zero (T0), say 'port 30', and should measure heading changes of the vessel to calculate and reflect a new target bearing at any future time, Tn, perhaps by now 'starboard 80'.
As our turrets' training limits and parking positions are intrinsically defined relative to the boat, along with our turrets' current training angles, it's trivial to work out where the ship-relative target bearing lies in relation to individual turrets, and therefore we can easily calculate the direction of rotation and the required rotational angle to acquire that target bearing.
That sentence is possibly the worst I've ever written. If you're interested in this thread, and want to understand what will eventually be happening 'under the bonnet' later on, it's maybe worth re-reading.

In essence, the chosen frame of reference is identical to those men in a spotting-top with binoculars, shouting down voice-tubes. In the maths that will follow, the hull is the thing.Work will take me out of the loop for a few days - I'll be back later in the week. With pictures.

dreadnought72:
Ouch - the Mayhem text editor, when used with copy & pasted plain text written elsewhere, really hates me. It was formatted ok when it left!  :embarrassed:

srcampb:
Watching with great interest!

Bob K:
Very succinctly written Andy, and in the wee hours too.  At this rate I can envisage bread-boarding stepper motors and controls long before I am able to mount turrets in my new project.  IMO the realistic deployment of turret movements has been an aspect of model making that has long been waiting for such an elegant solution.  Just imagine having a period warship on your lake that can replicate this in real time.  A slight change of course, and the gun bearings change to follow the "target".  It will look awesome on the water  :-))

Martin (Admin):

--- Quote from: dreadnought72 on January 02, 2017, 01:17:47 am ---Ouch - the Mayhem text editor, when used with copy & pasted plain text written elsewhere, really hates me. It was formatted OK when it left!

--- End quote ---

Not sure what was going on there, the formatting code was all still in place?!?  :embarrassed:

Navigation

[0] Message Index

[#] Next page