The pre-planning stage has merged smoothly into the planning stage. I've started a Scrivener document for project notes and resources, and a Gannt Chart to plot whether I can afford to use certain technologies.
If I hew to a firm October 1st delivery date, the Dependency between the delivery and development of a VFD display cuts too far into the delivery cycle at the 3d printer. Basically, if I assume I will be getting the faceplate done at Shapeways, I can't afford to wait for a vacuum tube to ship from the Ukraine.
But I can't resist giving it a try anyhow!
I made a scale drawing of the footprint of the faceplate, and made scale drawings of the leading display options. Most of the available LCD displays are too big to even fit inside the box. The remainder are still so large they take up too much of the behind-the-panel space (space I need for the rotary switches). I'm not ruling out pulling a display from a vintage calculator but that seems like a shame to do, besides being time-consuming.
The only real competitor to a miniature VFD for the desired look and footprint is a monochrome OLED display. Basically I'd be using it to display a picture of a 7-segment display (or you could look at it as displaying a custom character set in a large font). Not entirely convincing as a 1970's-era display, and certainly not as cool as a VFD, but it would be nice and bright. It would also be extremely simply to wire (assuming I use an Adafruit breakout board).
But given the time, cost, and the requirements of the prop, the smart choice at this point is a static display; a back-lit image of a typical display.
So the plan is to frame out a space that would fit the VFD if it were to arrive in time and become functional, and to provide the computing power inside the box to be able to drive it, but design so that simpler substitutes can be slotted in.
This is not a project that takes well to a linear development process, but fortunately, it is simple enough that I can afford to use an iterative development that circles through scope and work breakdown structure in addition to local problem-solving. The issues with a classic waterfall design process are that I am using unexplored technologies, and the project requirements are quite fluid. I am free to change the parameters of what I intend to deliver if I stumble upon a process or part that will produce a lower cost or a better effect.
The difficulty, of course, is controlling risk and keeping the cost of exploration down. You can afford to explore only a small number of fruitless paths. You also have to make firm decisions at multiple points along the development path in order to be able to continue both planning and build.
This is why the most important element in the project plan, for me, was the pre-planning stage. Pre-planning was intended to absorb the more outre explorations with their potential cost in parts and development time. When I hit the planning stage, it was with a project spec and construction method that was roughly parameterized.
As it turned out, exploration of what the devices might "actually" be, and what we chose to simulate, and what were the plausible ways we could build them, has essentially ruled out the need for extensive research and the need for complex electronics. Neither the project spec nor the theoretical reality we are simulating requires -- for the CBR kit at least -- breaking down specifics of the threat environment. The theorized user doesn't need to know which chemical agent they are facing, and the box I build doesn't need to discriminate either in display or in any kind of detection circuit.
The latter requires explanation. One of my earliest pie-in-the-sky ideas was to use RFID tags attached to mock samples to allow the prop to "detect" different threats and react differently to them. But, for all practical purposes, what the prop does is "Blink the warning light and display something cryptic on the tiny display." There isn't practical reason to go further.
This was also worked iteratively with what would physically fit on the 8 x 6 cm footprint of the top plate -- once we committed to the assumption that the controls looked roughly like a military radio of the period, and not some sort of multi-button futuristic keyboard and display. There is a stark limitation to the number of settings a single knob can reach -- or that a Recon Team member in field conditions can be expected to dial up with any accuracy.
Cycling through practicalities of prop construction, although the military could and has created multi-pole rotary switches with different selections in different rings, getting this to work practically for our prop would be extremely difficult. And doesn't seem worthwhile; for gaming purposes, the Recon Team member is going to turn one big dial to "Alarm Silent" or to "Inject Universal Antidote." No further interaction is necessary.
So what we end up with is a box with minimal internal electronics and several rotary switches mounted on top (plus display and a couple other bits and pieces).
Which because of the switch mounting means it needs something fairly solid and reasonably dimensional up there. And the look of period radios is raised or incised lettering in the plastic itself (rather than printed/anodized faceplates). Which is likely to be simplest done as a 3d print.
This isn't the first time I've used 3d printing, so I am aware of the constraints there. There is a variable shrinkage. It usually requires polishing. And it is too expensive to print large volumes. As a guess, even with minimal wall thickness the entire 8 x 6 x 15 cm box would be too expensive. So it seems smartest to duplicate a typical construction of the time and have a top plate that screws down to a body. The body in this case is probably resin-cast -- mostly because I need to build experience with molding.
Another advantage to 3d printing is that you generate a dimensioned 3d model at some point in the process. Which you can use to visualize, to problem-solve component fit, and to confer with the client and get approval.
I'm still toying with the idea of printed knobs but I haven't figured out how to get the brass inserts and set screws to work. Which they will need if they are operating rotary switches. Best route might be to smash some cheap knobs, drill out the recess in the prints, and epoxy the insert to the new knob. At approx $2 per cc, printed knobs would be as much as $6 each -- but that is quite competitive with surplus military radio parts.
I'm also thinking I might have the "injector nozzle" printed. Even though, as we understand the underlying technology, there is no need for any visible injector, even Morrow Industries can understand the need for ergonomics. Having a clear "something" you press against to administer the dose just feels better to the Recon Team member using it. Besides, it looks better as a prop with something there, and it gives me an excuse to try to slip some more function in -- a vibration motor behind the injector. And probably a capacitance sensor to trigger it.
The CPU needs are minimal if there isn't a functional display, but if there is one, the software would be simplest on an Arduino. A "naked" Arduino will do it, though (although I'm not against using a mini or even a micro). So plan to have one even if that lifting power isn't needed. Since it is available, however, I can do tone generation on the CPU and I won't need a separate chip to generate the alarm sounds. Just need a basic amp/power amp and probably a piezo speaker.
Unlike most of the things I've been doing lately, liPo is not advantageous, and there is no need for any kind of RF link. An organic gas sensor would be very, very cool but not very practical and could waste a lot of the development time. About the only major thing left to figure out is the best way to access the battery for battery changes.
In the iterative process, the CBR makes so much sense in the current scheme (simple electronics, surplus knobs on a 3d printed face-plate, resin-cast body filled with shot to achieve appropriate weight), it is sensible to shortcut the exploratory process on the med-kit and just declare that "It looks like the CBR kit and is built the same way."
If I didn't make this fiat, I'd be struggling a lot to define how the magic med-kit could possibly be doing what it is doing and how one would want to present it to either the Recon Team operators or to our players.
Instead all I need to do now is combine the various descriptions into some number of positions on a small number of knobs and switches and a small cryptic display. Basically, it becomes "Cleric-in-a-box"; as far as the Recon Team member/player is concerned, you turn the dial to "Cure Light Wounds" and cast one use of the spell.
I admit to being very tempted to try to build in some sort of actual bio sensing so it can at least detect that it has been held up to a human...if not displaying actual values for pulse, temperature, or whatever else is easy to measure. Or fake the measure of, rather!
But for the current development plan, that must be considered stretch goals. Whatever I can do in the way of real sensing will have to be accomplished within the framework of a resin-cast box containing an Arduino with a minimum amount of support circuitry, and will have to happen through the "injector site" populating the curved bottom of the box. And whatever is displayed will have to go through the "I'm just a seven-segment display" on the top, plus perhaps a blinking pilot light if I can possibly figure out what that light might do (the CBR kit has two such lights and it would be nice to be able to echo that with something similar in the Med Kit.)
(My alternative design direction for the Med Kit is to keep it with basically radio knobs and olive-drab plastic case, but arrange the display and controls to vaguely suggest the TOS Medical Tricorder. Without attached scanner, probably!)
Exploratory time is almost over. I have to either order some knobs now -- so I can accurately dimension the model -- or commit to custom molding/printing. But I probably have to order the selector switches themselves to make sure I can fit everything properly. 6 x 8 cm is really a small footprint for having multiple switches and indicators!
No comments:
Post a Comment