Model Boat Mayhem
Technical, Techniques, Hints, and Tips => Microprocessor control => Topic started by: dreadnought72 on January 02, 2017, 01:15:27 am
-
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.
-
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:
-
Watching with great interest!
-
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 :-))
-
Ouch - the Mayhem text editor, when used with copy & pasted plain text written elsewhere, really hates me. It was formatted OK when it left!
Not sure what was going on there, the formatting code was all still in place?!? :embarrassed:
-
Same thing happened to me Martin when I posted my pseudo code spec.
Good specification Andy. We will be watching you and your fellow Arduainites with interest.
Colin
-
The hardware:
MICROPROCESSOR
I'm going to be using an Arduino Mega 2560 (https://www.arduino.cc/en/Main/arduinoBoardMega2560). Mostly because it's what I've got. It is currently just under £30 from Maplins, while compatible models are around a tenner online.
It comes with 54 digital I/O pins, 16 analogue inputs, and particularly enjoys PWM inputs. All this is good.
For testing, I'm running it off a USB cable from the PC to provide power and to enable me to upload edited software with ease. It has a power socket enabling it the ability to run off 6 to 20V once it's in a boat.
There's about 250KB of flash memory (plenty) and the internal clock runs at about 16MHz (more than enough).
COMPASS
I've got an MPU6050 mounted in a GY-521 breakout board (https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf). This was about £4 online, and it's powered off the Arduino.
First off, I should point out that it's not a compass. I tried a compass, and wasn't impressed, though it did tell me the kind of magnetic dip at my latitude. This device is a combined gyroscope and accelerometer each of which measure in three axes, giving us 6 degrees of freedom - enabling it to be used as a fully functional inertial measuring unit. It comes with a DMP (digital motion processor) which chews up the MPU6050 data and spits out information that we can use. And all in a 4*4*0.9mm box. In this instance, all I want to know is rotation about its vertical axis - I'll be ignoring pitch and roll and linear acceleration. I'm grossly under-utilising its abilities, but this would be the obvious go-to for people wishing to model active stabilisation systems, or just download their boat's performance around a course.
STEPPER MOTORS
I'm using six 28BYJ-48 stepper motors (http://www.datasheetspdf.com/datasheet/28BYJ-48.html) with associated ULN2003APG drivers. Under £2 each, online. (Wait a minute, Andy - you said HMS Dreadnought. That's got 5 turrets. Why six motors?) I'm using six motors so that one is dedicated to the tracking of targets - If you like, think of later capital ships with large, armoured rangefinders. They don't move like the turrets, but it'll be good to model their actions. Power for the steppers has to be independent of the Arduino. 5V is plenty.
OTHER BITS?
Breadboard, wire (lots of wire!) and some clever thinking.
Andy
-
The Other Hardware:
INPUTS
Along with data from the compass, I want to be able to send my target bearing to the ship, and to request the turrets train to that target, or return to park. For test purposes, I'll be using the box on the left. This is a rotary pot and a couple of switches, which will be read in real-time by the Arduino. Ultimately, these can be replicated by one channel and a couple of switches on a standard TX, with output from the receiver going to PWM and digital input pins on the microprocessor.
OUTPUTS
This is my mockup of the deck of Dreadnought - there are six steppers to drive five gun turrets (A, P, Q, X and Y) and the rangefinder (RF). Status for these steppers will be displayed by LEDs. There are five states:
1/ Parked
2/ Going to park
3/ Training to target
4/ On target
5/ Free to fire (you might think 4 naturally leads to 5, but, for example, while turret X may be on target when pointing aft there's a bit of superstructure in the way)
Andy
-
Great progress so far Andy. Interesting. Will those little steppers be up to driving a turret?
Looks like several battery voltages required?
-
Following with interest...
Andy are you mounting/rotating your "compass" sensor on one of the the steppers?
Regards
Jonathan
-
Hi!
Bob, there needs to be a dedicated power supply for the steppers: you can't run them directly off the Arduino, else bad things happen. The Arduino's wide voltage range means it could be run off 6 or 12V, such as the one powering the model. I suspect a small separate regulator for the steppers from the same supply would be the way to go, to keep things simple.
Jonathan, the compass will be firmly fixed to the hull. The physical 'direction' of the unit isn't important, as long as it's mounted level with the Z axis vertical. In use, it's the change of rotation around this axis that's the thing.
Andy
-
Re power supply - 5v could easily be supplied from the USB stick chargers people use for recharging their phones on the go - small and high capacity devices.
You can get 12v versions of the 28byj steppers ...
Andy - I will be interested to see how you get on with the MPU6050 - I chucked mine in the bin!
Regards
Jonathan
-
You can get 12v versions of the 28byj steppers ...
Checking the spec for the steppers I've got, they've got 5V stamped on them, while the driver board says 5-12V. These beasties get warm on 6V, I don't think I'd want to run them much higher than that.
Meanwhile ... an update!
The good news:
My inputs are talking to the code no problem. The compass is chatting away. The LCD display I thought I'd fried months ago is actually all right. And I have precise stepper control in any direction and speed I fancy which I can only describe as phenomenal. :-))
The not so good news:
To run six steppers simultaneously, I'm having to write a driver to do it. I became increasingly aware that the libraries available for an Arduino to control stepper motion are not quite suitable for this application. Great for one stepper, great for multiple steppers doing nothing else, but as I need to monitor inputs and process the compass in real time, I think I need to go for the bespoke approach. That's not a big hassle, really - the code so far is well under 10k, nowhere near the Arduino Mega's limit. There ARE boards dedicated to running multiple steppers which "ease the pain" by only needing a 'direction' and 'step' signal, but I'm going to continue down this route for the moment.
Back to tinkering!
Andy
-
Andy,
Both 5vdc and 12vdc are readily available - the stepper driver board stamped 5-12vdc will drive both.
Regards
Jonathan
-
Probably worth going for the 12V option, then, for those out to buy cheap steppers - that is, if there's really a difference under the can. ;)
Andy
-
Andy,
Probably worth going for the 12V option, then, for those out to buy cheap steppers - that is, if there's really a difference under the can. ;)
Andy
You cynic :) - you've got me wondering now...
maybe the extra lug on the 12vdc version case is an additional cooling fin for the standard 5vdc innards.
-
I will not be buying any kit at this early stage of development, but would appreciate a complete parts list (with links) when this reaches a more advanced stage. I would love a breadboard to watch seven slowly revolving turrets go through their paces. Patience {-) {-) {-)
I've not even laid the keel yet :embarrassed:
-
Here's a look at the general flow of the program.
I can 'subroutine' some chunks, but it seems pretty solid here.
Andy
(https://i.imgbox.com/cAaTdCbV.png) (http://imgbox.com/cAaTdCbV)
-
Hi, Andy and followers (and Racundra)
I am following this like a hawk - I have Arduino and a slew of steppers, and just need the time to get it all together
So, thanks for the relevant nudge. I even have the impression that I understand a lot of your wisdom
andrew
-
Andrew - a good impression to have! :-)
Things get ugly when reading the compass, and determining where a turret is in its 'safe to train' zone but there's nothing, so far, which is insurmountable. I think.
Got to get some cable, pin connectors and soldering done, come payday - I should be experimenting this weekend. :-))
Videos to follow. Hopefully!
Andy
-
Andy,
Great flow chart - haven't seen this type of thing since the 80's - this is more complex than you first think.
Looking forward to next update.
Regards
Jonathan
-
You'll no doubt note, Jonathan, that the coding will be less complex than the chart: huge swathes of it can be handled by stand-alone functions, called multiple times. (Seven turrets or five? Doesn't matter!) The benefit of the flowchart at this stage is that:
- I've got my head around what I want to see happen.
- It defines the variables I need to handle.
- It's transferable to any other programming languages.
...and that, I think, is part of my goal with this project: to help demystify microprocessors, accept them as a useful (and affordable) tool, and use them for whatever we want them to do.
I'll publish some code next.
Andy
-
Andy,
Wow what a flow chart - makes me feel a little inadequate! My programming is a little undisciplined and always happens with fingers at the keyboard rather than pen and pencil first which in the long term no doubt takes longer but adds to the frustration fun
It will be very interesting to compare our solutions at some stage - I guess we will both be interested in each other's logic/ approach and I am always up for condensing multiple lines of clumsy code into what others sometimes make a single line :)
PS When I locate the SD card for my video camera which has gone AWOL I will post some video also...
C-3PO
-
Nicely written flow chart Andy. Even I can follow (mostly) the logic.
-
Paul Freshney, MB Editor, has a correspondent with a model of USS Missouri which uses a 'Matchbox Hub' to keep his turrets pointing in the right directions. Apparently this is a device developed for model aircraft to stop their flaps getting into a flap and has been adapted for turret control. Not cheap at $69.99 but apparently has 4 outputs per unit, not clear if they can be doubled up though. Some information here:
http://www.horizonhobby.com/product/radios/radio-accessories/miscellaneous-15069--1/matchbox-servo-matching-power-system-jrpa900
Might be worth checking out although I suspect the Arduino solution could be rather cheaper - maybe?
Colin
-
Clever piece of kit - unless using sail servos you still have the 180 degree limitation.
From what I can make out it (MatchBox Servo Matching/Power System) allows 4 servo's all on the same channel and for each of the 4 servos you can configure:
- direction of rotation (reverse the RX signal)
- set end points - limit rotation
Clever piece of kit but not what is being proposed for the Andy (dreadnought72) /C-3PO solutions
Regards
Jonathan
-
Horrible restyling of post by forum software. Sorry
-
[/list]Clever piece of kit - unless using sail servos you still have the 180 degree limitation.
270 degree servos are commonly available, other values too. Its just the "standard" ones that only go 90 degrees
-
Martin, an hour of editing and tweaking later, I'm told that the 'edit' time for a post has expiredl My post is lost!! {:-{
I was trying to publish software, using the code key, and it's all gone. Is there a handy list of 'do not use' particular [] commands anywhere, 'cos I need to use 'em?
Andy, deeply frustrated.
-
Oooo! Maybe a save! ;) File saved from the depths of copy-&-paste!!! O0
A Dip Into Programming!
My previous flowchart contained a box asking "is targetBearing within turret training range?". There should be an image of this simple question below.
Hmmm. Well, that's an easy question for us, eyeballing a solution, but in programming terms it needs to be defined more completely. There's a flowchart below which details precisely how to answer this question, producing the results which are either "not in range" or "in range", for any turret. How cool is that? (Answer, not very: all questions and queries in a flowchart should result in 'answerable', logical questions.)
Off to the basics. I'm measuring all angles from the bow, clockwise (if you want to think in degrees, that's fine - though the program will gulp up stepper counts instead, still measured from zero).
What's (vaguely) interesting here is that the second flowchart doesn't care what units are being used, it's only interested in the relationship between numbers, where these numbers are measured from the bow, clockwise.
The anticlockwise limit to a training arc is defined as a variable. I'm using (the cunningly named) turretMin[ x ] for this, where 'x' is the turret number (for programmers, you'll notice that the turretMin variable is actually an array: "what's an array, Andy?" Ok. Think of a horizontal row of pigeon holes, one box for each turret, where each one is numbered by another variable called 'x'). That means turretMin[ 2 ], for example, will be the leftmost position allowed by the turret numbered 2 in our initial declaration of these variables. (Incidentally, good programming practice dictates that turret 2 will be the third turret, since we can - and should - number arrays from 0 upwards.)
Similarly, turretMax[ x ] is the clockwise limit. This is ('I see the square brackets!') another array. Finally, targetBearing is the singular angle, measured from the bow, of the target we wish to point at.
So what's happening in the expanded flowchart?
Turrets, any turrets, have two mathematical formats. Type one have a training arc which crosses the '0 degrees' boundary. That is, the left limit (turretMin) might be 220 degrees, while the right limit (turretMax) might be 140 degrees. This is the situation for turret A in the Dreadnought, and (maybe different limits, but same result) for turrets A & B in Warspite, for example.
Type two turrets have training arcs which do not cross the '0 degrees' boundary. Think of turrets P, Q, X & Y in Dreadnought. X & Y in Warspite. P, Q and X in Invincible. Their training arcs are completely outwith the 0 degrees boundary...incidentally, we can include Dreadnought's P turret as a type two, if we set a turretMax of 360 degrees.
The flowchart, in its first query, differentiates between these two formats.
Type two is forced to the right, one is to the left.
On the right side of this flowchart, we first ask "is targetBearing >= turretMin[ x ]?" and then asks "is targetBearing <= turretMax[ x ]?". If (and only if!) the answer to both these questions is 'yes', then the targetBearing lies within the training arc: it's "in range". Simple! It's a question of "Are you bigger than that AND less than that?"
To the left, the answer's a little more devious. "is targetBearing >= turretMin[ x ]?" will scope any bearing angles "above" the minimum angle to 360 degrees, and then (should this fail) will ask a further question "well then, is targetBearing <= turretMax[ x ]?", to fill in the other options. Our question now is "Are you bigger than that OR less than that?"
If (and only if!) the answer to either these last two questions is 'yes', then the targetBearing lies within the training arc: we once again get the result "in range".
The good news - while it's easy to pick our slow wetware through a flowchart, step-by-step, it actually makes it more complicated than the program. Here's how we could write the above for an Arduino, which uses a (close!) dialect of the language known as C.
targetOpportunity = FALSE; // we set a targetOpportunity variable = FALSE
if(turretMax[ x }>turretMin[ x ]){ // this is first query in flowchart
if(targetBearing>=turretMin[ x ]{ // this is the right-side 'YES' route
if(targetBearing<=turretMax[ x ]{ //
targetOpportunity = TRUE; // if 'YES' AND 'YES', therefore the target is in arc
}
}
} else { // a 'NO' to first query in flowchart: we'll go down the left-side
if(targetBearing>=turretMin[ x ]{ //
targetOpportunity = TRUE; // Above minimum? Good!
} else {
if(targetBearing<=turretMax[ x ]{
targetOpportunity = TRUE; // OR below maximum? Just as good.
}
}
}
The outcome is a TRUE of FALSE flag set for any turret.
Incidentally, "//" marks the start of any comment, and is disregarded by the microprocessor.
The above works really well, and extremely quickly.
But we could even speed it up. (... Can you see how? (Advanced Question Paper! Not obligatory!))
More soon!
Andy
-
I have not the first clue Andy but I will be interested to see the answer. The simplicity of what is written as code above belies the amount of work you and C3PO have done on this in your own zones.
A couple of future projects are very suitable for this type of technology and the cost is not prohibitive either :-))
-
Reducing a complex logic problem to a simple sequence of Boolean (yes/no) filters is producing a very elegant set of instructions. Although I have not used "C" I appreciate how it works, avoiding spurious 'break outs' (IF/THEN/GOTO) which could confuse the logic under certain conditions.
PS: I always write my replies in MS Word, then copy / paste into the Reply box. That way if anything goes wrong I still have my saved copy to start again with.
-
Finished soldering today - six steppers now attached to thecompass, LCD, LEDs, and my input devices. The next few days? Getting it all to talk to each other.
This IS going to work: personal status? Quietly confident.
Testing and video demos to follow :-))
Software afterwards.
Andy, still aiming for the end of January.
-
Hi Andy, and all. It's been quite a while since I've been on this forum. I recall your project the dreadnaught, very interesting. I thought you might be interested in my latest turret control, it's pretty basic, but I finally got it running. Uses the same 5v geared steppers you are using. An UNO and ULN2003/2803, and an LSM303 compass. It certainly doesn't have ranging etc or the other fail safes you have. Once I got the kinks out I was able to keep the steppers all synced. Cap
Here's video, hope the link works:
https://www.youtube.com/watch?v=mgtidK7LFhA (https://www.youtube.com/watch?v=mgtidK7LFhA)
-
I thought I'd mention a couple more things, I looked through your thread some more and Bob K Agincourt, all very interesting.
You might have a look at the Customstepper.h library, it has one feature that I think really allowed me to get it to work the way I wanted. It's the stepper.isDone() boolean check. If you put all your stepper movements in loops that first check that the steppers are done rotating (ie the arduino finished sending each step pulse it needed to complete the last command), the new movement won't begin, so your motors complete their movements before the new movement command. They don't loose count of where they were, although that can be done other ways, I just found it to work quite well. Also, I have read people having problems running several steppers with Customstepper.h but it works, some bug in their sketch.
I also have the primary pointing device (director) run the turrets, the director turns the full 360 or multiples, it runs off degrees 0 deadahead gotten from subtracting the current compass heading from the initial. The way it's set up, when activated, it trains on dead ahead (but that could be 90, 270, whatever, or could be input). It can be activated by a single radio channel.
The LSM303 compass module breakout works really well in my opinion, has the calibration example and the heading example with the library. It's tilt compensated, ie has magnetometer and triple axis acclerometer, it gives stable heading with random variation of usually 1 deg, up to just under 3, not too bad.
For development purposes you might try biting off a smaller amount at first, then adding the other features. All my steppers are stuck down with sculpting wax, and the turrets are stuck to the motor shafts with the same. Makes retrials after errors much faster. Of course the turrets will at some point need to be fixed and zeroed. On my larger model from a while back I had set screws on the shafts with a hole in the turret for hex driver. If small enough I'd probalby use a piece of tight fitting silicon tubing so if they get out of alignment you simply twist them back. Once you get one turret to follow the director and not exceed its field it's easy to add more, 7 not a problem.
Note that the director turrets in the video I posted has three seperate stepper circuits, the director, turrets 1 and 2 are wired directly to the same circuit, as are 3 and 4. So that requires 4x3 digital outputs that's getting close to max for an UNO. The Mega has plenty, good choice for 7 turrets :-))
I'd be happy to share how it runs if anyones interested. Cap
-
Hi Capricorn,
Nice video - looks like you have a pretty neat solution.
Not sure if you have seen it but checkout this thread - http://www.modelboatmayhem.co.uk/forum/index.php/topic,56800.0.html
And also https://login.proboards.com/login/6696601/1
Do you have any plans to add other functionality?
-
I did see the t.a.r.g.e.t. thread, I was a member on this site years ago when I was working on a 1:35 scale DD, that has functioning turrets, I conversed with Andy and some others on his dreadnaught project, probably they don't recall. But Andy was the one that suggested the compass module to me. I take rather long breaks (years) from working on my model ship, I only just got back into it a couple months ago on RCGroups, and this realy just a mini version of what I had before, with the compass added. The 1:35 scale DD has guns that elevate also via steppers.
Once I had it working well I posted the video and I searched around various sites to see what others may have similar. I saw Andys post here, seems to have stalled a while back, I can understand that, thought I'd add some new life to it.
I don't plan any additional features at the moment, not until I get a model to put it in. I was contemplating a 1/200 scale BB plastic kit, probably the Bismarck, but that is a lot of work, not sure I want to commit. What features did you have in mind, or suggest? Cap
PS what year was 1984 written, because I've googled it and I can't get past the cypher question.
-
PS what year was 1984 written, because I've googled it and I can't get past the cypher question.
A very ill (TB) George Orwell finally completed the manuscript for 1984 in December of 1948 on the Scottish Island of 'Jura' (inner Hebrides) the book was first published on 8th June 1949 in the UK.
Hope this helps.
Alex.
-
Thanks Alex, I misread the question, finally figured it out; "about what year was novel 1984 written?", duh, 1984....
-
I believe this thread should be merged with . . .
http://www.modelboatmayhem.co.uk/forum/index.php/topic,56800.0.html (http://www.modelboatmayhem.co.uk/forum/index.php/topic,56800.0.html)
Progress is being made towards a working system.
-
January, I initially said? Well, it's been a busy year. %%
But I'm off this week. And it's only Wednesday. :-))
Status? Everything is wired up. Code is flowing. Things are working. There's been a few setbacks, but I'm getting there.
Currently I'm writing error correction stuff to chuck out spurious reports from the MPU6050. There's maybe one returned a minute, at fifty calls per second. Not too bad. But none would be better.
And the imu does drift, at 360° per day, which is kind of cute. (No one is going to track a target for 24 hours!)
Oh, and there's an issue with the Arduino - the software will keel over if it's run for about two months, non-stop. Though I don't see this as a deal-breaker for general lake use. ;)
Meanwhile my cheapo steppers are throwing up their own issues - I suspect I can 'only' achieve 40-minutes-of-arc accuracy with these guys. Warning: there are several flavours of cheapo steppers available. Caveat emptor. Same can, some 12V, most 5V, and many with different gearing options. These fellas do 509 microsteps per revolution. Fine for model purposes, but there are ways (=£) to be far more accurate. At the moment, I'll nail this version before thinking ahead.
In general: I'm picking my way through the 'turning flowcharts into code' which is just time-consuming more than anything else. Add a chunk, test, add a chunk...
More later!
Andy
-
Hi Andy,
Good to see you back attacking the solution.
What steppers are you using? 28BYJ48? I have them at 2048/4096 steps per revolution - am I missing something?
- Step Angle (8-Step sequence: Internal Motor alone): 5.625° (64 steps per revolution)
- Step Angle (4-Step sequence: Internal Motor alone): 11.25° (32 steps per revolution)
- Gear Reduction ratio: 1 / 64 (Not really exact: probably 63.68395.:1 )
- SO: it takes (64*64 = 4096 steps per output shaft revolution.. In 8-step sequence.
- SO: it takes (32*64 = 2048 steps per output shaft revolution.. In 4-step sequence.
Regards
C-3PO
-
There seem to be several versions of the gearing under the can. I've been sending four steps (HLLH, HHLL, LHHL and LLHH) per subroutine-call, and get one rev through 509 calls.
Which threw me for a while: what insanity is this?
...and then it struck me. 2^8 calls is pretty much 180°. Given these steppers are made in the hundreds of thousands to control vanes in cars' blower systems, I've obviously got a set of these.
Andy
-
Andy,
If they are 28BYJ48's then I am sure you should be at 2048 steps per revolution - your HLLH etc sequence makes sense - could it be the pin sequence 1,3,2,4?
Maybe worth a try of the second sketch on this link to see if you get one revolution. "Test Sketch: Rotate 1 turn in each direction, repeat."
https://arduino-info.wikispaces.com/SmallSteppers
The common steppers have a gear box @ Gear Reduction ratio: 1 / 64 (Not really exact: probably 63.68395.:1 )
So motor 32 steps per revolution x gearbox 64 you end up with 2048 steps
The 509 just doesn't seem to make sense
C-3PO
-
Hi Andy,
I am certain you have standard steppers - The answer is eluding me - but check this out:
63.68395 x 64 = 4075.7728 ( 63.68395 x 32 = 2037.88)
4075.7728 / 8 = 509.4716 or your 509 steps per revolution. ( 2037.88/4 = 509)
I think you are full stepping not half stepping
So I think you should be stepping (HLLH, HLLL, HHLL, LHLL, LHHL , LLHL, LLHH, LLLH) - red one are additions that will give you 2048 steps per revolution
C-3PO
-
Mmm. I tried half stepping.
I'm having to add a small delay() between steps in order for the steppers to not choke on the stream of commands - just a couple of milliseconds is required.
A non-moving stepper in a sequence then needs to equate to a solid delay() equal to that of a moving turret in order to not 'speed up' those that are moving, in total meaning that (for five turrets and a r/f) the sum of delays per full step is around 40ms. At the resultant 25ish full steps a second, turret rotation is about 360° in twenty seconds, which feels about right. Half stepping would double this...and my gut reaction is it feels a bit 'slow'.
That said, these delays are set as variables, and eminently tweakable once everything's working. We'll see what balance between angular accuracy (and it's sub degree at 509 steps) and speed/'feel' look like at the end of the day.
Final point - I'm using a user-brewed stepper subroutine, so it's not impossible to adjust this to run in singular 'part' fullsteps (2038ish bits of 360 degrees) with little alteration - better accuracy, a little bit more code.
Andy
-
Hi Andy,
You are a brave man creating your own stepper driver.
Found this video online - so well presented https://www.youtube.com/watch?v=B86nqDRskVU
Check out 17:20 minutes - it clarifies it all.
I wonder how much time and money this video cost to put together! - it existence does show how widely used the 28BYJ steppers are...
C-3PO