Come a Little Bit Closer
I often struggle with the exact definition of an embedded system. At first glance it seems like it ought to be a computer embedded in something else, right? You might define it as a computer with no user interface, but many embedded systems now do have user interfaces. You might try saying that it is a system that doesn't use a workstation, but that fails sometimes too. I'd say that a PC with data acquisition boards and motor drivers is closer to an embedded system than a traditional application developer's realm. What about a computer that has sensors and effectors that interact with the real world? That's probably my favorite definition, but I have decided that it is probably best to borrow U.S. Supreme Court Justice Potter Stewart's famous statement:
"I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description…But I know it when I see it."
Of course, he was talking about pornography, but it applies just as well to embedded systems.
Although it isn't perfect, I am partial to the definition that embedded systems have sensors and effectors that interact with the real world. Part of designing effective systems is knowing the range of options available for such things and evaluating their relative merit.
Of course, merit is a subjective measure. For example, consider tires on your automobile. Do you want tires with treads or slick tires? There is no right answer to this question. To get an answer you have to (even if unconsciously) ask another question: What is my goal?
Drag racing cars want to go fast. They use slick tires because they make the most contact with the road. So why don't you use slick tires on your car? One word: rain. Without treads, water would not channel away from the interface between your tire and the road and you'd slide over the road in a decidedly unsafe fashion.
Twice this week I've had to think about detecting a physical object. Once was for one of my projects where I need to see if a door is open or closed. The other was a colleague who was working on a bean bag toss game for his son's school. That got me thinking of how many ways there are to sense a physical object.
The tasks are fairly different. The door is reasonably well aligned so something as simple as a microswitch with a striker would do the job. The bean bag game has targets passing through a hole at varying rates of speed with some variability in position. So a microswitch might not be the best option there.
Just for fun, I decided to make a list of the ways I could think of to sense an object: mechanically, optically (including infrared), magnetically, capacitor/inductor schemes, acoustically, or via radio frequency techniques. I'm sure there are other ways (and many of these cover multiple different ways — for example, I can think of at least three optical methods ranging from a camera to measuring light bouncing off the object in question).
A mechanical switch is cheap and easy, but — as with the bean bags — not always a good solution. They are also prone to fail since they are electromechanical. You could argue that at least some magnetic solutions are mechanical as well. A reed switch is basically a relay contact that reacts to an external magnet. This would work well in my door design. A magnet on the door gets close to the reed and causes it to open (or close). This requires no wires on the moving part of the door and is reasonably cheap. It is also electromechanical, but somewhat more reliable since the entire reed can be sealed (granted, switches can be entirely sealed, too, at greater cost).
However, there are other ways you might do a magnetic sensor. For example, the reed switch could be replaced with a hall effect sensor. These may not be as cheap as a simple switch (especially when you add the circuitry to read them), but they are certainly reliable. You can get integrated sensors for a buck or two (for example, sensors from Melexis or Allegro).
Speaking of magnetics, I have seen schemes where a door changes the capacitance or inductance of a circuit element. Usually, that element controls an oscillator so that the change in value changes the frequency of the oscillator. That might sound overly complex, but a digital level that changes frequency is easy to detect since your processor can easily measure the time an output is high or low. This is especially interesting if you need to not only know something is present, but how far away it is.
Acoustics can also tell you how far away something is by using SONAR (or SODAR). Some old Polaroid cameras used this scheme for autofocus, and you can still get similar-looking modules from Senscomp and other sources (in fact, I used one a few months ago to detect a person sitting at a computer). If you did this with radio frequency, you'd have built a RADAR.
There are many ways to do optical detection. A vision system with a camera is probably overkill most of the time, but there are two common optical schemes that work in a lot of cases. One is to build a large optointerruptor. A beam of light crosses to a sensor and the object breaks the beam (this assumes, of course, the object is opaque). Another common scheme is to let the light bounce off the object and sense the reflection (a crude form of LIDAR).
Obviously, if you have a sensor and you are depending on a beam break, you have to shield against ambient light and ensure the alignment of the beam and the sensor. The reflected case is less of a problem with alignment, but you still have to be careful of ambient light.
For most applications, just using a simple light and sensor won't work well. Most applications use an infrared light (IR) and modulate it at some frequency. Certain common lights emit infrared modulated at 100 or 120 Hz (based on the 50 or 60Hz AC where you live), so the frequency is usually much higher than that. Because IR remote controls use a 38 kHz modulation (for historical reasons), that's a common frequency. You'd think it would be hard to filter and demodulate the incoming signal, but there are ICs that will do that for you (Vishay has many choices for these, for example).
You do have to be careful, though. All that filtering and processing means that it takes a certain amount of IR to trigger the sensor and there may be some "recovery" time to wait before it will see another event. It was important to do the math to see if the bean bags, for example, would go by so fast that the sensor would just consume the event as a glitch.
Another way to use IR is to use an IR pyrometer or PIR device. These are commonly used in alarm systems because they really detect motion. Two pyrometers measure the IR emissions of what they can see. If nothing is moving, the difference between the two sensors will remain steady. Anything moving will cause a difference that can be detected. This isn't really a good choice for object sensing, but it is a possibility. Like the other IR sensors, there is some finite time to respond.
Another radio frequency method — although a bit of overkill — is to use RFID tags. This has the advantage that you can also know which object is nearby. I used this once in a museum display that sensed different cast rubber livers and displayed information about what was wrong with each one (or, why the one good liver was healthy). You can find inexpensive RFID readers, but be aware that different RFID types have different ranges.
So what's the right method? It is like slick tires — nothing is always right, it depends on your goal. For the liver project, the RFID method made sense. The door project will use a magnetic reed switch and the bean bags wound up using reflected IR, I think. One of the most important parts of our jobs as designers is selecting technically feasible methods that fit the overall system goals: cost, reliability, accuracy, or whatever drives your design.
I'm sure I've missed some methods — feel free to post a comment to remind me of any you've used. In the future, I'll talk about some other physical interfaces and the trades involved with them as well.