The DeLuxe PX08M Development Set has a solderless breadboard as a part of it. I plan on just using LED's until I get it working. And the kit comes with small projects to do, so I figured if I do some of those I should pick it up again, hopefully. No I was mainly lookin for some help when I get stuck on the programming.
That sounds like an excellent plan, & that kit sounds like a good deal. By all means, work through their examples. You'll find that a lot of them will apply to what you want to do. When/if you run into problems, I'll be happy to help you work through them. Even if you find solutions elsewhere, if you post them here it will help others understand what you're going through. When you do post examples (whether they're problems to solve, or just clever things that you figure out on your own) please include as much detail as you can, so that everybody can figure out what's going on. JM
Thinking some more on this, it might be an interesting challenge to build without any microcontroller at all. Start with a 555-based R/C switch, that's easy enough (built several of them). Output that to a counter that increments once for every "tick" to select which gun to fire. The whole package should fit on a board 1" x 2", or thereabouts & cost Building something is the easy part, though. I'm curious what you're trying to accomplish & why this sequencing method achieves your goal. You may notice that, throughout most of this thread, I've been trying to focus on exactly what to build, rather than how to build anything. That's all I'm trying to do here; figure out what you want to do. You seem to have the how at least partly figured out, & I'm just wondering what's the rationale behind it. JM
What he is trying to acomplish. A ship witha tripple stern in fast gun. the ability to fire one cannon then the next and the next as range testing or line up shots before wasting ammo on a true fireing of all 3 cannons. It also allows you to keep you ammo on each cannon even.
I battle fast gun, and since the ship only has a single tripple mount, that does not rotate, I'm trying to control the amount of BB's that I fire per shot. One fast gun tripple can fire all the ammo in like 10 seconds or so. Being able to single shot the guns will allow me to make sure I'm on target while wasting fewer BB's, and take potshots at people again without wasting the ammo. Its most likely not going to be that effective, but I can see at times during a battle when it will help a little.
OK, that makes sense, I guess. 1st impression, I was thinking 4 guns aiming all different directions. That didn't make any sense at all. Then I read again, saw that it was for a quad, & wondered why shoot 1-offs when you could hit with more. These explanations make good sense, though, & thanks to you all. Should be pretty easy to do, with or without a uC. JM
Here's the general way that I'd do it, which is not to say that it's the "right" way - there are plenty of other alternatives. First, I suggest that you start with your code comments. Many people just go ahead & code, then expect to add comments later. Unfortunately, it very seldom ends up happening that way. Most often, the documentation gets put off indefinitely. Then, some months later, you find yourself reviewing the code, wondering "What the heck is going on here?!" I like to start with the comments, making them increasingly more detailed (kind of like writing a spec., in a way) until the detail gets to the level where you can start inserting code between the comments. Besides helping with the motivation to do what many consider a boring chore, it helps you to make all the key decisions that you'll need to make, to get done what you want done. Here's basically what you'll need to do: 1. "Read" a servo pulse. I believe the Picaxe has a handy built-in function to do this easily (PULSIN?). This will convert the pulse width into a number representing the duration of the pulse, that's placed into a variable. Use your breadboard to build a test program that reads pulse width outputs from a channel of your radio receiver & displays their raw numeric values (look for some sort of a "debug" function in your Picaxe documentation; I'd be very surprised if there isn't something). That will make it easy for you to figure out what the "center" pulse width value is, as well as where you want to set thresholds for "forward" & "back". You'll probably want to set these somewhere other than full, so that as soon as the stick hits these points, action will be taken. You should be able to take output directly from the signal pin of a receiver channel. Grounds need to be connected, between your receiver & the breadboard. You should be able to power the breadboard from the receiver, & ultimately I'm sure you'd like to power the circuit from it, but I'd check the power requirements (mA) vs. what the receiver can handle before doing that. Play around with this for awhile & you'll get a pretty good feel for what's going on. You'll need to write a loop that repeats the "read" & "debug" commands. This will probably execute a lot faster than the servo pulse repeats, but there should be a "wait" parameter in the PULSIN function that tells how long to wait for a pulse; this should be all the delay you'll need. So, the program should look something like (in no particular language): MAIN: Read PulseWidth into Variable named 'PW' Debug Variable 'PW' to display GOTO MAIN 2. Depending on the value of the pulsewidth variable received above, you'll want to take 1 of 3 actions. Assuming your channel isn't reversed, you'll probably get a larger number when the stick is forward than when it's back, with a "middle" value when it's centered. As you experiment with reading pulses, you'll want to determine a pair of thresholds: The points at which you consider the stick pushed forward or back. Between these thresholds is your "centered" range where you want nothing to happen. Above the "forward" threshold, you want to fire 1 of 4 guns in a sequence. Below the "back" threshold, you want to fire all 4 guns. I'd modify the "MAIN" loop lik this: MAIN: Read PulseWidth into PW IF PW > FwdThresh THEN GOSUB SHOOT1 IF PW < BackThresh THEN GOSUB SHOOT4 GOTO MAIN SUB SHOOT1 RETURN SUB SHOOT4 RETURN At this point, nothing is going to happen regardless of what the pulse width happens to be. We've got to fill in the "SHOOTx" subroutines: SHOOT1 subroutine: This is where we'll fire 1 of 4 guns, in a sequence. There are a lot of ways to do this, but I'd do it by shifting a bit through a register, then copying that register into the register that's associated with the firing output pins (I'm getting a little ahead of things; there are a lot of details regarding control of I/O pins that is covered in your uC documentation, that I won't bother to go over here). Suffice to say that there is a register (or variable) that is associated by-bit with each of the output pins of your controller. These pins are connected to electronic firing valves in the final unit, but can be connected to LEDs just to see what's happening; if you can light a LED, you can fire a gun! Whether the value of an individual bit in this output register (I'll call it "GunsOut" for now) is a 0 or 1 determines whether the valve is open or closed. IF GunsOut = 0 (all bits = 0, in binary we'll show this with a leading '0' as 00000), then all valves are closed; IF GunsOutT = 16 (i.e. 0xF or 01111), then all valves are open. When we want to fire 1 gun at a time, in sequence, we'll basically "walk" a '1' bit through the GUNSOUT register. The most efficient way to do this is with a "shift" function. We'll use another variable, that I'll name "ShootMask" to hold the current gun to shoot. We want to preserve this value between shots, so that we aren't starting over each time. Every time that we go through the SHOOT1 subroutine, we'll shift the value of ShootMask 1 bit to the left, starting with a value of '1'. So, for each time we do this, the bit values will step through the following sequence: 00001, 00010, 00100, 01000, 00001, etc. Here's how it might look, again in no particular programming language: SUB SHOOT1 SHIFTLEFT ShootMask MOVE ShootMask to GunsOut PAUSE [some TBD amount of time] MOVE '0' to GunsOut RETURN Note that I added "PAUSE" & a "MOVE '0' to Gunsout" lines. What this does is to close the firing valves again, after they've been opened by the 1st "MOVE" command. You don't want them to stay open after the shot. Some experimentation will be needed to find the appropriate length of time to hold the valves open for a shot. As an alternative, you might want to hold the valves open as long as the stick is held forward (or back), giving you control over it. I can make a case either way, but this is a design decision that you'll have to make. One thing that you'll have to do if you want to use the stick to hold open the valves (probably a good idea to do it anyway) is to check the PulseWidth variable at the top of SHOOT1 or SHOOT4, to see if it's a "new" move or being held. In SHOOT1, if you don't do this, you're liable to see the guns continuously fire in the 1-2-3-4 sequence, for as long as you hold the stick forward (this may be a desirable feature; it may also be illegal in your club). Same thing in SHOOT4; you may or may not want all 4 guns to fire continuously, as long as the stick is held back. You can prevent this by storing the PulseWidth value each time it's received into another variable (LastPulseWidth). If the "new" pulse (represented by PulseWidth) is above the "Forward" threshold, AND the "old" pulse (represented by LastPulseWidth) is ALSO above the "Forward" threshold, then there hasn't been a return of the stick to "Neutral" & the SHOOT1 subroutine should be skipped. Same thing if the "old" & "new" pulse widthsare less than the "Back" threshold. SHOOT4 Subroutine: This would be pretty much the same as SHOOT1, except that you don't need to rotate a '1' through the output. Instead, just move a literal 0xF (01111; 16) into the GunsOut register. Clear GunsOut the same way as in SHOOT1. Other than some details of I/O pin assignment & setting initial values, that's basically your program. You'll need to make some decisions, as noted, & figure out a few details. One that comes to mind is, will your gas flow be the same firing 1 gun vs. firing 4? If not, then you'll probably need to hold your firing valves open for different amounts of time (if you do it in the program, vs. doing it with the stick). Another option might be to add a master "SHOOT" subroutine, called by both SHOOT1 & SHOOT4, that actually moves the value (as determined by the SHOOTx subroutine) to the output register, then clears it again, thereby firing the guns. Some additional "tweaking" to the logic may be needed, such as "GOTOs" after RETURNs to prevent any possibility of doing both a SHOOT1 & SHOOT4 on the same cycle, etc. But otherwise, this should give you somewhere to start. Go ahead & post any questions, code snippets, etc. as you have them. It might be worthwhile to start a new topic for this item, to keep it all together. Good luck! JM
I just got the kit yesterday, but will not have time to work on it for a bit, 2 weeks I'm guessing. I'm getting my PE done, and Helping John get his ready for the next battle, then I plan on jumping in to it. I remember little to nothing about programming since its been so long, but just looking at when you posted here will help speed things along. I had the board made using diodes, and actually have it assembled, and tested, but its a mass of wiring on the breadboard, it will work for now, till I come up with somthing better. I think having the Picaxe control the actual time, instead of the transmitter stick movement is the way to go, I kind of hold it on too long, at times as it is, and it will shoot multiple times. I want 1 stick movement, one trigger of the solenoid. So in the long run I think this will also improve my BB consumption. Thanks for the help.
If you must have a method of firing one cannon out of a tripple at a time, just rig a logic circut to a TD board. Set it up so that it fires guns 1-2-3 in sequence, one per fire signal. Set anther TD board up so that it fires all 3. Keep it simple, else it will break. Note that as a target finder, shooting alerts your target too.
Well I think its really my decision if I want to single fire guns or not, and I don't really think a fastgun 28 sec, 4 unit ship will attract too much attention from the 24 sec, 6+ unit ships, since they will be too worried about other 6+ unit ships.
A big part of the fun of doing stuff like this is figuring out the different ways it can be done. That's a great one! & oh, so true, too! JM
Let's see if somebody can help me figure out details of a component design, here. In another post I stated that I think the ideal input for target range & bearing would involve a knob with an indicator that I could feel so I'd know where it's pointing without having to look away from the action. The knob would need to rotate 360 degrees with no stops or gaps, so that I could track a target no matter where it happens to be. That covers bearing, but there's still the matter of range. Best I'd been able to figure out was a separate slider for range, but I never really liked the ergonomics of the whole package all that much. I came up with a new idea, though, that incorporates range, bearing, & firing inputs. Here's a rough sketch: A vertical slider would serve both as the range input & the bearing indicator. I'd expect the index finger to operate the range input while thumb & middle finger rotate the knob. With my hand on the control all the time, I should have no trouble feeling where I'm pointing. Also, the entire knob would press down as the "trigger" to fire a shot. That's the basic design, details TBD, which is where I hope some folks have some ideas. 360-degree rotation is easy enough, & activating a momentary-contact switch when the knob is pressed shouldn't be so hard, either. The big problem is coupling the range indicator while allowing full rotation of the knob. I could incorporate a sliding potentiometer into the knob, & connect it using slip rings. Finding one to fit inside a knob might be a challenge, though. I'd like to keep the knob diameter to about 3/4" & height to about 1" or less. An alternative to a slider might be a wheel potentiometer, or lever. The coupling issue is still the same, though. Another idea is to use a mechanical coupling. The only idea that I came up with was to make what amounts to a rack gear wrapped around a cylinder, that engages a pinion on a fixed potentiometer. The rack teeth would be cut laterally along the outside of a cylinder, so it could engage the pinion no matter which way it's turned, & should be something that could be turned on a lathe pretty easily. This might make the package a little large, though. I'd like to keep the behind-the-panel part to around 1" cubed, although I could probably get away with 2" in one dimension (other than depth). I might be able to get a custom switch company to design & build the thing, but probably not for any reasonable (to me) cost for the very small number of units I'd need in my lifetime. Anybody have any other ideas? How about volunteers to try to build something, once I get the details firmed up? JM
John, I have here some 1k slider pots less than 1" long that I got to use as trimpots beside a regular joystick & they would fit within your knob. The reason I went away from knobs to push buttons in limited quadrants was that , whilst you are watching your boat your eye can relatively easily calculate an approximate bearing relative to the heading of your own boat ; even if you put a point on the knob to let you feel the heading it is pointing at it is very hard to maintain the knobs orientation relative to the bow of your boat to maintain accurate bearings RELATIVE TO THE BOAT. If you want to try this configuration I can probably cobble something up for you but will not be free to look at it for a couple of weeks. We have our Nats starting day after tomorrow so everything else is pushed to the background until that is over & subsequent repairs to bring boats back up to scratch completed. Regards, Kevan
Cool! What was the source and/or manufacturer? I hadn't even gotten around to looking for parts yet. I've got sliders, but nothing that small. The idea is that the handheld/transmitter unit would, itself, remain stable in its orientation relative to the ship - i.e. "up" always corresponds to "forward", etc. That would make the target relative to the ship consistent with the knob's pointer relative to the transmitter. I'd also seriously consider adding detents at key bearings, such as the points at which various weapons' fields of fire overlap, etc. Weeks is well within my timeframe. I wouldn't need anything actually built for quite awhile. Months is more than enough. Are you working/planning to work on a button-based input module? If so, any progress yet? JM
1st pass at designing an integrated bearing/range/fire input knob: Color codes: Yellow is the frame/box of the control, lighter yellow is the panel of the transmitter case; Blue parts are used to indicate bearing; red parts are used to indicate range; green parts are used to issue a "fire" command. Bearing is indicated by turning the outer knob assembly (shown green). Not visible is a splined shaft connecting the knob to a 360-degree absolute encoder, shown in blue at the bottom. The splined shaft allows the knob to slip when it's pressed down to fire. Range is indicated by a vertical tab (red) that sticks through the knob, & also serves as a tactile indicator of bearing. The tab is connected to a barrel-shaped rack gear (gear teeth wrapped laterally around a cylinder). This "barrel rack" fits inside the knob body & outside the knob-to-encoder shaft, allowing it to slide freely up & down. With teeth cut horizontally across the cylinder, it can engage a spur gear on the range potentiometer continuously throughout the 360-degree sweep of the knob. The tab has about 0.5" of vertical travel, which translates into about 180 degrees of rotation of the potentiometer shaft. The "fire" signal is produced by pressing down on the knob body. The solid outer knob is connected to a horizontal disk that activates a snap-action switch when the knob is pressed down. As an option, the disk can have notches cut/filed in its outer rim that engage a small spring catch, not shown. This would provide detents that the user could feel as the knob is turned. Useful detents might be directly astern as well as gun overlap bearings; for example, I could know that between (click) & (click), I have both forward & aft turrets engaged without having to look away. Not shown is a small (about postage-stamp size) circuit board. There should be plenty of choices where to mount it. This board would contain a microcontroller & associated components, to take the bearing, range, & fire raw inputs, converting them into serial data output for processing by a core module. So far, the whole thing takes up about 3-1/8" x 1-3/4" x 1-7/8" depth behind a panel. I wouldn't mind getting it a little more compact. The knob will probably have to be built in 3 parts. The range indicator tab/barrel-rack gear would probably need to be 2 or 3 parts. Knob & tab/barrel should be something that could be done on a lathe. The rest is all cutting & drilling. JM
Insteed of trying to select a range,as range is much harder to judge than bearing. Why not have the system auto range? A auto range detector should be much easer than auto tracking. It would help reduce the amount of atention that a captain would need to pay to a target, and leave some for driving.
That's a little outside the realm of what I'm trying to do right here, which is as stated, to combine the bearing, range, & shoot inputs into a common user control. This is just 1 piece of a larger overall project. The larger project may or may not, at some point, include auto-ranging. That's another piece, to be developed on its own within the overall project framework if somebody wants to. However, auto-ranging might very well be illegal in the club(s) that I plan to fight in. In fact, I don't know of any clubs that do allow it. The whole idea of the common, integrated control is that I haven't been happy with separate range, bearing, & shoot controls. This is largely for the reason that you bring up, that it diverts the captain's attention somewhat to have to hunt for separate knobs, sliders, & buttons. I've got the multiple controls now, on a per-mount basis (which multiplies the problem by the number of mounts controlled). I've tried to arrange them so that they're all handy, but I still have to get off of 1 to use the other. Until very recently, I haven't been able to come up with anything that I thought might simplify things for the operator (captain). With the integrated knob, operationally the captain could indicate only a target bearing if he wants, ignoring range. Leave the range input full-up & you've got max. range. If the captain wants to set a shorter range he can, if not he can leave it as-is. Push the same knob down to fire. No matter what, figuring out range & bearing from my own ship to a target is a best-guess, judgment call at best, & I have no problem with that. I'm sure it's going to take some practice to get the hang of it, but practice is a good idea, anyway. Hand never has to leave the control, which I think is a big improvement over what I have now. That's the theory, at least. Whether it works as well in practice, TBD. JM
Hello, Carl recently let me know about this forum, so I wanted to let you all know where I am at with my own version of a fire control system. I have been working on the controller problem for the last year and half, and I think I have a working solution. The transmitter is a gutted PS2 style game pad with a new target direction indicator. The transmitter has 15 buttons, two 2-way joysticks, and a 360 degree target direction input knob. The receiver is a fully custom PCB that supports 8 servos, a large pump circuit, 4 solenoid firing valves, and a PWM main drive controller. The system is addressable; so many people can be running in the same area without interference. Ben Lee from the WWCC graciously allowed me the use of his Hood to test out the system and helped me install and test the system. The turret direction control allows the target to be tracked across 360 degrees without end stops. Target direction is dictated by a knob on the controller with a large pointer. The controller knows where the end of travel points are for each turret and will stop the turret before it hits anything and then swing it around to the other side as needed. The turrets can also triangulate on a target. I included 4 ranges in the setup: 3’, 6’, 12’, and long range. The ranges are set by pressing a button. Our testing so far shows that it only takes a couple of minutes experience to use the controller without having to actually look at it. We tested the range at over 200 feet without loosing information. Longer ranges still work, but could have a slight delay in actions taking place. The radio system is quite fault tolerant. I added a few safety measures to the controller. When it starts up, the boat goes into a safe mode that rotates the turrets so they point either straight forward or aft. In this mode, the guns will not fire. Pressing two buttons is required to get the boat into a “hot” mode that will allow for turret movement and firing. Also, if the boat looses communication with the controller for more than about eight seconds, the boat will revert to safe mode and also stop the main drive (preventing runaways). The boat is steerable and driveable while in safe mode. I have also included a configurable minimum time between shots for the servo firing circuits. I am definitely looking for more feedback on how to improve the system. I am rolling together several more changes for the next revision to make the configuration something that can be done by the average computer user and make it more water resistant. Stephen Morgret
I just saw Steve's controller in action today. The HMS Hood was at the WWCC's awards meeting today, and everyone saw a full technical demonstration. It was VERY impressive. It does practically everything that we've talked about in this thread, and seeing it in action was incredible. I took a short video of the fire controller in action today. My camera died on me before I could film its full functionality, but you can at least see some of the basic functions. http://www.youtube.com/watch?v=094RDEzKGJw By the way, Steve, welcome to the forum! I'm that crazy Spahkreuzer skipper who "welcomed" you to the club. Gascan on this forum is my brother who ran that pesky Italian cruiser, and JohnmCA72 is one of those crazy texans.
