Category: Sensors

I’ve just put in a Seeed order for some more Grove sensors (because they’re very easy to set up and use). Here’s what I’m thinking of doing with them:

• Collect the usual environmental data – air quality, dust, temp/humid, water, alcohol – and compare against readings from the same sensor set that’s in the Brck office.
• Wildlife detection using motion sensor, mike, and camera unit.
• Investigate fire/smoke effects using smoke and gas sensors; I’m more interested in effects of different types of cooking fuels in houses, but could adapt this for camping too (a group I belonged to lost a member to fumes in their tent, so this is of value to me).
• Human monitoring using alcohol detector and galvanic skin response (e.g. sweat density) monitor.

I’m also thinking about what sort of UAV or balloon data would be useful from a short trip.

• Even 10 minutes of data would be good – especially if it’s a) messy (e.g. oblique), and b) contains features like buildings
• Although 10 minutes of nice clean stabilised downward-looking is also a good thing to have: garbage in, garbage out really does apply to aerial images.

[cross-posted from sensornews.com]

I’m at the iHub Nairobi today with a bunch of sensors (thanks for the loan, Brck team!), because some of the Kenyan ideas for today’s Space Apps Challenge projects are sensor-based.  Those projects didn’t happen, but I’ve been having some very interesting chats with people about the hardware we have here, about their own use of hardware, and about why coders aren’t including hardware in their projects.

Aside from utility (not every project needs sensors, just as not every project needs a web interface), the two big blocks appear to be unfamiliarity and fear.  First, the fear: generally that using hardware will be hard to learn, or that you’ll break equipment irreparably.  And the familiarity: coders are used to software, and hardware can seem very different to software, at first.

The fear: I suffered from these fears too, as I got back into hardware.  That combination of “oh grief I’m going to break it” combined with “but what could I possibly do that’s useful with this stuff”.   The answer is really quite simple.  Buy some kits, start putting them together, and learn from that a) what works and doesn’t, b) why, how, when hardware is useful , and c) how to make your designs more useful.  Yes, things break; no, the outputs aren’t always perfect, but the point of using kits is to learn, and fast.  If that sounds familiar, it’s because it’s the same ethos that drives agile software development: build, fail, learn, build better until it fits what you need.

And speaking of familiarity: electronics is really coding with things.  You have basic units (components), basic things you can do with them (connect together, run voltage through them, read outputs from them etc), that you design together into a working system.  And if you’re using microprocessor-based kits (Arduino, RaspberryPi etc), then you really *are* coding, because you’re programming the microprocessor to send signals, respond to data inputs etc.

I’m doing this the easy way.  I’m starting with components that slot together and have code that’s already written for them: the grove sensor series.   The kit you need to start getting sensor results with these is:

• Arduino Uno (or clone) – $30
• USB cable: USB type A to type B– $2
• Grove base shield – $9
• Grove sensor (any type) – $3 upwards

Erm, that’s it.   You’ll need to download the basic Arduino software, and find the example code for your sensor in somewhere like the Seeed wiki, but  for about $45, you too can start experimenting with sensor data. I’ve just left a stack of Grove sensors and a couple of Arduino Unos at the Brck Nairobi office; I’m using the same stack in New Jersey so we can compare results and ideas.   We’ve already got data from this experiment – proving that the Brck office is dustier than the Ushahidi office nextdoor isn’t a great leap forward in knowledge, but taking these sensors out into the field, and getting comparable data from places without good coverage from ‘official’ air quality monitors is.

The journey from here involves lots of placing sensors and learning how they fail, what they do under stress, and what their limitations are.  It’s also, ultimately, to start reducing the number, size and price of components needed to produce usable and useful sensor data, to learn from pioneer communities like Public Laboratory and RiverKeeper, and to make it just ‘normal’ to include sensors in system designs and ‘normal’ to plug them into existing equipment like Brck and mobile phones (I have a Geiger counter that plugs into my phone’s audio port – I’d love to see more of that sort of reuse out there).

And now, back to thinking about questions like “could you build a gas sensor into your clothes”.  I just happen to have an MQ-5 gas sensor in front of me, and am thinking about what it would take to get from there to an alarm ringing on my phone…

[Cross-posted from Sensornews.com]

Here’s the list of items that should arrive at home soon: a basic sensor set to supplement the Geiger counter, spectroscopes, cameras, microcontrollers (Arduino and RaspberryPi), accelerometers, temperature, IR and range sensors in my toolkit.

I’m most excited about the dust sensor because it’s it was a component in Matt Schroyer’s DustDuino sensor (as seen on PublicLab.org) that’s being trialled in the developing world by Internews’ Earth Journalism Network… will be interesting to see what I can get out of it.

“Sensor. Noun. A device that detects or measures a physical property and records, indicates, or otherwise responds to it.” – Google

A sensor detects physical variations in the world, e.g. light, temperature, radiowaves, sound, magnetic fields, vibration, particles (e.g. pollution, radiation) or objects (e.g. water droplets).

Humans contain Sensors

Humans and other creatures contain sensors: eyes, ears, nose, tongue, skin.  Humans are very good general-purpose sensors:

• They detect noise over a wide set of frequencies, both with their ears and with the rest of their bodies (e.g. the deaf percussionist Evelyn Glennie accurately tunes her drums by ‘hearing’ with different parts of her body)
• Their visual systems see the world in high resolution at roughly 60 images per second (which is why films, games and light fittings are updated at the rates that they are), in stereo that gives decent depth and motion detection (although optical illusions mess with these beautifully)
• And similarly for smells, tastes and skin.

These sensors are sometimes used in sensor journalism, but so too are manmade sensors like cameras, motion detectors and thermometers.

In many situations, manmade sensors are more appropriate:  humans tend to fail the “dull, dirty, dangerous” test: their attention wanders on boring tasks, and it’s not fair to put them into dirty or dangerous situations where a manmade sensor would be more appropriate; they also can’t detect much of the physical world -e.g. radiowaves – without help, and their outputs aren’t always accurate enough for the task in hand.

Manmade Sensors are Old News

Manmade sensors convert common physical quantities (light, temperature etc) into measurements, actions or stimuli (sounds, light etc).  Manmade sensors have been designed and used for centuries, including:

• Seismometers for motion (Heng, 132AD),
• Thermometers for temperature (Galileo, 1593),
• Barometers for air pressure (Torricelli 1643),
• Gyroscopes for orientation (Serson, 1743),
• Cameras for light (Niepce, 1816),
• Microphones for sound (Wheatstone, 1827)
• Geiger counters for radiation (Geiger and Muller 1928)

Low-Tech Still Works

One area of journalism where sensors are commonly used is weather reporting.  At the low-tech end of modern weather recording is a Stevenson screen with manually-read instruments.  A Stevenson screen is a wooden box designed in 1864 to shelter a thermometer from direct weather (rain, snow, wind) and other objects (leaves, animals) that might damage the instruments inside it or bias readings from them. Stevenson screens are used for weather reporting worldwide, and contain instruments like:

• a dry-bulb thermometer (for temperature),
• hygrometer (for air humidity),
• wet-bulb thermometer (also for air humidity, when combined with dry-bulb thermometer readings; also available as a combined wet- and dry-bulb thermometer known as a psychrometer [Kilby 1993]),
• dewcell (for dew point),
• barometer (for atmospheric pressure),

Stevenson Screens are a good example of the care needed to obtain minimally-biased sensor readings.  The box and its positioning is standardized by the World Meteorological Organisation, to minimize instrument bias, e.g. all boxes are mounted 1.25m high to minimize ground temperature effects, louvred to minimize the effects of still air (e.g. overheating), and with doors opening North, to minimize reading errors from direct sunlight.

But Electronics can be Convenient

Each of the instruments above has an electronic equivalent, e.g. a sensor that can provide data remotely without a person needing to visit the Stevenson screen.  Digital sensors (sensors that convert physical quantities into electrical signals) are more recent, including digital cameras (Sasson 1975) and other sensors whose outputs can be sent to electronic storage, over wifi links or directly to computer processors.  We’ll talk more about these later.