Smartphones are the most common expression of [Gene Roddneberry]’s dream of a small device packed with sensors, but so far, the suite of sensors in the latest and greatest smartphone are only used to tell Uber where to pick you up, or upload pics to an Instagram account. It’s not an ideal situation, but keep in mind the Federation of the 24th century was still transitioning to a post-scarcity economy; we still have about 400 years until angel investors, startups, and accelerators are rendered obsolete.
Until then, [Peter Jansen] has dedicated a few years of his life to making the Tricorder of the Star Trek universe a reality. It’s his entry for The Hackaday Prize, and made it to the finals selection, giving [Peter] a one in five chance of winning a trip to space.
[Peter]’s entry, the Open Source Science Tricorder or the Arducorder Mini, is loaded down with sensors. With the right software, it’s able to tell [Peter] the health of leaves, how good the shielding is on [Peter]’s CT scanner, push all the data to the web, and provide a way to sense just about anything happening in the environment. You can check out [Peter]’s video for The Hackaday Prize finals below, and an interview after that.
This is your fourth or fifth revision in almost as many years. and the latest version has a lot of sensors that aren't found in the Mk.I version. Is this just a function of cost, or are device manufacturers really pushing out newer and more capable sensors?
You’re right — I think the Arducorder Mini is my seventh or eighth prototype (some of them don’t make the site), which is about one a year since I started designing them. For me it’s very exciting that this is the first “complete” design since the Mark 1, which was built nearly eight years ago — the others were experiments (or learning experiences) in different aspects of design, from designing handheld linux-powered systems, to incorporating different graphical requirements, to experimenting with sensor fusion.
I think the past few years has really been the start of a renaissance in off-the-shelf sensors. What excites me the most isn’t so much slightly smaller sensors or devices with higher resolution, but sensors that come completely out of left field and add embedded capability that simply wasn’t there before. The new microspectrometer that Hamamatsu released this year was a great example of this, as is the Radiation Watch Type 5 (a photodiode-based radiation sensor, which is MUCH smaller than tube based systems). The AMS lightning sensor is also very cool, although because there are few storms where I live, I’ve mostly used it to detect when large electrical items (like the air conditioner) turn on. A few other parts have existed, but the price point or availability hasn’t been accessible — the single-chip inertial measurement units from Invensense that are an order of magnitude less expensive than they were only a few years ago, and the recent low-resolution thermal cameras are great examples of this.
If you could describe what is missing from your tricorder, what would it be? What sensor is on your wishlist?
Before going into the sensors, after the first design (the Mark 1), each of my “tricorder projects” has examined a different aspect of the design of a pocket-sized handheld multisensor device that I thought was important. The Mark 2 examined beautiful graphics and visualization capabilities, and what it was like to SSH into your handheld instrument to develop code for it. The next iteration tried to be much less expensive and have modular sensor boards, but failed horribly — it was under designed, and far too limited in almost every way (including graphical capabilities). The Mark 4 came about right as smartphones became popular, and asked whether it would be better to pair a small keyfob with a smartphone or tablet instead of having a separate device. On the other end of the spectrum, the projects in the last few years have focused on much more complicated devices, one of them linux powered — but it became clear that I was basically trying to replicate making a smart phone with sensors, which I think isn’t the path to go for two reasons. The first is that I’m not sure the same user model that applies to talking, texting, and playing games applies to massively multimodal sensor data (as many other wonderful features as smartphones have, like incredible visualization and communication capabilities, as well as a large community of developers). The second reason is that even if it were the right user model, I’m a single human being, and smartphones are made by massive companies with hundreds of hardware and software developers. By making this mistake twice, I spent many months developing devices that barely got past showing their first “Hello World” before hitting some critical roadblock in WiFi drivers or graphics processors that would require months of redesign work. It’s terribly disheartening, and I decided to “take a break” and design the Open Source CT Scanner as a result. Humility is important, and I definitely was in over my head with an intractable design path, and not making my mistakes cheaply at all. That’s why I liked the development of the Arducorder — a set timeframe from start to finish (5 months) with major milestones along the way, to keep it tractable and exciting.
To the sensor wishlist — a spectrometer and high-energy particle detector have been big on the wish list since the Mark 1, so I’m very excited that those are incorporated. I would love to see a small embedded laser distance measurement tool, as well as a small CCD camera with an integrated framebuffer and an SPI interface. Even 640×480 resolution would be wonderful. There are modules that are inches in size, but it would have to be down to cellphone-camera sized to be small enough to incorporate into the Arducorder.
In the far future, I’d love to see a tiny nuclear magnetic resonance spectrometer, or miniature versions of other conventional lab tools. The community has also asked for a software defined radio module many times, but I’m afraid I don’t have much experience with RF — I hope that someone will design a sensor board with this, and incorporate it into the Arducorder.
You have a machine that can do an incredible number of measurements, but for any user, simply knowing what these measurements can tell you is the limiting factor. Do you see the tricorder as simply a lab you can put in your pocket, or as something more like a Star Trek tricorder that automatically tells you what you need to know? Is it a combination?
This is a good question. There really are three components — the hardware and sensors themselves, which are capable of sensing a great many things (individually or in combination), (2) software written by folks with some understanding of those measurements (like scientists or engineers) that interpret them and give you measures, like interpreting the spectrometer wavelengths that correspond with the photochemical reflectivity wavelengths as a measure of leaf health in the video, and then there are (3) the users.
For people who already have some knowledge (or interest) in science, this is a fantastic tool, and it’s beautifully reconfigurable so that you can quickly add to the software (or hardware) to meet new applications. I’m excited to see some of the new tiles that folks come up with!
But there is this fundamental limitation in science, and in math, and statistics, and engineering, that we hammer into undergraduates — but if you’ve never been formally exposed to this material, then you may not know. And it’s that every test, every algorithm, every statistic, has certain assumptions, and if they’re not met, then the answer that comes out is meaningless. If you point a spectrometer at a television and ask it to calculate the photochemical reflection index, it will still give you a number — but if it comes out positive, it doesn’t mean that there is any chlorophyll present — one of the assumptions of the PRI test is that you’re pointing it at a leaf. Similarly, if your data isn’t normally distributed (ie. shaped like a bell curve), then you can’t use many statistics — the numbers they give you will be invalid. We hear about this all the time — people doing bad science, bad statistics. It’s like trying to translate from English to French using Google — if you give it jibberish in, then what you get out may look like French, but it will be similarly meaningless. It’s easy for us to detect this because we use language all the time, but unless you use science (or math…), you might not know jibberish when you see it. And so one of our continual tasks in science education is to teach you to recognize when what you’re seeing is valid, and when it’s not — both so that you can do good science, but also so that you can help others when they’re not (or, detect when someone is trying to pull the wool over your eyes).
Believe it or not, I think this is a fantastic thing. I think the most important lesson in science is something incredible and cool that gets the student excited, but the SECOND most important lesson is how to actually do experiments and interpret data. I want people to walk around with these devices and learn more about their worlds, and get excited. And then I want them to point the thermal camera at a metal that’s reflective in the long-IR like aluminum, and ask why they’re seeing a thermal reflection instead of the temperature of the aluminum (and, in turn, learn about emissivity and reflection). And to point the spectrometer at their cat and wonder why it still gives a number (and learn about spectroscopy, and chemical identification). I especially want kids to do this — to learn about the /process/ of good science as doing it. I want this so that they can be good critical thinkers from a young age, and also learn a fluency with these basic processes that will let them be even better scientists than we can be today.
Any scientist will tell you that 90% of science is designing experiments that don’t work out as you’d first planned. I’m a postdoctoral research fellow, which is a fancy title for someone with a PhD who spends a few years doing research before finding a professorship. Most of what I do is design and perform experiments that don’t pan out at first. The difference between me and a novice scientist is that I make many more mistakes than them — but I’m extremely good at making my mistakes cheaply, testing more alternatives far quicker, and recognizing when something is likely a true result, or when a research path is unlikely to pan out. It’s all part of exploration, the scientific and critical thinking process, and it’s wonderful!
Hypothetical, and we're not going to hold you to whatever answer you give. You win the grand prize, a trip to space or about $200,000 USD. Which one to you take, and what is your reasoning for doing so?
What would make a better story, “scientist pays off student loans”, or “scientist releases open source science tricorder, travels to space”?
The Hackaday Prize has already allowed me to cross something off my bucket list — designing and completing a modern open source science tricorder that’s incredibly capable, manufacturable, and that lets folks share their science almost instantly with others. On top of that it’s modular, and through great effort, Arduino compatible, to help make it accessible and tinkerable to a much larger community. And all of this in only five months, from start to finish. I just turned 32, and it’s incredible to think that something I’ve tried to make happen for half my life is now sitting on the desk.
For even longer — as long as I can remember — I’ve wanted to go into space. If space adventurer were a career, I’d take it! (In Canada they select two astronauts only about once a decade, and there are strict age requirements so they can get enough missions out of you to make it worth all the training. I was born in the wrong year!). How often do you get to cross two things off your bucket list?