Today I’m going to talk about something near and dear to my heart- sensor selection and integration. My Master’s thesis and my most cited published work focus on embedding fiber optic sensors directly into functional metal parts. I won’t be talking too much about sensor specs- that’s something that should be discussed on an individual level for whatever your task is. Rather, today I’ll be talking about how to determine where to put sensors in your application, and how to design your sensor outputs.
There are a few takeaways that I hope I can convince you of:
- Putting a sensor right where you want to be measuring is priority 1
- Selecting an easy to use sensor is priority 2
- Making decisions based off of as little data as possible is priority 3
The first two points I doubt will be particularly controversial, so we’ll start there.
Place your sensors close to your point of interest, inside of it if possible
Part of sensor design, measurement, and characterization is the recognition that you’re rarely getting perfect data from your sensor. Between electrical noise, manufacturing variance, and the structural changes associated with integrating a new sensor, there will always be some discrepancies between your sensor data and the physical phenomena you’re interested in. Good, disciplined sensor design seeks to mitigate uncertainty, and the simplest way to do that is to remove as many interfaces between your device and your sensor.
A good way to think about it is this: Everything between your device and your sensor is introducing noise and uncertainty, most of it in ways that are impossible to quantify with high confidence. By removing those interfaces, you never have to even bother trying to solve those problems, and you can start doing science faster.
After location, ease of use trumps everything else
A senior electrical engineer was once reviewing some of my software, and asked me if I could do some specific manipulation of the data. I told him that I could, but I would have to write the logic in first- when I said this, he simply responded, “If you can’t do it right now, just say you can’t do it until you can.”
It’s easy to judge sensors based off of their potential: If it can store X amount of data at Y speeds and in Z formats, we can use it for a lot of things down the road. However, it’s a bad habit- disciplined sensor selection should focus on current capability, not imagined.
The main reason I put this point here is to mitigate risk- If I have a sensor that plugs into the device, then into a controller, then into a digital-analog-converter, then feeds into a series of programs that have to do various transforms on the data, I almost never use that sensor over one that I can just plug directly into the computer and get data out of. If something goes wrong in the second case, I can tell there’s something wrong with my sensor, cable, or data output. If something goes wrong in the first case, I have to verify every possible interface from sensor to output, and it becomes much more ardurous.
Of course this cuts multiple ways: If I have a sensor that plugs right into the computer but outputs data in an arbitrary encoding that can only be read through some esoteric terminal, that isn’t any good. As few interfaces as possible, and as little specific knowledge as possible, are the hallmarks of good sensor selection.
“Weniger, Aber Besser” (Less, But Better) -Dieter Rams
Data collection is important for science, but in most applications it is best to be lean. Having lots of data is good- it allows us to make informed decisions with high confidence, but we should take a lesson from how our brains work (synaptic plasticity) and try to emulate them- determine the least complex model that we can use to make good decisions, and constantly look for ways to make that model even simpler.
This becomes much more important during system integration- if everyone builds their sensors and logic flows to be greedy, everything becomes slow and hard to troubleshoot. If instead everyone delivers the minimum functional subsystem, integration is intuitive and subsystems are considerate of each other.
I hope to update this post with examples and images at a later date- this note is to serve as a reminder to me
Jack Schomer 