Let's look at a real-world example, based on some of the requirements gathered so far. One of the user interfaces required is a set of preset bearing buttons, as described below: Let's see how we might make this work. For now, let's just focus on the user interface. That means that the radio system, targeting algorithm ("Core"), weapon controllers, etc. are going to be ignored for now (assume that they're in place & working). This diagram illustrates the basic system & how the parts fit together: Visit this site Here's basically what we need to do to make this type of Interface Module work: - Recognize button presses - Set the target bearing depending on which button was pressed - When asked, provide target information in the 3-part form of This will involve producing 2 messages. will always be 0, will need to indicate whether it's Range or Bearing, & will be whatever it needs to be. There are a few questions that we need to answer. In particular, we need to finalize the communication definition that I proposed in an earlier post. For the moment, let's leave that alone. The 3 elements, however, we can deal with. "Target" will always be '0' if we're assuming a single target. If we want to build so that multiple modules can be included, each to define a different target, then we'll need to set up a mechanism to define which target this module is for. This can be done with a pair of switches or jumpers, & isn't going to be terribly difficult. It will eat a couple of general-purpose I/O pins on our controller, so we'll need to plan for that. "Bearing", we'll get from the buttons. For now, let's use a pair of numbers for : '1' means Range, '2' means Bearing. This requirement doesn't specify how to define "Range", so we'll need to come up with something. For now, we can just plan for fixed-elevation guns, so "Range" can be set to a default. We'll still send it when asked, it'll just never change. If the module gets updated later, to include a range-setting input, this will be fairly easy to add. How many buttons do we want, & what bearings should they represent? The requirement says we need 16 buttons, 4 in each quadrant. Note that, in the requirement, they're not evenly spaced. That really should have some further definition. It might not be a bad idea for somebody to build a mock-up, just to see what works well in the hand. How many are enough? How many are too many? A little plastic Radio Shack project box should do the trick, plus a number of pushbutton switches. For the 1st try, maybe just stick some adhesive "dots" onto the box, to avoid having to drill holes & ruin it. When it seems about right, then go ahead & drill. For now, let's figure on 16 bearing-indicating buttons, at TBD locations. We've already talked about a "global" definition of the space around a ship in terms of Bearing to Target, as a number from 0-255, with '0' being directly ahead & "degrees" increasing clockwise. This gives us specific numbers that we can assign to each button. It' pretty simple, then, to hook up each button to a microcontroller pin & "read" when each is pressed & assign the appropriate value to a variable. One problem, though: That's an awful lot of pins! 16 pins just for the buttons, plus we'll need at least 3 for communication with the radio. Range, firing buttons, & anything else that we might need later are going to take even more. That's going to be a big uC, & cuts down our choices considerably. Also, doesn't it seem like a waste, to have 16 pins just sitting there waiting for a button-press, when there's only ever going to be 1 button pressed at a time, & then only briefly with most time spent with nothing pressed at all? Remember, in a prior post, when I said that the shift register would become your best friend? Well, here's the time when it's good to have a friend that can give us some I/O pins back. Shift registers basically come in 2 types: Serial In/Parallel Out (SIPO) & Parallel In/Serial Out (PISO). The 2nd type is what we're interested in here. A PISO shift register will take some number of parallel inputs & shift them serially out onto a single-pin output. What this means for us here is that our 16 buttons can be hooked up to the parallel inputs of 2 8-bit PISO shift registers instead of 16 pins of our uC. When our uC program needs to "read" the switches, it just asks the shift registers. Each shift register uses just a single pin to send its data serially. Instead of using 16 uC I/Os, plus 3 for the radio I/F, all of the devices can share common "data" & "clock" leads. Only the "select/enable" needs to be unique for each. This will only take 5 pins on the uC, instead of 19! The uC, when it reads the switch values from the shift registers, needs only to put that data into the previously-defined sequence, then send it serially to the radio interface. That's it! It just loops around, endlessly, doing that simple set of tasks. I've put a basic flow chart into the Fire Control folder. Other questions to consider in the basic design: - How do you want to handle multiple button-presses? That's going to happen, & we need to decide how to deal with it. We could take an average of the values. We could sample bits, LSB-to-GSB (or GSB-to-LSB) & just go with the 1st set bit we happen to get. We could also ignore it altogether, & just keep the last "good" value. There are probably other ideas, too - we just need to settle on SOMETHING. - We'll need to set a default initial value. When the system 1st comes up, until some button gets pressed, there will need to be SOME value set. What should it be? Not a tough question, but one that needs an answer. - How quick of a button-press do we need to be able to detect? We probably want the buttons to stay down for some minimum (but still pretty short) amount of time, before we decide that it's a "good" press. How long is that? Here's a good basic familiarity project for somebody: Experiment with a uC & momentary pushbutton switch, to see how short is too short, how long is long enough? - What if a button is pressed at the "wrong" time, when the uC/shift register isn't ready for it? That's very likely to happen, just like multiple presses. There's no way that we can always be ready, unless we use interrupts on the buttons, & good luck finding ANY uC with 16 interrupts! I suppose somebody could figure out a clever way to multiplex 16 buttons onto a single interrupt, but I think that might get a little messy anyway. My suggestion would be to use latches. Latches hold a signal active, even after the input has gone away. Sometimes, inputs or outputs on a device (like a shift register) are latching. The only latching shift registers that I know of are SIPO, but that doesn't mean that there aren't any latching PISO shift registers available. Even if there aren't, we could connect an octal latch between the switches & shift registers, t hold the signals active even after the switch is released, until the system is ready to read it. Latches need to be reset (some reset automatically when read), which may take another uC pin, worst-case. So, there's enough information for somebody to actually start building one of the modules of a fire control system! Add up the I/Os - we won't need any interrupts, no A/D, etc. so there should be a lot of uCs to choose from. Find sources for the other components - they're all common & cheap (switches should be the largest expense). You'll probably also want to build a "tester/simulator" to take the part of the "Core" in terms of communication. You should be able to press a button on the input module & see the correct number show up in the tester/simulator somehow. That's really all there is to it, at least for this particular module. What a "Core" might do with that data is for future work, but for now we can actually generate some basic targeting data! That's a pretty big step toward getting this project done! Questions? Who wants to volunteer to build one? JM
OK I know this isn't a direct reply to your most recent post, but I'd like to add something to our list of objectives. So this evening I was building boats with some friends, and during the bull session we got to talking about the WWCC's most recent campaign battle. The Axis fleet stomped all over the Allies by using coordinated torpedo attacks and breaking the Allies' will to fight. My buddies and I all fought for the Axis, but we started talking what the Allies could have done to change the results. We agreed that two things could have changed the outcome: All the allied battleships sailing at the same time, and using tight, coordinated formations to fend off the torpedo-cruiser attacks. I thought about this a bit, and remembered how hard it is to do tight formation sailing WITHOUT having to track multiple high-speed opponents and accurately shoot them down. I then wondered if some sort of autopilot formation control could be used to make formation sailing easier. So here's the new addition: Formation Control Autopilot 1) identify your own position relative to a designated flagship 2) adjust throttle and rudder to maintain position relative to the designated flagship 3) Change which ship is designated flagship, and become the flagship itself 4) (optional) adjust throttle and rudder to reach and maintain a formation-specific position relative to the designated flagship, and smoothly perform formation changes as necessary, in formations of up to 8 ships
Carl, that's some interesting stuff. I don't think it's really directly related to fire control, though. Would you mind if we started a new topic for automated formation sailing, navigation, etc. & moved it over there? JM
Anybody who plans to develop component modules is going to need some way to test them. For any Input module, like the one described above, you're going to need something that simulates at least the communication aspects of the "Core". Actual targeting algorithms aren't necessary, but you'll want some method of displaying the data sent by the Input module. If you can get it to a PC, that's probably great. If not, an LCD display might be a good option, or maybe just some LEDs. Eventually, you're going to want to test multiple units together. The following diagram illustrates a basic test/simulation setup that includes everything except the radio (dashed-out): The "Core" doesn't need to do anything complex - just pass-through is going to be enough for the time being. Same thing for the "Ship Control" module. We haven't talked about Weapon Control modules yet, but that's basically just a controller for an individual turret, torpedo, or other weapon - maybe even a spotlight or "fake" rotating director? Details are a topic for a little later. If anybody can build a tester/simulator like this, a very large portion of the system will have been pretty-well nailed! We may be closer than a lot of people think. Who's working on that multi-button Input module? I know somebody wanted the feature. We need a prototype module built, as well as enough of a Core to communicate with it & display data produced. JM
How about this: Since it might be a little out-of-scope for fire control, & really worthy of a topic on its own, how about for this project we make the requirement that we're able to interface with TBD navigation, autonomous piloting, detection, etc. systems? Think on some language that makes that clear, without going into too much detail, OK? JM
Yeah, that works. I am picturing a custom-built human interface (radio) that has the controls for maneuvering, fire control, damage control, formation controls, and status reports (ammo, gas, batteries, water level, etc) and what the "formation control" module of that would be like. This thread is solidly devoted to the fire control aspect, but establishing a general communication format that allows other modules to talk would be important.
As for 16 (or more) inputs (pins), they do not necessarily need to be on the uC. There are, indeed, parallel in serial out shift registers that can read 8 buttons and clock them out serially, requiring only 2-3 pins on the uC. Granted, it is not an interrupt type system, but if you perform reads pretty quickly, and have bounce caps in, I am thinking it would probably work pretty well. You can stack 2 74HC165's to get 16 buttons. Alternatively, you can do something that is common with Picaxes - parallel processing with multiple uC's. They are, after all, pretty cheap at $3-12. I am thinking you could can stack several of the new X1-s on an I2C buss and use the scratchpad memory to give toggle states. If you poll often enough, I don't think you will need an interrupt. I haven't looked to see how many interrupts can be used per chip yet, as this is not the path I was looking down, but it appears, on quick glance, depending on the chip, you can set up to 8 pins to perform the interrupt (not 8 separate interrupts). The X1s also have an interrupt flag that might be useful. I am thinking that for most of what we do, a poll system would be adequate. You have to press a button pretty fast to be missed, methinks. Cheers,
Maybe, maybe not. That's why I suggested that somebody (or more than 1 body, even) build a basic button-reading, familiarity-building project just to see for sure what they can or can't get away with. Anything that I know to be true is much more valuable than something I just think is probably true. The trouble with polling, in general, isn't so much the duration of the press as when the press happens. A lot depends on what else happens to be going on that isn't necessarily related to the buttons at all. Some corollary to Murphy's Law probably covers the likelihood of pressing a button at the "wrong" time, when the program isn't ready to detect it. Especially, if somebody is trying to shoehorn too much functionality into a single controller. I think it would serve anybody's interests, who wants to get something built that works well, to learn some of the nuances of how various primitive functions work. Just dealing with button-presses, there's plenty to understand that can be useful in a project like this. I'd want to get acquainted with things like: How to detect & handle a "leading edge" state transition, like when a button is 1st pressed. What's actually happening, & what can screw up? How to detect & handle a "trailing edge" state transition, like when a button is released. What's actually happening, & what can screw up? What about sampling "stable" states (i.e. "up" or "down"; "open" vs. "closed", etc.) instead of transitions? How many times to I need to sample a stable, consistent value before I should consider it valid? How many "glitches" can I tolerate in that time? Everybody needs to decide what is or isn't "good enough", & to do that they really need to understand the effects of their decisions. If some method works 90+% of the time, is that good enough for combat? Personally, I always try to find as many ways that I can that something can get screwed up. If I can identify & handle all of the errors & exceptions, whatever is left over should be the "good" case, right? JM
And then, there is the whole issue of button bounce on the switches. While it may not be an issue with other circuits, it is an issue with uCs. Interestingly, the Picaxe has switch bounce compensating routines built in with the button command. Cheers,
What other issues might somebody find, if they go looking? That's a major point of doing a button-reading, familiarity-building project. Better to find out what sort of gremlins are lurking in the shadows now, than to find oneself with a fully-developed system later, that has intermittent problems for some unknown reason(s). JM
And, with the Picaxe 08M stater pack selling for $12.95 with programming software (in BASIC), documentation, chip, programming cable, experimenter board, components, even a battery box, anyone with the inclination to try out this direction can play. Granted the 08M only has 5-IO pins, but some clever multiplexing has been explored on the Picaxe forum even with this bottom tier chip. It is the chip I am currently using in my prototype Fire Control Assistant (that uses 3 RX servo signals to derive a servo position signal) - not enough for a full fire control system, perhaps, but there are several with more oomph, and the chips run about $3-$12. In fact, for the truly frugal, the software and documentation and simulator are free for the download from Picaxe.com (rev-ed) to play with before you ever buy the chip (which you will need to do to see if it actually works with your hardware). Cheers,
Maybe, maybe not. Look back in the topic a ways. By strange coincidence, we've defined a basic communication protocol that consists of 3 elements: . It doesn't necessarily have to be 3 serial bytes; it could be transmitted over 3 R/C channels, if somebody wants to do that. You may be closer than you think. JM
For the ship-side, perhaps. For the multi-switch input that was currently under discussion, maybe a higher power ship would be in order. Actually, the direction I think I would start on the ship side is the 21 servo controller (I seem to recall it being $42). Then, whether you are sending data via serial, I2C protocol, or 3 RC channels, or a hybrid of some sort, you have the advantage of offloading the actual servo handling with the attendant timing issues. Parallel processing - a wonderful thing. [8D] Cheers,
The 3-element protocol is just a means of "packaging" data that gets "shipped" from Point A to Point B, nothing more. How's about we hold onto that thought for awhile, but don't lose it. I don't know that anybody has defined a need yet for any number of servos, much less 21 of them. I'd really like to keep the focus centered on exactly what we're trying to get done. THE APPLICATION IS KING! By "application", I mean the "what it is" that we're trying to do. I don't think we have it fully defined yet, but we've got a good start. That's why I keep asking, "In a perfect world, where anything is possible, everything works all the time, & nothing costs too much, what exactly would you like to do?" I always figure that the hardest part of developing any product is prying out of the customer exactly what they want, & this is no different except that the "customer" is US! If anything, that just makes it tougher because we know "too much". The 2 biggest headaches in product development are: 1. A customer who knows (or thinks they know) how how to design & build their application better than the developer does, & wants to micro-manage every detail of it. 2. A developer who thinks that, because he knows how to "program", that it automatically makes him an "expert" in the customer's domain. In our case, we happen to be both! Once we've got "what" defined, there will be no shortage of "hows" to get it done. If we were designing a database application, we might choose Oracle, Sybase, SQLServer, or some other system as the basis. Maybe I have a lot of Oracle experience & favor it, while somebody else prefers something a little cheaper & wants to go with MySQL. If we design the application right, then it really shouldn't matter. That is, unless performance needs, some feature, or other compelling reason says that we need to use "Database X". If we've already invested a bunch of time & effort into "Database Y" by the time we make this discovery, then we've got a problem. Especially if we've built the whole product around certain features that might exist only in "Database Y", & not easy to do in "Database X". Anybody who's ever had a custom house built has probably spent more time up front, with the architect, "hammering out details" than the actual builders spent hammering on nails to build the thing. Why is this? It's because we want to be sure we get it right the 1st time. It's an important project, a big investment, & we plan to live there for awhile. Sure, there will be changes & adjustments to make once the actual construction starts. But, the better we do our up-front design work, & be as sure as we can of everything before we get too committed to specific tools, materials, etc., the less these sort of issues will cause trouble. Do we care whether the contractors use a Stanley nail gun vs. a Craftsman? Probably not, but we do care if there's good traffic flow through the kitchen, & all the bedrooms, bathrooms, etc. are large enough & in the right places. Maybe we don't want a toilet in the living room after all, even though it's a nice, warm spot next to the fireplace, & that's where the pipes are, right under the floor... JM
So, who's working on the multi-button input module? I know somebody wants one. If the guy(s) who want one don't feel up to the task of building it, somebody else should be able to build it for them pretty easily. Maybe work out a trade? Get that 1st module done & you're well on the way to knowing all you need to know, to build the entire system. Even just a prototype on a breadboard would be pretty cool. What should we try to figure out next? More input modules, or take a stab at controlling a weapon? JM
The guy who builds the 1st input module is going to have a big say in the remaining decisions about details of the communication interface (between modules). Also, he's going to know how to do about 80% of what he's going to need to do to build subsequent modules. Plus, 90% or more of what it's going to take to build any other input modules. One simple, basic module is going to open a lot of doors for somebody. JM
Some other sub-topics to deal with at some point: - Weapon Control Module design(s). I see this module type as being a rather simple, "point it where it's told" sort of device. All it really needs to "know" is the aiming parameters for its weapon & it can be oblivious to whatever else is going on. There might be several different variations, depending on which type of mechanical control & communication input is used: "Standard" servo, DC motor with external ESC, DC motor with integrated controller, stepper, PPM input, serial input. Others, too, perhaps. I can make reasonable cases for any of the above, & all should be do-able within the defined framework. - "Core" modules & targeting algorithms. This basically boils down to taking the inputs (range & bearing that we want to "aim" at) & converting it to aiming orders for specific weapons. As with most other modules, there may be a number of ways to get this done. I think that it would be ideal if we ended up with multiple "core" modules, each using different methods (same thing for input & weapon control modules, too, for that matter) so that end-users will have a variety of choices to make if they want to build or buy a system. - Ship Control Modules. Basically, this module's job is to receive & decode commands from the radio & distribute them to the appropriate weapon control modules. One major consideration is how much "intelligence" should be put in the ship vs. in the user's hand. In other words, where do you want most of the processing to take place? My personal preference is to try to keep the ship itself as "dumb" as possible, but I realize that there will need to be some compromises. My main reason for this opinion is that wherever the most processing takes place is also where the most updates will need to be made. I figure I can do this more easily in the operator's hand-held unit than I can in the ship. Regardless, some "balance" is going to need to be determined between a completely "dumb" ship & a 100% "smart" one. Ship control & "core" modules will probably end up having to work as pairs. In fact, to make the "lite" version (that uses an unmodified R/C transmitter as input) work, that balance will almost certainly have to be 100% of the processing on the ship side. That brings up a new topic that hasn't been discussed much: - Configuration. Since one of the goals of the project is to build something that can be deployed on any ship, it's going to have to be customizable by the user. My own experience suggests to me that this could end up being a bigger job than the basic system itself. I'll share some more detailed thoughts on this area later, but 1st I'd like to hear what some others think. I have a couple of ideas about how to get this done, & favor 1 of them, but somebody else may have a better idea that I haven't even thought of yet. - Radio. I like to keep options as wide-open as I can. With regard to radio, this means considering any & all viable options & picking what works best for the application. I know that many people tend to assume that any system must operate within the framework of a "traditional" R/C system. I have 4 basic problems with this assumption: 1. It seriously limits what we can make the application do. 2. The basic R/C model is very poor for transmitting general data, which is what we need to do. 3. By the time we get enough of the basic modules developed, to the point where we're ready to connect them wirelessly, we'll have acquired enough skill to be able to use alternative products. 4. While we could potentially modify a traditional R/C transmitter & receiver to pass general data, the trouble it would take to do so is much more than what it would take to use alternative products that are designed to be integrated into uC systems. That said, not everybody will necessarily agree & there's probably still a need to keep the "traditional" R/C system as an option. I think it should be kept to the "lite" version, though. What may end up working very well with a "lite" system is a combination or pair of "ship controller/core" module(s) that uses the right-hand stick to work as a pseudo-"input module" by defining an aiming point in terms of X/Y coordinates. These could be converted into the defined bearing/range data pair that is further processed into weapon aiming orders just like any other version of the system. Using this model, then, the "lite" version would consist of a radio module, a ship control module, & enough weapon control modules to control however many weapons need controlling. - Deciding when to "shoot". Most of us have probably seen conventional systems where a "glitch" causes weapons to fire when they're not supposed to. uC control opens up some interesting possibilities with regard to interlocks & other potential enhancements to overall safety. There's also another matter to consider: When the decision is made to "shoot" something, where should that decision to be made? I'm not talking about automated systems; presume that the user has made the decision & operated whatever control he has to fire a shot. The system needs to translate that into some sort of action(s). Those actions may ultimately be taken by individual weapon control modules, or by a ship control module. I can make a case for doing it either way, but would be interested in hearing what others may think. JM
Well I have been reading this train of thought since you first posted, but since I have not done any programming since back in the Atari 800/Commodore 64 days, and have forgotten anything I did know, which was little, I have not posted, but. I purchased the DeLuxe PX08M Development Set, it was only $24 with shipping at Visit this site And then I found this R/C Programmable LED Sequence/Flasher System, which I should be able to program to do what I want at Visit this site I want it to Fire gun #1 only when the stick is moved up, the second time you move it up gun #2 fires and so on. This board will support up to a quad mount. And when you pull the stick down it fires all of them at once. Now is anyone able to help with the programming, since at this time I'm quite lost, but plan on learning.
I wouldn't worry about that. Approach it as a complete beginner. You'll probably catch on pretty quickly because of your prior experience. Working with microprocessors is a lot closer to what you did on those older systems than modern Windows programming, so you might actually have an advantage over somebody whose experience is a little more current. I'm sure that there are small "tutorial" projects documented. I'd work on some of those first. Get yourself a solderless prototyping breadboard. Radio Shack, etc. has them for about what you've already got invested or less. Don't be put off by doing really basic, low-level stuff. Everything you ever build afterwards will be made up of these sort of "building blocks". Honestly, I wouldn't even look at something like that until you've gotten very comfortable flashing LEDs, reading switches, reading potentiometers, & whatever other basic tutorial projects you can find. I wouldn't buy one of those. I'd build my own. Basically, if you can light a LED, you can fire a gun. Substitute a solenoid valve for the LED (with appropriate isolation). Well, here's basically what you're needing to do, based on your description of what you want: - "Read" the servo pulse width coming out of a R/C receiver. What you'll get will be some number. The higher the number, the longer the pulse. Determine what number represents "stick centered", & determine a threshold above which you will recognize "stick forward". Same thing for "stick back". - Whenever you detect a "stick forward" value, increment a counter. Depending on the value of the counter, set 1 of 4 output pins high for some TBD length of time (or, until the stick is re-centered). Another option might be to rotate a bit through a register, & copy that register to the output register when you want to shoot. That would really be a lot simpler. - Whenever you detect a "stick back" value, set all 4 output pins high. Each of the 4 output pins would be connected to a solenoid valve, isolated by a solid state relay, optocoupler, etc. For starters, on your prototyping board, just use LEDs. You've got 2 basic functions to deal with: Reading the servo pulse & setting an output. In between, there's a pretty simple determination of which output(s) to set, depending on the pulse input value. Now, look for a couple of tutorials that do those things. I'm not going to do your programming for you. That would take away a big chunk of your fun! But I'll be happy to answer any questions that you have about it. JM
