I'm entering a new round of teaching and I'm really asking myself what are the skills necessary to create the kinds of electronic gadgets I've been creating.
From my perspective, a lot of it is boilerplate; parts and circuits I already know and can plug in to a new project. I have intentionally kept this collection of known elements small and controllable -- even as each new project I undertake intentionally includes learning and adding at least one new element to the set.
Another large part is the analytic method. Iterative design, modular construction, testing and empiricism and, as I am able to do it, quantification and calculation.
The hardest part to teach is that kind of instinct you get when you have done similar stuff for a while. When you understand not the specific wiring of a part, but the way that wiring is similar to a host of other parts. Like knowing that basically all 8-pin dips will want ground and vcc, and they will often be found on corners of the chip. Like having a sense for the current rating of a part from how physically beefy it is.
And, yes, a large part of it these days is looking for help online. Whatever circuit I'm tinkering with, the chances are good someone else has done something similar. The trick there is being able to sort signal from noise. To know where to look, to be able to navigate in those places where the information might be, and to be able to rate the trustworthiness of what you find. And that also seems to be something that just requires familiarity; time and exposure and experience.
The analytic method seems the easiest to explain. Being able to apply it may be another matter entirely!
When I got a little further on I reached a point of calculation; where I knew the wattage of the various things I meant to use, and I could check that against the known capacity of batteries and see if it was actually possible to put that much light on a costume.
What I was gathering was empirical but quantifiable data; a sense of just how bright each part was, that I could then use to understand how their numerical data (aka wattage, lumens, field of view, etc.) related to actual visibility in stage lighting conditions.
The best I could do was to test each section of lighting on the costume before I soldered the final wires.
And although I was able to do a full plugs-out test, the final shake-down under show conditions -- costume on an actor, stage lights on, wireless microphones in use, etc -- was done for the first time in front of an audience.
So the very first part of a project is trying to parameterize what it will take to achieve what you want to achieve.
Say that you are trying to make, as a for-instance, a pair of nekomimi ears.
The two big questions during the first phase of development are then, obviously; 1) what do we need to wiggle the ears, and; 2) how do we control them.
At some point you need to proof the concept. Put a servo on an ear on a wig block and see if it moves as smoothly and swiftly as you intend. Hook up a sensor and see if it is sending you data you can parse usefully.
But before that you need to grok just what kind of servo and sensor is necessary. And for this, calculation (and research) helps.
But we're not talking actual engineering calculation (although I've done that in the past). I'm talking about the simpler tools science uses; order of magnitude calculations, and dimensional analysis.
Order of magnitude is the justly-famous "Spherical Cow" family of approximations. Instead of trying to plug in exact numbers to ten significant digits, you are seeing if you are in the same ballpark or not.
Assume cat ears. Assume they are made out of fake fur and foam. Assume we can make a fairly smooth pivot for them; so as an approximation, the turning resistance due to mechanical friction will be on the same order of magnitude or less than the torque of moving the ear itself.
Borrowing a page from dimensional analysis, I look up a standard small hobby servomotor and see the torque is rated in ounce/inches. So to find out if a small servo will work, I need to be able to plug ounces and inches into a calculation.
A brief look online and I find the shipping weight on a pair of crew socks is 2.4 oz. Assuming the foam and fur is a bit heavier than that (but around the same dimensions) I'd go 10 oz at the outside. Holding up a hand, I'd say the ears are maybe 5" at the base -- that gives a radius of under three inches. So the torque to move them would be < 30 oz/inch.
A micro-servo at Adafruit is listed with a stall torque of 25 oz/inch at 4.8 volts. Which, given my generous assumptions above, is probably enough.
So now let's calculate velocity. I said "twitch" to myself and twitched my own ears (I am one of the small percentage of people who can do that). Felt like a bit under 1/2 second. Assume I want to move the ears from neutral to forward in 1/2 second, that's at least 90 degrees. So as an approximation, I need to be able to move 180 degrees in 1 second or less.
That same servo lists at .1 second/60 degrees, which is a magnitude faster than I need. Of course that's probably no-load speed, but again this seems plausible.
Now, if the speed had been too low, I might have to put in a gear train. Which would multiply the torque by the same factor, plus double it to account for mechanical losses. Had the torque been too low, same idea; put in a lever arm, and reduce the effective velocity.
The thing of it is, to do this kind of approximation -- Orders of Magnitude and/or Dimensional Analysis -- you have to have a sense for what matters and what doesn't. You notice I didn't bother actually including mechanical losses. That is because my experience for machines like this is that torque trumps any losses in the pivot. But the fact that I brought it up; again, experience that even a simple rod linkage will waste significant energy which has to be accounted for in the design.
And that's the tough part to teach, again. You have to do this kind of
approximation, and do it over and over again, and hold it up against the
real world with empirical tests and research (to see if other people
have used a small hobby servo on a pair of cat ears -- and, yes, they
have. Which is good enough to proof that this is a method that can
work, all else being equal).
And it also required I understood the concept of torque, of angular momentum, of how this is characterized (as mass over a lever arm aka radius.)
And this is physics. Or other sciences. Which means that often what is happening is not intuitive. Your instinct might be, for instance, that a blue christmas tree light of 5 watts is brighter than a blue LED at 1 watt. And it would be, except that an incandescent lamp puts out a broad spectrum, which is then filtered down to just the blue by a coating on the bulb, with the rest wasted as heat. So more of that power becomes blue light in the LED.
Which seems to require you have a basic grounding in whatever sciences may be appropriate. Or at least some basic general science.
And then there's the familiarity with the tools.
I've been using servos for a while. I am familiar with several things about them; that they make noise when they move. That they move at a preset rate. That you need to supply a specific kind of control signal to them (PWM -- pulse-width modulation). That they require the same 5v as much of your electronics, but more amperage than a typical Arduino will supply.
In the case of the WIZ costume, my known tools were Power Darlingtons, Arduino, XBee modules, and my home-brew Blink code. I'd already hooked many of these modules to each other in different projects; PWM dimming of a high-power LED via a power darlington, speaking to an Arduino with an XBee, and so forth. So the interactions were mostly known.
What I did NOT know is if the circuitry -- micro-computer and micro-power serial data link -- would survive in an environment where I was switching several amps of LED on and off. Or if the whole mess would make radio noise and interfere with the wireless microphones.
Now I know. And I know simpler ways to build the next similar device, too. Iteration and empiricism aren't just useful for the project at hand; they are also how you refine the tools you then have available for the next project.
But this makes my teaching project difficult. I can communicate a set of tools, but the skills to know when these tools are appropriate and the range in which they will work -- that is more difficult.