GreyhoundSensorRig

AKA, Quantified Dog

AKA, Dissertation Data Collection

Overview

The goal of this project is to build a test rig to mount all of the sensors that I want to use to monitor biodata from dogs providing social services on. The test rig will be for use with my greyhounds. The aim of this project is to see whether this is a feasible project, what kind of data can be collected, and if this system might be useful as part of data collection for my dissertation project.

Components in Bin

Vendor List

Seeed Studios, Canada Computers (for power bank), Creatron (for data shield)

Progress

  • July 13
    • I was glad that I tweeted my sketch-up, because I managed to lose my hard copy
    • pulled out all the components that I need for this project, tested and not: Arduino and base shield, data logging shield, power source, GoPro, heart rate sensor, 2 3-axis digi accelerometers
    • plugged in power source and GoPro to charge
    • Hello World tested the Arduino (same as here)
    • test successful!
    • plugged in Grove shield
    • went back to the accelerometer wiki, and plugged in one accelerometer in I2C port
    • test successful!
    • started researching connecting two I2C sensors on the same base shield
    • decided to throw the extra accelerometer into the bin for now and Email Grove support
    • went to the loudness sensor wiki to test
    • test successful!
    • learned from sen that it would be possible to use a digital accelerometer and an analog one simultaneously on the Grove shield, so decided to test the analog accel
    • accessed the analog accelerometer wiki
    • for reference – pins on Arduino, L to R w power source to the left: unmarked, ioref, reset, 3.3V, 5V, GND, GND, Vin / A0, A1, A2, A3, A4, A5
    • calibration of analog accelerometer threw errors that I’m not sure how to fix, so I’m going to test the heart rate monitor and add this to the to do list for next time
    • testing the ear clip heart rate sensor, this time with blue LED
    • code was not functional – demo code was for chest strap sensor
    • also checked w code in the PDF manual, and same outcome
    • will try to see if I can find demo code for this next time, not sure why it’s not working this time when it worked fine before?
  • July 21 (with help from sen!)
    • troubleshooting the heart rate sensor – sensor cord wasn’t plugged in all the way, once plugged in it worked just fine
    • calibrating analog accelerometer just didn’t throw errors this time (no idea why)
      • once the calibration was complete, had to edit the library file as indicated on the wiki, which was located in Documents>Arduino>libraries>AnalogAccelerometer>ADXL335.h
    • testing the data logger shield
      • important!: The RTC Data Logger Shield v1.1 makes use of pin 4 as a chip select. Please be sure other stacked shields do not make use of that same pin.
      • tested using File>Examples>SD>CardInfo
        • test successful!
      • testing the RTC using File>Example>RTC>RTC
        • test successful! Note that in the example sketch, “RTC is NOT running!” actually just means that the RTC is initializing (ie, getting the time from the computer)
  • July 26 2016
  • today’s mission is to figure out how to begin connecting all these sensors together! it’s an adventure!
    • started by stacking all the shields, and pulling up the wiki page for the digital accelerometer and the data logger shield
    • quickly realized that I have no idea how to write data to the SD card using the shield, but found that there was a data logger example in the Arduino software, and a little tutorial online that I could use as a starting point
    • decided that in this case, I’d start with the analog accelerometer, since the data logger example was for use with three analog sensors
    • modified the data logger code to include the library for the accelerometer
    • things that I read/learned trying to write this code:
      • googled “CS pin” – summary: “In short, the chip select is an access-enable switch. “ON” means the device responds to changes on its input pins, and drives any output pins (possibly not at the same time), while “OFF” tells the device to ignore the outside world for both inputs and outputs.”
      • CSV file = comma separated values file, which sen said that “it’s the simplest data format that basically everything can load (excel/openoffice/Google sheets/kst2/etc)”
      • re: where to put the things in the code, from sen: usually at the top of loop() you would have the bits that fetch data from each of your sensors and puts it into variables, then below that you’d have the datalogging part that turns that data into a string and puts it on the SD card, then you’d usually wait X amount of time (like a second, if you want to log data once a second)
    • downloaded the measuring acceleration demo code
    • integrated the measuring acceleration demo code and the data logger code into the sketch Integration 1 and saved it after successful verification!
  • August 3 2016
  • continuing to work on integration code w helpy help from sen
    • tested the Integration 1 code with the hardware, and successfully pulled values from the analog accelerometer to the SD card
    • sen troubleshot my code and pointed out that in the data logging loop, I was pulling the wrong data from the sensor to write to the card (String(sensor) versus String(ax), String (ay), and String (az))
    • modified the code to write the proper variables to the SD card, and saved as Integration 2
      • in this version, there is no loop through each analog pin, because the variables are individually identified, so there’s no need to go through the pins one by one
    • tested Integration 2, and totally worked. yay!
    • pulled the demo code for the digital accelerometer from its wiki page, and tried combining it with Integration 2. threw some errors because I was doubling up on variables, which was easy enough to fix, and sen pointed out that I didn’t need to include serial.println for each sensor, because that was already happening through the data logging shield at the end of the code. removed all the extra instances of that, which simplified the code significantly. re-saved as Integration 3.
    • once I simplified the code and fixed the variables, Integration 3 verified!
    • in order to have the data from the digital accelerometer logged by the data shield, I attempted copying the data logger code for the analog accelerometer, and modifying the variables (ax, ay, az) to those relating to the digital accelerometer (dax, d_ay, daz)
      • saved as part of Integration 3, and verified successfully
    • Integration 3 uploaded just fine and was showing data in the serial monitor (yay!), but there were a bunch of unidentifiable zero values, so not ideal
      • data pulled from the SD card was the same
    • sen found a couple of more variable problems, so I fixed those and tried again
    • data from the analog accelerometer worked fine this time, but the digital one was still throwing zeros, so I ran the example code for just the digital accelerometer to make sure it was working
    • when I ran the demo code, I still got only zeros, and sen noticed that the data logging shield was missing pins to allow the I2C data to get to the Arduino. first step for next time will be to retrieve some jumper cables from my Hacklab bin stash, and jump the I2C pins down to the Arduino (skipping the data shield), and then it should work just fine
  • I feel like it’s worth memo-ing at this point that next time I decide to work on a project with a new coding language, it’s *probably* worth the ten or so hours at the beginning to do a quick tutorial and learn some of the language first. sen is helping me skip lots and lots of steps just by being more C-literate than I am right now, and that probably could have been avoided.
  • August 7
  • continuing to work on integration code w helpy help from sen
  • today, starting with heart rate sensor!
    • Memo: Things that basic wikis should tell newbies that would lower the barriers to entry: when you plug in multiple sensors to a shield, you don’t need to unplug everything to test them. you can test one at a time.
    • tested the heart rate sensor with its own code, and it worked fine
    • with some help from sen, I integrated the heart rate sensor code into Integration 3 (saved as 3b), and it verified on the second try! (I still feel victory EVERY time I don’t throw a thousand errors)
    • commented out all the Serial.println, except Serial.print(“Heart_rate_is:\t”); Serial.println(heart_rate); to simplify the code
    • after asking sen, I added the heart_rate variable to the code where the data shield is pulling data from the sensors, and everything verified properly: Integration 4!
    • next step – test to make sure everything is working properly
  • September 4 2016
    • successfully tested loudness sensor using test code from wiki
    • switched data logging shield and Grove base shield (temporarily?) to deal with the I2C pin problem described above
    • tested digital accelerometer (successfully) using example code
    • integrated loudness sensor code, saved as Integration 5, which verified on the second try!
    • tested Integration 5 (all sensors!) with the data logging shield, and everything logged successfully!

Post-Proposal Approval Redux (Progress 2)

  • January 17 2017
    • uploaded Arduino sketch from September 4th and everything appears to be working as well as it was before, which is great
    • checked the SD card and it had logged data
    • tested the heart rate sensor on Kiki Hacker. Good news: she didn’t mind wearing the ear clip. Bad news: she was too floofy to have a heart rate.
    • cleaned up the code and comments so that it’s more understandable
    • tested the heart rate sensor on tiny dog Wren. Only bad news.
  • February 16 2017
    • consulted with ABC friends re: dog-friendly heart rate and other biodata sensor options
    • checked online and conductive rubber and CR1220 coin cells (the batteries required for the RTC in the data logging shield are CR1225s, but these should work) are both available at Creatron
    • removed the heart rate sensor from the hardware and commented out the code (for potential future use with humans)
      • learned to comment out blocks of Arduino code by doing “/*” at the beginning of the block and “*/” at the end of the block, rather than // at the beginning of every line
      • code verified correctly, saved as Integration_6 on desktop
      • updated Git
    • did a Hello, World! test with the Grove LEDs (LED was doin a blink)
    • next steps:
  • March 9 2017
    • Tonight, I’m just musing about some things. I was considering if I’m missing any sensors that it would make sense to add to this package. I thought about temperature sensors, but sen pointed out to me that there would be a lot of pollution from environmental temperature changes that would probably mean that the data wouldn’t be meaningful. I thought about maybe taking temperature readings throughout with like an ear thermometer or something, but I think that then the data would feel less meaningful, in that it wouldn’t be as organically created by the dog and the environment – there would be a lot more interference from me. I think in order to feel like I’m being genuine to the research-creation methodology, I want to sort of just let the dog and the environment do their thing, and to have the data to look at afterward. It does occur to me, though, that the loudness sensor is going to have similar levels of pollution from the environment (even though I guess sharp peaks in loudness can be more easily interpreted – barks – than sharp changes in temperature can). I’m browsing the Seeed website, and the only other thing that sticks out as even really having relevance could be a light sensor? I’m not sure what that would tell you, other than adding another environmental data point. Could be worth it, if it’s easy to get? The only thing is that all of the other sensors have to do with the dog. A light sensor would be the only environmental sensor to not have any sort of interaction with the dog.
  • April 15 2017
    • tested the conductive rubber as a breathing sensor using a multimeter, but unfortunately the rubber isn’t sensitive enough to measure the resistance of breathing in a meaningful way.
    • integrating indicator lights
      • re-tested Hello, World with Grove LED, and it worked just fine
      • for each sensor, I want an indicator light that will turn on when the sensor starts sensing some kind of meaningful data
        • three sensors: digi accel, analog accel, and loudness – for accelerometers, the data is output in units of g (where each g is 1x the force of gravity), so this would be +-1g, and for loudness it looks like a reasonable bar is anything above 10 (it looks like this is measured in volts, which I don’t know a ton about)
        • using this resource as a starting point for the code
        • tip: (fr sen) double pipe (||) is an OR operator in Arduino code
        • removing heart rate sensor code because it’s not useful and it’s in my way, so that’s going to be gone in Integration 7
        • using analog accelerometer for first test
        • commented out some of the analog accelerometer setup code where variables x, y, and z were being created, because they don’t seem to be being used for anything
        • on first test (code verified and uploaded fine), no matter what values I give to the variables (tried 2 and 500), the LED is always on. tried troubleshooting and no luck, going to try with the same LED (pin 2), but loudness as test sensor since I have much more control over the data that gets picked up
        • second test, same thing
        • sen suggested commenting out the LED code to see if the LED still turned on, and it did. so something other than the LED code is using pin 2
      • next step: figure out what is using pin 2, and if I should use another pin for the LED, or if this can be adjusted
  • May 14 2017
    • Today, I’m creating a to do list of what needs to be finished on this sensor package so that I can get an idea of when I can begin recruitment for this study. I had considered adding additional sensors. Below are the criteria I used for additional sensors. I found no additional bio sensors that fit these criteria. However, I did find some additional environmental sensors (temperature, light).
      • available (plug and play, through Grove)
      • affordable
      • would give data that seems meaningful to a dog’s experience in a therapeutic environment
      • would be feasible for non-invasive use with dogs
      • would be non-invasive to human service users in a therapeutic environment for data collection
      • would comply with what I had approved through the REB
        • Memo: It’s interesting that when I started off this project, I really wanted to focus more on biodata, and the environmental was just going to be kind of icing. However, given the constraints of the project and taking into consideration the priorities I set about being non-invasive, I’m really ending up focusing more on environmental data. It’s making me wonder if some of the reading that I’ve done (especially around cyborgism, etc) isn’t going to be a bit superfluous in the end, and if I should be looking more at theoretical texts around a slightly different kind of analysis.
    • the following are the steps that I need to complete in order to be able to begin using the sensor package for data collection
      • (2) first, through looking at the package to compile this list, I determined with advice from sen that I had mistakenly attached my analog accelerometer and my loudness sensor (also analog) to the same analog pins on the Arduino – this maybe explains why the indicator LED wasn’t working, since I had been testing it with the analog accelerometer, so I need to go back to my code and make that adjustment so that I can move the loudness sensor so that both of these will work. so that’s step one (but actually step two, because it’s harder to do than ordering, which comes next…)
      • (1) order additional sensors (temp, light)
      • (3) add additional sensors to the code
      • (4) add indicator LEDs to all five sensors
        • (5) create physical attachments for these
      • (6) create physical attachments for all lights and sensors
        • (7) add velcro and elastic to tail accelerometer
        • (8) attach loudness, body accelerometer, temperature, and light sensors and indicator LEDs to the harness
      • (9) organize cables, make a case for the Arduino package
      • (10) test the coin cell battery with the RTC
        • (11)make sure that the timestamp is being recorded with the data in a single file on the SD card while the package is running
      • (12) test entire package
  • May 14 (continued)
    • Step One: Ordering Additional Sensors
      • Memo: Once I had shifted my focus to environmental rather than biometric sensors, there are a lot more things available. Cost of CO2 sensors was way too high. I looked into an air quality sensor, but it’s an analog sensor and I don’t have any analog pins left. this doesn’t seem like the highest priority sensor to me, as it’s unlikely that there would be wild variations in air quality in relatively contained environments. sen pointed out that it uses a lot of power as well.
      • in the end I decided to order (based on availability, cost, perceived usefulness, compatibility with existing package – particularly in terms of not having any analog ports available) the parts below, allowing me to add temperature, humidity, barometric pressure, and light measurements to my data collection
    • step one complete! eleven steps remain…
  • May 19
    • After reviewing the first few recruitment Emails, I’m going to have to add a step 13 to modify this package to be usable with smaller breeds of dog – so far no one who’s contacted me (of 13 Emails) has a large breed. this could be tricky!
  • September 5
    • I have been taking memos in a separate document, and plugging away on things like recruitment and initial interviews for this project. However, in the shuffle of things, I lost track of time, and my first site visit for data collection is this coming Monday! I’m excited, and also, I need to get this sensor package functional. Luckily, the dog that I’m visiting for the first set of visits is a medium breed dog, so I don’t need to miniaturize just yet. That said, here is my (new, condensed) to do list for this coming week (!):
      • (1) put analog accelerometer and loudness sensor on different pins on the Arduino so they will both work
      • (2) add the following sensors to the code
      • (3) create physical attachments for all sensors, including velcro and elastic for tail accelerometer
      • (4) organize cables
      • (5) test the coin cell battery with the RTC
      • (6)make sure that the timestamp is being recorded with the data in a single file on the SD card while the package is running
      • (7) test entire package
  • October 23
    • I am returning to this in a long-overdue kind of way, as I have my first data collection visits in a week and a half, so I’ll be banging through this to do list in the next few days, as well as attempting to miniaturize the package and harness so that it can be used with dogs who are quite smol
    • To Do list progress
      • (1) moved loudness sensor to analog pin 3, altered code (analogRead(3)) to reflect the change
      • (2.1) adding temperature and humidity sensor to the code
        • the example code provided here didn’t work, because it uses an analog pin for input, despite being a digital sensor, and as evidenced by point 1 on the to do list, I’ve already used up my analog pins (which is why I ordered a digital sensor on purpose)
        • in order to change to using a digital sensor, I asked for help and learned that this code is not well-written in terms of entry level usability. It’s written this way in order to talk to the chip quickly. The code avoids the digitalRead command, which would be too slow, but it’s also sloppily written. The port is not defined at the top where the chip is defined, it’s rather hard coded throughout, making it more difficult to change. In this case, I’m just going to change it throughout, because I’m not going to go back to use the chip as analog for this project, but the sample code itself would be easier to use if it was written more cleanly.
          • Note: DHT11 is the sensor that I’m using, and I’m using digital pin 5
      • Memo: TIL: It’s not just Seeed that provides resources for various sensors, even though the Grove system that they’ve created has the chips mounted in a really easy-to-use way and has created the shield which really facilitates this. Adafruit provides this same sensor (DHT11), and the code provided by them includes a library that makes it much easier to use. A note for future is to look for Adafruit sample code first, because theirs is usually higher quality at an entry level than what is provided through the Seeed wiki. Adafruit puts a lot of effort into this, as a company, and that’s probably why their code is more accessible.
  • October 29
    • Tonight, my goal is to finish integrating all the remaining sensors. Good luck, me.
    • To do list item 2.1 continued!
      • this time, I’m starting with the Adafruit tutorial on connecting to a DHTxx (in this case, x=1) sensor, found here
      • Code integrated, added to the data string for the data logging shield, and verified
      • Item 2.1 complete!
    • Note: I definitely did not get through all of my sensors tonight. What I DID do was create this guide to how to integrate open source sample code for individual components into a sketch for one coherent project. While this did slow me down big time tonight, it will hopefully speed up my process in the future… and maybe also remove some barriers for other people just starting out. ¯\_(ツ)_/¯
  • October 30th
  • I am now working from the sketch file Integration_8
  • (2.2): Integrating the Grove barometer
    • found Adafruit tutorial on the barometer sensor
    • tested sensor using sample code
    • integrated code
    • learned that you don’t have to define pins for I2C-connected components, which is neat
    • after troubleshooting with sen’s help, barometer code verified (no loop needed, no variables defined – need to look more into this when I have more time)
    • Note: I’m only using the barometer for pressure, as altitude is difficult to measure in different locations, and I’m already collecting temperature data from the temp and humidity sensor
  • (2.3): integrating the Grove digital light sensor
    • chip on this sensor is the TSL2561, also connects over I2C
    • also using the Adafruit documentation for this one – so far, so much nicer than trying to navigate the Seeed wiki. I’m glad that exists, but leaves much to be desired.
    • ran the test code, and I’m just getting “sensor overload” all across the serial monitor
    • checked with sen, who suggested changing “FLOAT” to “LOW” in the line that reads “Adafruit_TSL2561_Unified tsl = Adafruit_TSL2561_Unified(TSL2561_ADDR_FLOAT, 12345);”
      • from sen: “on the Adafruit board they connect the “address” pin of the sensor to an actual pin on the board so you can control it, it lets you change the address of the sensor, on the Grove board they for some reason connect it to ground and don’t let you change it, it doesn’t really make sense to me why they would connect it to ground, but they did so you have to tell the library that it’s connected to ground, otherwise it talks to address A but the sensor is actually listening on address B, so they can’t communicate”
        • without this feedback, I would have been looking for a different example code to use, so I was grateful for the technical support!
      • Memo: I really need to learn how I2C works – I think that this is a huge weakness of mine right now
    • while integrating code, I included the configuration code in the setup, but it’s noted in the Adafruit guide that the auto-gain is experimental, so if it ends up not working, I may need to switch to a static gain in the future
    • Okay. I’m deciding to remove the light sensor for now. The data is observable, if less precise, and the code is much more complex than I anticipated. I may return to this sensor if I have time before my visit on Wednesday, but I may not.
    • Removed light sensor code, other code verified no problem
    • Calling to do list item 2 done!
  • (3): create physical attachments for all sensors, including velcro and elastic for tail accelerometer
    • the first step of this is to finish the tail wagging sensor. at this point I don’t have a cable that’s long enough, and I don’t have a soldering station at home. so I have to figure that out.
    • harness and bags have been located, power supply is ready to be charged, I’ve put together the SD cards and the coin cell batteries for the data logging shield
    • found random blue LED modules attached to digital pins 3 and 4, not sure why? removed. removing light sensor for now as well.
    • item 3 still has some sewing and cable-making in order to be finished, but that will be done tomorrow night at the maker space
  • (4) – done!
  • to do tomorrow: finish 3, plus 5, 6, 7, and then it’s ready to go!
  • October 31
  • slight change of plans. I have decided not to include the tail sensor in the iteration of the package that I will use for data collection. The reasoning for this is twofold. One, there does not seem to be a way to attach the wire for this sensor that is non-invasive to the animal involved. Two, whether or not the dog’s tail is wagging is observable data. While it may be possible to collect this data using a wireless accelerometer and an additional Arduino shield, this is beyond the scope of my current abilities and also would add to the bulk of the sensor package, which is already somewhat cumbersome for a small dog. Instead, I have opted to connect both accelerometers to the existing harness. One to the chest piece and one closer to the back of the harness. This way, I will collect as much data as possible, using the least invasive methods available to me.
  • sen explained some I2C things to me. A simple explanation can be found here
  • also, it turns out that integrating the light sensor wasn’t as complicated as was originally thought. yay!
  • last items to finish are:
    • (3) create physical attachments for all sensors, including velcro and elastic for tail accelerometer
    • (4) organize cables
    • (5) test the coin cell battery with the RTC
      • went back to the Elecrow page on the RTC and used the example code to set up and integrate the RTC into the full integrated package (still on Integration_8, btw)
    • (6) make sure that the timestamp is being recorded with the data in a single file on the SD card while the package is running
      • In doing this, I also decided to organize my data string for the SD card a little better. The order that I’m writing the data is:
        • date and time
        • light level (in lux)
        • temperature and humidity
        • barometric pressure
        • analog accelerometer (positioned on the back)
        • digital accelerometer (positioned on the chest)
        • loudness
    • (7) test the whole package!
      • “voltage”
        • for some reason, in my serial monitor, between lines of data, I’m getting something that says “voltage”, followed by three random numerical values. I couldn’t at all figure out where these were coming from, so sen hypothesized maybe one of the accelerometers. Ze looked into the libraries of each, and sure enough, one of them has some superfluous code in there that means that it throws extra data. It’s fine, and doesn’t show up on the SD card.
      • light = 0 (oops)
        • my light value in the data string kept coming up zero. Turns out it was because I hadn’t plugged in the physical sensor, at all. It was still in my bag. Oops.
      • life in the future: my pen will remember that for me
        • I was thinking to myself, in order not to turn the package on and off, I should just turn it on once when I arrive, and then leave it running, and keep notes of what time I start and end observations. And then I realized, I don’t have to remember that, because we live in the future, and my pen will do that for me.
      • adding an indicator light for the SD card
        • after I tried testing and the SD card didn’t initialize properly, which I only realized because I had the serial monitor open, I realized that I should have an indicator light for the SD card initialization. So that’s added.
      • after I added the indicator light, the code was throwing random errors unrelated to anything that was just edited… sen suggested I make sure to double-check the sections I did edit to make sure there aren’t any extra open or close brackets hanging around. There were. =P
      • every light involved in this project happens to be blue, including the power indicator on the power source. So satisfying. Matchy matchy.
      • last but not least, the power source
        • For some reason, when I turn it on, using the power button, it just turns itself off a few seconds later. Tried plugging it into my cell phone and turning it on, and it didn’t turn off randomly.
        • As I originally guessed, the Arduino package isn’t drawing enough power to let the power supply know it’s being used, which is why it’s just turning off. I will need to pick up a new, more suitable power supply in the morning.

…but other than that, this project is pretty much done. There will be some modifications to be made for smaller dogs, but from here on out, my memos and documentation will continue in my research journal. Thanks to anyone following along at home. I’m nervouscited to mark this project complete… as complete as any project ever is in the wiki-verse anyway! The final version of the code for this project can be found on my GitHub. Special thanks to the Sherman Centre, and to sen, and to my very patient greyhounds, D and Boom, without whom this project definitely would not have been possible. <3