Here's another optional feature I'd like to include (actually, a pair of related features): C.3. Automatic stabilization of those guns that are adjustable in elevation/depression to compensate for sea state and/or vessel trim. C.4. Disallow firing of guns where their (presumed/calculated) elevation exceeds a defined safety margin. I think that C.4., in particular, is the kind of thing that can help "sell" the idea to those who don't have it & might be opposed to its use. The idea is that adding a level of safety at least partially offsets any perceived advantage that non-users might have. JM
I generally want to keep discussions focused on WHAT we're trying to accomplish, & get that thoroughly fleshed-out, before getting too much into HOW to get it done, at least for now. I think we've got a pretty good list going, & I hope that nobody is getting intimidated by how large it's grown. One of the key reasons for designing the system as a collection of modules is to break the tasks down into manageable pieces so that it isn't a single, large, overwhelming task for anybody. The more potential features we can identify up front, the better we can determine exactly what to build. I don't think we'd want to find ourselves "painted into a corner" because we didn't identify some useful feature up front, & can't add it later because we failed to at least allow for expansion in the design. There seems to be a little bit of an issue with regard to the use of "traditional" hobby R/C equipment & I'm not entirely sure how to address it. Probably it's best to define another pair of features: One involves/requires the use of existing hobby R/C technology & the other doesn't. I generally see this as a "how" rather than a "what", but it may fall into a gray area that overlaps both. I'd be more than happy to discus the pros & cons of either method if anybody wants to. I will say this, though: The farther we get into this project, the more comfortable all of us will be dealing with "alternative" methods & technologies. We'll also become keenly aware of just how poor a technology hobby R/C's PPM encoding is for data transmission. There are a lot of off-the-shelf RF data solutions available that can be integrated into a project. One we're all comfortable interfacing among several functional modules, it's not much of a stretch to include a RF data transmitter or receiver as one of those modules. However, in keeping with the desired goal of making a system that's accessible to all, there may very well be justification for developing a "lite" version that fits within the hobby R/C domain. Other thoughts on the matter? JM
I've gone ahead & drawn up a very basic block diagram of how I see the user's hand-held unit of a fire control system in terms of architecture: The blocks represent basic modules to be developed, & the lines between them represent interfaces (arrows showing direction of data flow). Dashed lines show optional modules that can be substituted or added. In this example, the user would have an Input Module with preset aiming points (range indicator TBD, or a fixed range could be hard-coded), LED status display (details TBD), & use an off-the-shelf RF data transmitter module. The "Core" module takes its inputs & figures out firing solutions for each weapon, with plenty of details left to flesh out regarding how that gets done. What I call the "lite" version would have certain functions moved to the shipboard module(s), with a lot of the inputs consolidated in the user's hand-held (i.e. a "traditional" hobby R/C transmitter). Plenty of room for growth/discussion/etc. here... JM
Some more notes on the diagram I posted eariler today: Again, here is an illustration of how breaking the project into component pieces helps reduce it to something easy to manage. For example, if somebody wants to build an "interface" module with a number of preset bearings represented by pushbuttons, it's a lot more clear now exactly what they would have to do. If they want 8 buttons to represent the 4 major compass points & 4 intermediate bearings (i.e. each button represents a 45-degree angle), the basic design is laid out for them. If I were doing it I'd use an 8-bit parallel in/serial out shift register to "read" the switches - no point wasting 8 uC inputs dedicated to individual switches that are going to actually change very rarely. That means you can get by with a very low-end controller that only needs I/O pins for data, select, & clock to access the shift register, plus data, select, & clock to communicate with the "Core" (assuming synchronous serial is used for both). Somebody might even get clever & combine clock & data leads to save a couple of pins. I don't see a need for any interrupts, timers, or A/D converters so we're looking at a pretty simple, basic uC here. I'd expect it to cost about $10-15 to build, most of which would go into all those switches. So, while a full-blown fire control system may seem overwhelming, by breaking the system down into its component parts, it doesn't seem so big after all. Just about anybody should be able to build a little device that reads some switches (or pots, or whatever pointing/indicating device you want to use) & convert the input into a serial data stream. Eventually, if this project really gets going, there may be all kinds of Input Modules to choose from. Pick whichever one(s) you want, or create a new one. As long as they follow certain (TBD) rules, they should all be interchangeable. Same thing with the "Core". Take a set of inputs that conform to the rules, apply whatever targeting algorithm you choose, & output a set of weapon-aiming "orders", again using the rules we're going to all define & agree on as soon as we get all the features figured out. I'm adding some more diagrams in the site's File Manager in a Fire Control folder. JM
Here's another idea to think about for those who, for whatever reason, want to use an unmodified R/C set: Use one of the transmitter's 2-channel sticks to indicate target position relative to own ship. What direction the stick is pushed determines bearing, & how far it's pushed indicates range. Examples: Stick full right is max range, 90 degrees; stick deflection equal forward & right, target is at 45 degrees, range depends on how far from center. I imagine somebody could train themselves to operate it pretty effectively. Probably need return springs in both axes (or removed in both, so that they're the same). I haven't bothered to figure out the math, but it should be fairly easy to convert a pair of x-y values into range & bearing. JM
You can break anything down into its components. The deeper you go, the simpler it gets. Eventually, you get it to the point where it's something you can do. It's the same as with a combat warship. Most people, the 1st time they see one (or photos, or even descriptions) don't have a clue. But over time, we learn about radios, speed controls, guns, CO2 systems, rudders, hulls, etc. to the point where we can handle it & make it all work. JM
Here's generally how I'd like things to work, speaking strictly from a user's perspective: First, I'm almost completely dissatisfied with the standard user controls provided on a typical 6-channel R/C set. The exception (hence "almost") being that I find a 2-channel stick to be pretty good for forward/reverse/speed control & rudder. When it comes to aiming & firing of rotating/elevating guns, I think it leaves plenty to be desired. That's not surprising, though - the thing was engineered to be used to control model aircraft in flight, not aim guns on a model warship! I should be surprised if it DID work well for the unintended purpose that I'm putting it to. The closest thing to a decent directional (bearing) control is the "Flaps" knob on Channel 6. That gives me about 270 degrees of rotational input, which is about what many main battery turrets can cover. There are some problems, though: As it comes from the factory, it's in a pretty inconvenient spot. Flaps are a secondary control on an aircraft, but half of the gun-aiming input is pretty darn primary on a combat warship! The solution, as many people have done, is to move the knob somewhere more convenient, often making it bigger at the same time. This often involves replacing the right-hand stick assembly. This works pretty well for aiming 1 mount, or multiple mounts that are linked together for common control. The rotation range of the knob may not match the rotation range of the mount that it controls. For the most part, this is something we have to live with. What I'd really like is to be able to turn the knob to a particular position, & be able to trust that the mount is aimed at the same angle relative to the ship as the knob is relative to the transmitter in my hand. A lot of times, I just can't see my own gun barrels, but I can see (or, better yet, FEEL) where the knob is aimed. Besides the basic differences in positions, if there's a friction rotation drive involved, chances are pretty good that the mount(s) will get out of alignment with the knob anyway, if they were ever lined up to start with. The problem can be summed up by saying that I just can't trust that the guns are pointed where the knob is pointed. Friction drives are often used with controls that determine motion, not position. This is completely dependent on the captain being able to see & accurately judge the angle that the mount is aimed, which is often impossible (especially at those times when it's needed the most!). Then comes the problem of multiple gun mounts, with different coverages. One obvious solution is to add more knobs, 1 for each mount to be controlled. All of the issues with a single knob/single mount apply to any subsequent knobs/mounts. In addition, there are only so many control channels available, which limits how many mounts that can be independently controlled. Finally, more knobs mean more complexity for the captain to have to deal with. Even if I managed to find a radio with enough channels to control multiple mounts, I doubt that I could use them all effectively. There's just too much stuff to have to worry about. By the time I get all weapons trained on the spot I want to shoot - assuming that I can aim them all accurately in the 1st place - the situation is likely to have changed on me. All the problems of aiming, from mismatches between inputs & actual aimed angles, drive slippage, etc. multiply when multiple independent mounts are involved. Rather than have to deal with numerous weapons individually, I'd like to have some sort of collective control over ALL of them. To me that means shifting my personal focus from the individual weapons to the target itself. If I could keep my attention on the target, & let "something else" worry about the mechanics of getting weapons aimed at that target, I think I could be a more effective captain. That's where the fire control system comes in. How this gets done is what I expect will be the eventual outcome of this exercise. What I'd like to accomplish is summed up in the 2 primary goals to simplify the user interface & manage multiple weapons. JM
The problem of multiple gun mounts is easy to solve. Get more hands to turn the knobs. Have a few people on a ship that has multiple 6 channel radios in it.
Brilliant idea! With 30 available ground frequency channels, we could have a great battle between 2 ships each with crews of 15. I guess that completely settles the fire control issue, then. JM
There's a discussion about CNC mills in the General forum. Discussing the general technology, somebody notes: Also, there are interfaces between modules that allow them to communicate with one another. Think about this: Why would anybody design a system like this? Why not put everything onto a single chip, or at least a single computer board? Figure that a CNC system was designed/built by professionals - what might they know that would lead them to design it this way? There are certain parallels between a CNC mill & a proposed model warship fire control system. Both are, basically, motion-control systems. Instead of moving a single head (mill) on many axes, our task is to move multiple "heads" (turrets; mounts) on 2 axes. "Creates model" is roughly equivalent to defining the target. "Cuts part" translates to firing weapons. In between is the system used to put everything into the position necessary to get the job done. If you see a CNC mill in operation for the 1st time, your reaction is likely to be "Holy cow! How do they do that!?" That's understandable, viewing the system as a whole. But people design these systems, they make them work, and they use them effectively. One of the keys to doing so is to break the job down into its component tasks. Then, break those tasks down into their components, deeper & deeper, until you have a collection of relatively simple tasks that you can solve & manage. This is the key for solving any complex technical problem. JM
Here's a thought exercise (at least, for those who don't have enough friends to help man all their weapons, or do have friends, but those friends would rather run their own ships) that might help flush out some more requirements: "Build" a minimum system from the blocks defined in the posted diagram. That would include 1 Input module, a core (including a targeting algorithm of your choice), a RF Interface, & a RF module. Mentally, on paper, or however you find convenient, work out some scenarios involving the system's use. Figure out how you, as a user of the system, would handle certain combat situations. Based on user inputs, what would be the system's reaction, and how does that affect the tactical situation? Then, put yourself on the "other side". Imagine that you're up against the system that you've defined - how would you try to defeat it? Knowing how it works, what are its weak spots that you can exploit? The results of this exercise may point out the need for some more features (or not). JM
Let's give some thought to what our data should look like. In the diagram on page 3 of this topic, there's a simple block diagram that shows a variety of different modules with lines linking them. Those lines are the interfaces & need some definition (not necessarily now, but eventually). We can see that there's a lot in common among the various modules that take input. Each produces the following outputs: Target ID, range to target, & bearing to target. The "Core" module puts out range & bearing to target, too, as well as mount ID and a "shoot" message of some kind. First, every module needs to be living in the same world & all need to be able to "understand" what is meant by the various data elements that are sent back & forth. What is done with this data may vary considerably, but everybody needs to understand what is meant when data is received. I'd like to propose the following: - Bearing to target is expressed as an 8-bit number (0-255). This will fit nicely into an 8-bit register that is common on microcontrollers. The bearing represents an angle around the ship, with 0 being directly ahead & angles counting upward as you go around clockwise. Bearing 63 (0x3F) would be at 90 degrees to Starboard (right side); bearing 127 (0x7F) would be directly astern, bearing 191 (0xBF) would be at 90 degrees to Port (left side), & all other bearings would be proportionally in between. Bearing 0xFF (255) would be 1 "degree" (1/256th of the circle) counter-clockwise from directly ahead. Any module that deals with only a portion of the circle would also deal only with a portion of the range of bearings. For example, a turret or knob that covers 270 degrees centered on the bow would refer to the range of bearings 0xA1 to 0x5F, etc. By agreeing on this standard, every single entity involved would "know", for example, that angle 0x20 is 45 degrees to Starboard of directly ahead. Range to target, likewise, should be represented as an 8-bit number. I suggest ranging this lowest-to-highest near-to-far, with 0 being immediately close & 0xFF (255) being maximum range (barrels horizontal). Whether any particular scale is applied, let's leave to later - maybe when it's time to actually build something? Anyway, the range value increases with the distance to target, with 0xFF (255) being maximum range/elevation. There may be considerable differences between weapons & other equipment with regard to elevation values & actual range, & this may have to be tweaked. We need to identify up to 4 targets & up to 16 weapons that the range & bearing apply to. There's also going to be the need to use some sort of message to indicate which weapon(s) to fire. I'd like to suggest a 3-part message structure with each part occupying 1 byte: Action, Item, & Value. - Action would basically tell what you want to do. This might include codes for "Set bearing", "Set range", "Fire", & any others that might come up. 8 bits give us 256 different possibilities so there's plenty of room to grow, or even define categories. - Item would identify the specific weapon, target, etc. that the Action applies to. - Value would be the specific value that Action should apply to Item. For example, if the Action is to set a bearing, & the Item identifies Turret #1, then the Value would be what specific bearing Turret #1 is to be trained to. Example: Suppose "10" is the Action code to set the Range to Target; the string "10023F" (binary "0001 0000 0000 0010 0011 1111') could be sent serially down the chain of modules, telling each what it's supposed to do. If an 8-bit parallel data path is used anywhere, the 3 bytes (0x10 0x02 0x3F) could be sent in sequence. If asychronous serial transmission is used then the message could be "framed" with a header, parity, checksum, etc. as needed. I'd suggest that it should be possible for any message ACTION/ITEM/VALUE to appear at any time. There shouldn't be any need to run sequentially through ALL possible combinations. Whenever there is a need to change something, a message is sent & there's enough information in the message that the receiving module should be able to do whatever it needs to do. OK? JM
Here's something else to think about with regard to inter-module communications: When are the devices going to be communicating? There needs to be some kind of arbitration scheme so that, whenever one module has something to send, that the other one is ready to receive it. On the one hand, you don't want to have one module transmitting out into the clear blue, when nothing else is ready, & also so that data only goes to the module(s) that is/are supposed to receive it. On the other hand, you don't want to have a receiving module sitting around forever, waiting for a message that might or might not come (sounds like an episode of Star Trek). This also points out why it's a good idea to give each controller its own single task to do instead of trying to cram everything in at once. The more "stuff" you have going on, the less time you have available to communicate with something else. Consider the case where you're trying to receive & decode a string of servo pulses from a R/C receiver: Every 20 msec you're going to get a string of 7 (using Futaba as an example) pulses with widths from 1-2 msec, a constant gap between, & about 8 msec. at the end. Everything else that you do must be crammed into that 8 msec. That includes all decoding, calculations, logical branching, communicating with other devices, etc. One possible way to tell when to send/receive to/from another device is to try to sync up on the timing. In this example, you know that every 20 msec. there's going to be an 8 msec minus whatever-time-it-takes-to-do-whatever-else window open when the module decoding the pulses is going to be available to talk to you. You've got to make sure that you're ready at the appointed time, which typically means that your execution cycle time must match the decoder's pretty closely. Add more devices, & they all have to match execution cycles, plus the window keeps getting smaller for each. You'll need to decide what to do when a communication window gets missed (& they will, you can count on it). In every communication protocol that I can think of, there's always a "master" & 1 or more "slave(s)". The master controls when communication takes place, & the slave(s) respond only when they're directed to do so. Everybody still needs to be ready to respond when the master comes calling, but the timing of the window doesn't need to be as precise. Here's an example of how this might work: The master has an I/O pin dedicated for each slave. Each slave has a corresponding pin connected to the master. These pins are used to select & enable the slaves individually. Data is sent serially by a common lead connected to 1 pin on the master & all slaves. A clock also connects master & all slaves. When the master wants to communicate with a slave, it sets the "select" signal for that slave. Now, at this exact moment, chances are pretty good that the slave is busy doing something & isn't ready to communicate right away. One of 2 things needs to happen in the slave: - The slave checks its "enable/select" pin on a fairly regular schedule, to see if the master is calling. If not, it goes back to what it's doing, but if the "enable" is enabled, it needs to turn its attention to the master. The master needs to keep the "select/enable" signal active long enough for the slave's longest-possible time between checks (plus a margin for safety), to make sure that it doesn't just go away, or worse, start receiving meaningless data. - The "enable/select" pin is implemented as an interrupt in the slave. As soon as the master sets it, the slave saves what it's doing & gets ready to communicate. The master needs to wait at least whatever amount of time that the slave needs to handle the interrupt (which, at least, should be fairly consistent). Once both sides are ready, data gets sent & received. The clock lead is used as a timer. Typically, each
okay, I'll bite. On the master slave issue: I ran a Scheer, with the aft turret rotation "slaved" mechanically (by wires) opposite the forward. Firing for the turrets was independent... as when they weren't 90 degrees to the ship... well they were pointing every which way. Shame was that I had the rotation points set such that the cannons only had about 180 degree rotation total. If I had my druthers electronically, I have thought that the channel expander buttons or something similar could be set to change master/ slave settings, and change firing linkage patterns. Say you suddenly want to be able to fire A and B turret separately... push a button and the firing control will fire them in sequence, with two of the original firing control imputs. All without rededicating a servo throw to do so. Especially usefull would be a button for an aft cannon that homed it to zero (directly aft) to fire Also, tracking the rear cannon with the front, to bring all turrets to the same general direction has the problem of needing to swing one set or the other in the opposite direction, all the way through its arc, to get back in line if the target crosses the fore or the aft of the ship. Computer controlled safeties to not fire the out of the alignment turret, would be a nice feature. I'm frightened by trying that with clippard parts luck Mike Horne
I don't see any e-mail address there, but I didn't spend much time looking. Try: johnm#skytex.net (with necessary replacement character). Include "SHIPFIGHT" in Subject to guarantee passing spam filters. JM
First, a clarification: When I talked about "master/slave" on 12/11, it had absolutely nothing whatsoever to do with turrets. I was referring only to communication channels. One end (or point, in a multi-point) has to be the nominal "master", just to keep everybody from transmitting at once & interfering with each other. It's like if you have several people with walkie-talkies, all on the same channel. If everybody keys their transmitter at once, nobody can hear anything useful. That's why people say "Over", etc. - it's a basic form of arbitration, to determine who gets to use the channel next. You mention another useful feature here, to prevent an out-of-alignment turret from firing. There are some variations to "out-of-alignment, with what?": - Out-of-alignment with the target is a more-or-less normal condition that should be expected to happen all the time. If the target is out of the turret's field of fire, for instance. - Out-of-alignment in the sense that it's not pointing where you want it to/think it is, is another issue, but needs to be considered. This can happen from a collision, or just plain slippage or gears/chains jumping. Something else to consider: How far out-of-alignment is too much? Is there some threshold of error, below which, you'd like to take the shot anyway? Are you only going to take the shot if the aim is dead-on accurate (at least within the ability of your equipment to determine)? How about if it's only 1 degree off - do you take the shot anyway? What if it's 5 degrees off? 10? A lot of what you're talking about falls under the heading of Targeting Algorithms, which we haven't really talked about yet. The reason for that, I hope will become apparent as we go on. Suffice to say, for now, that there are many different ways to skin that particular cat, none of which are necessarily "right" or "wrong". I'm trying to establish first as many real requirements - the "whats" - as we can. The methods used to achieve the requirements - the "hows" - should fall out from there, assuming that we
Sounds like the project is big enough that you'll find keeping a definition list will help keep us all on the same page. If master/slave is taken for the magic smoke (er... electronics) that runs the thing Then let me suggest using a term such as link and linked for changing the cannon sets roatation and depression to copy anothers by changing info from the tx. Given how much technology comes down in price, any thought to an lcd screen on the tx displaying the position of the guns/ status of ship... I can dream Now if I just understood electronics Mike
Not a bad idea at all. Let's hold off on that for now. What you're really describing is a method ("how") of converting user inputs into weapon aiming orders (also known as the "targeting algorithm") that we really haven't gotten into yet. Hold that thought for awhile & we'll get to that eventually. That's exactly what I was fishing for: Something specific that somebody wants. I'd add to the "anything is possible, everything works all the time" qualifier that perceived cost should be no object, at least when considering what anybody might want to see. Costs & technological barriers will eliminate some ideas soon enough, but let's let that happen on its own, later. For now, open up the imaginations & let whatever wants to fall out, fall out. If we were a company, developing a commercial product, we'd be in the "Market Analysis" phase right now, figuring out exactly what to build based on what the users want. We're a long way from production, or even design, for that matter (although we're starting to explore some options, mostly as example illustration at this point). That's the whole point, at least right now. Once we've got the dreams all defined, we'll figure out how to make (at least some, if not most of) them happen. Plenty of people do. There's no reason you can't become one of them. If not, there's still plenty of value in "dreaming", to help let the "builders" know what should be built. "Non-technical" users have a valuable role to play, keeping things grounded & helping to make sure that features are, indeed, useful. Too often, those who are more technically-inclined & directly involved in the development & building of something tend to add features "because they can", not because they're particularly useful. JM
