Introduction: Micro Atmospheric Temperature Tracker
Overview
An ultra lightweight microcontroller based sensor platform. Primarily built to function underwater but with the addition of a parachute, could be used to measure air temperature and other readings from a height.
Goals
Extremely cheap sensor array Cloud connected able to balance/move in a particular y axis / depth by use of propellor.
Possibly based on a plumb line weight distribution system and a small propellor underneath to reduce falling speed.
Specifications
Intel Edison device with some sort of communication or storage device which can be dropped into any liquid and will return sensor information over time.
Sensor GIT: https://github.com/neilhighley/intel2016_sensor
REST GIT: https://github.com/neilhighley/inteliot2016_webui
Also used: Relayr, IOT analytics
Step 1: Introducing the Intel Edison and Arduino and the Project
For the 2016 Intel IOT Roadshow in London, rather than the usual sensor to facebook shenanigans, I decided to look at how the board could be utilised in an Industrial Environment.
It will need to be water resistant, as it is to be used to retrieve information from submerged areas, such as water tanks.
The Arduino breakout board that comes with the Edison allows us to leverage our current Arduino skills in programming the Edison. It basically, allows arduino-centric designs to utilise the extra power of the Intel Edisons Xenon chip.
So, after unpacking, assembling, and installing the requisite beginner packages, hook up your edison board via the Serial USB cable, and obtain the following components;
1. Sunfounder Thermistor
2. Sunfounder Photoresistor
3. Sunfounder BMP180 Barometer
4. HC-SR04 distance detector
5. A 6 AA Battery pack
6. A box big enough for the whole Edison Arduino breakout and the batteries
Also, items to waterproof the box and sensors. Such as a glue gun, gaffer tape, PVA glue, etc
Step 2: Prepare Your Software
To make things a little spicy, I decided to use Johnny-Five, which is a popular IOT/Robotics library for Node.
Unfortunately, ito utilise the HC-SR04 sensor it requires NodeJS 12+ and the package that comes with the Edison is only 10, so you need to compile the package for the board, on the board.
{code}
wget https://nodejs.org/dist/v0.12.5/node-v0.12.5.tar.... --no-check-certificate
tar xvf node-v0.12.5.tar.gz
cd node-v0.12.5
./configure make make install
{code}
Thanks to: https://communities.intel.com/message/314636#31463...
..after around 2 hours... Your nodejs install will be up to date.
Install galileo-io and johnny-five using npm on the board using Serial/SSH
... Well, after a few hours it became apparent that mraa didn't like node. This seemed to fall straight down into johnny-five. So, ultimately, i went back to the 0.10.38 version of Node by reflashing the intel board. It was really easy to do, so it wasn't that bad.
What this meant was that I had to revert to standard GPIO gathering from the sensors. Again, not that bad, just felt a little clumsy.
Step 3: Software Studies 101
Our board is now ready for coding.
For the NodeJS code, I created methods which called the IOT procedures in Johnny-Five, but made them so that I could continue working on it while NodeJS installed on the board.
I created a fakeFactory, which passed fake objects, which in the fully updated system, would return the Johnny-Five objects, but for testing and development, would return test data.
e.g.
{code}
var getFake=function(name){
switch(name){ case 'Barometer': return { getPressure:function(){ return 1; }, getTemperature:function(){ return 1; }, getAltitude:function(){ return 1; }, getSealevelPressure:function(){ return 1; } }; break; case 'Sonic': return{ getNearestObject:function(){ return 1.234234; } } break; case 'Photo': return{ getPhoto:function(){ return { red:0.122, green:0.234, blue:0.5656, other:0.234 } } } break; default:return {}; }
}
{code}
This was a good plan, as it turned out that Johnny five and the latest Yocto were not good bedfellows.
This meant that it was easy enough to substitute the appropriate methods. Yay for Object orientation.
Step 4: Hardware for the Ambitious 301
Once you have the components, take a look at the appropriate instructions at Seeed studios site, and place them on a breadboard, so you can organise the ground and voltage.
You can minimise everything later with scissors and wire.
Step 5: The Barometer
The barometer was a Seed studio BMP180, and did the job admirably. The sample code for data retrieval can be found at the following link.
Step 6: The Distance Sensor
to be added..
Step 7: The Photresistor
to be added...
Step 8: The Thermiresistor
to be added..
Step 9: Testing the App
Test that all the sensors are returning valid data.
Wave things around, cough on them, etc.
Step 10: To the Cloud, Alice
Now all the components are working, we should ensure that we can send the data somewhere that it can be saved.
For this project, I will be sending it to a bespoke NodeJS application on Heroku, which will forward it on to a relevant cloud service and allow another application to retrieve the filtered data.
The reason I have this extra step, instead of sending it straight into a cloud service is to allow me to change my mind and the service it will send it to if needs be (*cough* time contraints).
I will create a simple dump for the data, in memory in my NodeJs App at first, so that I don't waste needless time fiddling with third party services. Plus, I will be able to run it locally if the wifi goes down (*cough* almost entirely likely).
The application will have two REST endpoints, one will receive packets of sensor data, and the other will return a snapshot of the data based on a filter specified.
e.g.
http://myapp.local/upd/:packet
will listen for formatted JSON objects
and
http://myapp.local/out/sensor/:filter
will return a JSON collection with a subset of the data.
Github: https://github.com/neilhighley/inteliot2016_webui
As I mentioned, this is set up to return fakes until the sensors are sending data and the app is saving it.
This also means that it could be done by another member of the team while I get on with the hardware tinkering.
An alternative I found good for testing was http://docs.relayr.io/
Step 11: Aqua Maria!
As mentioned earlier, the project needs to be water proof. As such, I have utilised the most common ways of waterproofing, namely glue and gaffer tape.
I drew a net of the box I was using to plan where the sensors go. Its going to be difficult to waterproof every component, so don't take this as a finished product, and proceed at your own risk, as any water will destroy the components inside the box. Also, once its waterproofed, it will most likely never be opened again.
My prototype used the Arduino breakout but I expect a manufactured version would forgo most of the arduino cruft for a small, modular circuit board.
To avoid the batteries running out, a plastic slip could be added to prevent the battery circuit until the last minute, where it could be removed and glued up.