Hi Carl, Stephen Stephen's work is really amazing. The off-the-shelf use of the rotating knob is genius - the red rotating knob on the PS2 controller has a very large and obvious pointer on it that you can feel with your hand. Without even looking down you can tell exactly what your target bearing is by feel alone. I practiced on the Hood on a nearby pond, and I came up with basically cradling the controller, using the left index finger and left thumb to rotate the turrets on the rotating know, and using the right thumbstick to sailing forward / reverse / steer left / right. Firing switches are the upper right buttons that I can hit with my right index finger. The range setting buttons are not touched frequently; in the heat of the battle I will probably just set it at the medium range and occasionally change it; but that we'll figure out in combat. The best part is simply tracking the target and just let all the turrets bear by the themselves. This is exactly what I'd been envisioning for years now. GREAT JOB STEPHEN! When developing and installing / programming this in my garage Stephen took some videos; I don't know if he's had a chance yet but he'll upload themt to YouTube. They show the rotating and tracking of the target. Ben
A hearty "Congratulations!!" Long ago, I'd hoped to be the 1st to field a true fire control system in a model warship, but ran out of time & money. I'm glad somebody's got something actually implemented in a ship! I hope you'll continue to share technical details as well as design philosophies. What radio system did you use? That's a pretty good feature, I think. We might consider adding something like that to the "combined" features list. Welcome to the forum, Stephen! I hope you'll share some more of what you've done & learned! JM
Hi John I don't know when Stephen will be able to log in next - he's on business in Taiwan at the moment, so at least the timezone is a bit off. He's the chief scientist behind this project, and I'm just the yard worker who installed it in my Hood, but I can talk a little bit to your question. - What radio? Stephen rolled his own. He bought off-the-shelf 2.4 ghz transmitter / receiver chips and integrated them on the circuit board into the system. Instructions to tell the sail winch servos what position to point to are calculated inside a processor in the controller and the radio transmits the packets to the receiver at a rate of about 10 times per second. He's using the sail winch servos because they can provide positional feedback. The controller then knows where the turrets are currently pointed towards. (Say, 90 to port beam). The captain dials in a new target bearing (say, 45 degrees off starboard bow). Controller calculates and generates the pulses to tell the servo to turn to 45 degrees. The signals are packaged and transmitted to the receiver in packets. (approx 10 packets per second are sent). Currently the entire PS2 game controller IS the radio and the controls all ship functions. There's some discussion about future versions perhaps eliminating the sail winch servo (sensitive to water) and replacing it perhaps with some sort of pot / motor combination. That's what I can offer at the moment; I'll wait for Stephen to chime in more when he's able. Ben
Hello John, I took a fairly different route to this than what you have been proposing. The transmitter is dumb, the receiver does all the real work. This allows me to use the transmitter for other things, as well. The radio system using an off the shelf Zigbee module to send packets giving the physical state that I want the receiver to be in. If some packets are lost, there is little consequence. A lot of logic also went into making sure that a packet was valid or else discarding it. There is really only one chip handling all the logic at each end. Every time you have to transmit data from one chip to another, you are introduction a potential failure point and also making it MUCH harder to debug. I am using dsPic's at both ends. The price is reasonable, they are 16 bit chips, and can handle the trig functions without issue. The system was designed to cover up as much of the complexity as possible and make it easy to use. The setup is currently a bit tricky, but that is being worked on for the next spin. A number of people have expressed an interest in getting these, so I am working to get it to the point where people can set them up and use them with little outside intervention. Stephen
Stephen, I'm a little confused about the reason Ben cited for using sail-winch servos: "they can provide positional feedback." Are you using them because you just have to tell them what position to go to, and they take care of the rest? (position control) Or are the sail-winch servos actually sending back a signal that tells your receiver what position they are in? (position feedback) How much would it cost? My next project will be a pair of WWI dreadnoughts, so Carl and I are interested in both having one in those ships and in helping you improve it for other people to use. And it's very easy to build three hulls instead of two, if you know what I mean [] Can you gut a regular transmitter and use the gimbals, switches, and trim tabs instead of a PS2 controller? I've always found PS2 controllers to be a bit cramped, and I get more precise control from the longer sticks on a transmitter box. I'd also like to have the option of putting the target bearing knob on the right side instead of the left.
Eric, the sail-winch servos only provide position control. I needed them because I needed the servo to turn farther than a normal one could turn. This version does not have position feedback. I am looking at a version of a turret that would have true position feedback. I would get the benefit of the feedback, use a standard motor (not even needing a gutted servo), and would be truly waterproof. This setup would also take care of the turret getting knocked out of alignment (without the user even knowing that it got knocked). A small change in programming would also allow this turret to be hooked up to a normal radio system and allow the entire turret (pointing direction only) to be treated as a single servo. As for the cost, I am still working it out. Right now, I only have two sets of boards total. These have mistakes that I am working out for the next spin, which will be much more production worthy. Because these were prototypes, the bare circuit boards were almost $50 each. Production PCBs are less than a tenth that, but there are too many problems on this version. That's part of what I get for fully using a 64 pin microcontroller. It will likely be a month or two before I get the next version ready. Could a regular transmitter be gutted and used? Yes, but not with the PCB I have in existing controller. The PCB inside the controller is custom, and it form fits into the inside of the case. The main PCB that came inside the controller gets tossed. Also, I really did use damn near every pin on that chip, and I did not include a separate breakout for the pins. What would be needed is a smaller board that has the transceiver mount, crystal, and IO expanders. This board would then need an extensive breakout area for all of the analog and digital signals. The good news is that no change in the programming would be necessary so long as the pin functions did not change. You will have a chance to test it out before too long, so let's not rush this part. Stephen
Interesting. The cannons that http://www.bderc.com/ sells use sprocket-and-chain rotation. Each cannon has a small sprocket mounted to the underside of the magazine, and they also include a large sprocket for mounting atop a standard servo, with a ratio sufficient for at least 270 degrees rotation. I have tested a few of these cannons, and I could positionally control a cannon using a dial on my transmitter. From what I understand, such a setup would work perfectly fine with your current controller, correct? I'm also kinda curious how you've been planning to add true position feedback to cannons. I've got a few thoughts of my own, but I'd like to hear your ideas first. Having the option of putting the target bearing knob on the right side, or even better, multiple boards with switchable controls, is something you will probably want to include. I know that I aim much better with my right hand than with my left, and I'm not the only one in the WWCC who does. PS: It may sound like Gascan and I are interrogating you, Stephen, but we don't mean to scare you. We're just really excited to see a working computer fire controller.
Carl, I do not consider it the Inquisition. I look at it as giving realistic feedback from potential customer requests. I am also jotting these down as requests. The chain and sprocket setup that you describe should work just fine. For feedback, there are several magnetic angle sensors on the market. By attaching a small magnet directly to the turret, I can get real the feedback I am looking for. However, I also need to do my own motor control to position the turret in the first place. Stephen
When are you coming back to the states? I think we can communicate much more effectively in person than on a forum. Plus Gascan would like to show you his video headset. I am kind of curious, though. What sort of magnetic angle sensor are you thinking of?
Stephen, Do you have a make/type/part #/supplier for the position indicator you used that you can share with us ? Regards, Kevan Morgan
Kotori/Gascan. For a magnetic position sensor , first look at the GMW engineering AM-360 kit : ( www gmw com ). Also see enclosed email reply . The Asahi sensor works well with the same magnets available from GMW (need to be N-S horizontal on the top of the magnet buttom ). Kevan, The prices for the AN_360KIT is $45 ea. The AN_360ASMKIT is $55 each. Both are in stock. I'm sorry, but we do not have an on-line ordering capability. To order you can send your Credit card info via fax, email or telephone. We also have a small 360 deg Angle sensor from Asahi (EM-3241) that operates on 3V and provides an analog voltage proportional to 0 to 360 degrees. Attached is a data sheet. In small quantities the price is about $2.75. There is an Engineering Eval kit that sells for $20 ea. Lou Lou Law Senior Sales Manager, Magnetic Sensors GMW Associates Not affiliated, just a happy camper ! Regards, Kevan Morgan
The 360-ASM sensors look good, but they have a slow response time. For our purposes, they may very well work. For my purposes, the 360 series uses 5V logic, which would blow my uC. I would need to add additional circuitry to convert the voltage. The Asahi EM-3242 looks like a better match for me, but is in chip form.
Hello, I just got back to the US last night. Carl, I am looking at the best way to make a modular transmitter module. It will take a little while, though, as I also need to make new boards for the actual IO. I also need to look at making them so I can use both the motor control and general purpose versions of the dsPIC. That way I can use the PWM for motor control and audio without having to make new boards. Those two onboard functions are not on the same chip. Stephen
Good to hear you're back. Will you be able to make the G/M event in March? Audio? Am I reading this correctly when I see AUDIO? That would be so awesome! I'll have my battleship play "Ride of the Valkyries" in every battle!
One of the options for communication that I looked into several years ago was cordless phone chipsets. They have data (for stuff like Caller-ID, directory dialing, etc.) as well as voice capabilities. My big idea was to equip my transmitter with a mic. & cruise back & forth in front of the enemy's port, taunting & insulting them! JM
That's definitely a decision that anybody who designs a "Core" & "Ship Master" pair will have to consider: How to balance the intelligence between them. I expect that these 2 modules will need to be developed as pairs, mostly for this reason. Personally, I like the idea of keeping most of the intelligence in my hand, vs. in the ship. One reason is a desire to keep the shipboard units as light as possible (not necessarily only in terms of weight). Also, for operator feedback as well as configuration & control of details, I think it's handy to keep as much as possible closest to the operator. At the same time, there's plenty of information available only at the ship level that's not practical to send to the hand-held (nor, necessarily, of much use there if it WAS there), especially information about the ship's physical state/orientation. I think that the case can be made for several different proportions of intelligence hand-held vs. ship. Everybody is liable to have their own opinion of exactly where this line should be drawn. Such as? I'm interested in hearing what else you have planned. I don't know that that's necessarily true. This is where a well-designed communication protocol comes in. To develop a module, one needs only to use the protocol as its input or output, plus whatever functionality the module is being designed to achieve. Unintended consequences are minimized when each module has only 1 job to do. Where a module is doing 10 tasks already, adding an 11th may cause the 4th task to suddenly stop working right. Now THAT sort of thing can be a MAJOR pain to debug. OTOH, if a module "only" has to receive & decode commands, then take some fairly simple action based on those commands, it can be a lot easier to design, build, & debug features on their own, without affecting or being affected by the whole system. The "trend" these days is to move toward more distributed architectures, for plenty of good reasons, I think. With a single controller, you're also going to run into a hard limit in terms of scalability, especially using hobby servos. There are only so many pulses that can be generated in a given refresh cycle. Every feature, controlled turret, etc. that's added is going to reduce the amount of inter-pulse time that's needed to actually do the work required by the features being added. That's an issue that hasn't been discussed in this forum much yet. I haven't brought it up yet because I want to get other aspects of the system that more directly affect the system's main functionality defined thoroughly. My experience in the area suggests that configuring a system for general use is going to be a much larger task than just developing one that works with a specific configuration. Not necessarily difficult, just larger. That's a big reason why I haven't been in any hurry to open that particular can of worms before, besides not really being needed yet. To be anything more than a one-off, or something that only another developer/programmer can update, the system needs to be "productized". This ability is much easier to design in from the start than to try to add on later. I like using tables to store system data. In particular, as it applies to this project, various data elements associated with weapons, targets, etc. can be stored to & retrieved from tables. For example, a turret table might have the minimum & maximum bearings in its field of fire, reload time, current aimed-at bearing, time of last shot, etc. Adding a weapon could be as simple as plugging in a new module & adding a row to a table. Some data elements would be updated real-time, from operator inputs, sensor inputs, & real-time calculations. Others (such as field-of-fire definitions) would need to be set up only when a physical device is added or modified (examples: Adding a new turret; adding rotation to a previously-fixed turret; adding a torpedo; etc.). Any system will need a way to define those items that are "fixed" during normal operation. How do we do that, & just as important, where? I think that this job is best done in the hand-held, which also suggests that it should be "smart" vs. "dumb". This is especially true if there is any kind of operator feedback on the hand-held. Configuration updates can be transmitted to the ship using the defined protocol, & from there propagated to any other devices that need updating. OTOH, if the hand-held is completely dumb, it's certainly possible to update configuration in the ship, but a lot less convenient. How to make configuration changes is another question. One possibility would be to add buttons & a display to whichever unit is appropriate. This is something that I would definitely NOT want to put into a ship, due to space & weight considerations as well as the need to survive being sunk. A separate configuration box could be developed, that plugs in when necessary (same thing could be done for the hand-held, too). This would have the advantage of 1 configuration unit being able to serve multiple ships, & not having to add to the cost, size, weight, power consumption, etc. of any one ship or hand-held. OTOH, having buttons & display available permanently on the hand-held would be probably the ultimate in convenience for the user, allowing configuration changes to be made on the fly. I have a different preference, though. I'd build a configuration application to run on a (laptop) PC, that can update the hand-held via USB. It's pretty darn easy to build a form-based Windows application that manages a simple database & communicates via USB. A USB interface module would be needed for the hand-held (or for the ship, if one still wants to go in that direction) that basically just converts one serial data format to another. Plenty of USB interfaces are available OTS. Basically, ship configuration might work something like this: PC Open ship configuration program Add ship (copy default configuration tables?) Configure ship (update details specific to the ship) Add weapons Configure weapons (update details specific to each weapon) Save (possible to store data for multiple ships/multiple configurations of same ship) (connect USB cable from PC to hand-held) Update ship (data transferred to hand-held) Hand-Held Enter "configuration" mode (auto on USB detect or manual/switch?) Receive data Update local tables Transmit updates to ship (all or just those updated?) Ship-board Receive data Update local tables Transmit updates to subordinate devices That may be getting ahead of things, as far as the distributed ship control system is concerned. Hopefully it won't clutter the issues that still need to be figured out. JM
Yes, you did see the word Audio. It will be a little bit before I can pull it off, however. I am currently using the motor control versions of the dsPIC, which does not have the CODEC interface. In order to get the CODEC, I have to give up a whole bank of PWM circuits that I am currently using for the main drive. The servos are run off of a second bank of PWM circuits that exists in both version of the chip, but the frequency is quite different. For audio, it is probably that I will be forced to add a dedicated uC that will simply be queued from the primary uC. I have enough pins to pull that off without issue; I would just need another small PCB with the uC, audio amp, and memory. The hood will be there at the WWCC Gunnery and Maneuvering day in March. Barring me having to get sent out of country on short notice, I should be there as well. John, you are quite correct about the cases to be make for locating the intelligence. I chose this route for a couple of reasons: I wanted to minimize the amount of telemetry needed and I wanted one transmitter to be able to talk to one of several ships with an absolute minimum of setup. I have a method worked out where the two are connected with a cable, both uCs are reset, they transmit some data back and forth, and then the two transceivers will only talk to each other. A variation on this would connect the transmitter to a PC to transmit a configuration file telling the receiver to respond in a certain way to inputs from the transmitter. On the debug issue, I only have the ability to debug one uC at a time. I've also found it difficult to simulate and test the chip to chip communication. When something goes wrong, all I know is that it is not working. I have a difficult time knowing which uC is at fault, or even if it is the PCB or wires connecting them. As using too many functions on a single uC, I am not too concerned about it. None of my functions are particularly timing sensitive. For time sensitive signals like PWM drive, communications, and servos, I use the on-chip modules that I can set and forget or use interrupts. It is the only way I can (and am) running 8 servos, communications, firing circuits, and main drive without being concerned about overloading the chip. The servos are accurate to sub-microsecond times and I have almost all the time between each incoming packet to make the calculations. The UI for configuring the ship has been on my mind for quite a while. I currently have to compile the servo settings into the program, but I did it in such a way that it is easy for me to pull them from some other source like the eeprom I have connected to each controller. Configuring the ship will be done by effectively running the ship in a very low level mode while the transmitter is hooked up to the PC. Each servo will be run individually and the desired positions stored both in the receiver and in an XML file on the PC. This will allow for ship configurations to be easily stored and retrieved. The next version of the set is getting close to being finished. Hopefully only one more week will be sufficient. The new receiver will have up to 8 firing circuits, 16 servos, 2 large main drive circuits, and 2 large pump circuits.
That's certainly true for anybody, any system. You've got to be able to isolate. To me, that's a point in favor of a distributed system. Whenever I build something that has to communicate, the 1st thing I do is build a simulation/test module. This produces a module that can send and/or receive data without regard for how that data is produced or used, & can be dropped into other "functional" modules so that everything uses the same, thoroughly-tested interface. Extend it to use a variety of I/O methods to create inputs/verify outputs (including, especially, invalid conditions). Example: To debug a turret control module, it's not necessary to have a complete system. Test/simulator module generates data, turret control's response (i.e. movements of turret, or even just pulse-width values, etc.) are checked vs. what's expected. Similar for testing an input module. You don't need to actually move a turret, just make sure that the data produced is appropriate to the input. A distributed model helps debugging a lot, I think, by providing multiple points of isolation. It all depends pretty heavily on getting the communication right, though. JM
Hey, folks! Here is another video of the Madwand's fire control computer in action. This time it's a pond test, showing the guns rotating together, adjusting to different range settings, and tracking a target as it sails by. http://www.youtube.com/watch?v=iRijujAk_x0
