Ash Tyndall

January progress update

2015-01-18T00:00:00+08:00

In the last few weeks I’ve been really getting into the meat of the project; the circuit has been designed and implemented (see Figure 1) and fairly stable software has been developed for the Arduino to allow it to send the temperature information to the connected computer.

A Python library for the parsing, analysis, recording and visualisation of the sensor data has been developed; currently unimaginatively named “thinglib”. You can part of the visualisation in operation in Figure 2. Hopefully it’ll get a better name when the project does.

Figure 1: MLX Arduino Circuit

The above circuit diagram was developed from the actual breadboard connections, and hopefully is an accurate representation of how that all plugs together.

Figure 2: Whole System

a) "thinglib" temperature visualisation
b) Raspberry Pi with built-in camera
c) Sensor circuit

To allow for the simultaneous capture of visual and thermal data, I’ve stuck the sensor and a Raspberry Pi to the same piece of board, close enough hopefully to eliminate most FOV issues.

Figure 2: Circuit Closeup

a) Sensor itself
b) I2C level shifter
c) Arduino Uno R3

In the current design the sensor sends the calculated raw temperature over serial to a computer where “thinglib” parses it and visualizes it.

Figure 3: First Sensor Test

This is the first test I did of capturing both the thermal data from the sensor and the visual data from the Pi, then overlaying the two. They’re not overlayed correctly, and it goes pretty badly out of sync at the end, but it’ll be a useful debugging tool.

Figure 4: Deviation Code Test

This is a test using a cup of hot water of the standard deviation calculation code which is used to separate the “thermal background” from the image, so that analysis can be performed on the image results. Currently the extraction of the feature vectors required for the classifier techniques is complete, so now the question is to implement the classifiers.

Much is left to do.

January progress update was originally published by Ash Tyndall at his personal blog on January 18, 2015.

Useful tips for writing a thesis in LaTeX

2014-09-19T00:00:00+08:00

These recent weeks I have been working on the literature review section of my thesis, and while doing that I’ve been trying to use LaTeX packages to make that experience as easy as possible. I’ll outline some of the things I’ve done here.

Use `subfiles` for a modular thesis

The first thing I realised was that my thesis is going to very quickly get unwieldy if it is all contained in one document. I did some research, and I found that the subfiles package was well suited to my situation.

subfiles allows you to have separate LaTeX files for different chapters, while allowing you to still compile both the chapters separately, and the whole document. This is great, as while I’m working on the literature review section, for instance, I don’t want to waste my time compiling my whole thesis document when all I care about is one section.

This is the directory structure of my thesis;

honours/
├── cshonours.cls
├── discussion
│   └── discussion.tex
├── introduction
│   └── introduction.tex
├── litreview
│   └── litreview.tex
├── methods
│   └── methods.tex
├── proposal
│   └── proposal.tex
├── references
│   └── primary.bib
├── results
│   └── results.tex
└── thesis
    └── thesis.tex

Using subfiles is pretty easy; what it does is copies the header of your “main document” to your subdocuments. I have my main document, thesis/thesis.tex, which looks similar to this;

\documentclass{../cshonours}
\usepackage{subfiles}
\usepackage{etoolbox}

% Configure bibliography
\bibliographystyle{acm}
\defaultbibliography{../references/primary}
\defaultbibliographystyle{acm}

\begin{document}
\newcommand{\mainfile}{} % we use the existence of this command to see if we're compiling the whole thesis or just a chapter

\subfile{../introduction/introduction}
\subfile{../litreview/litreview}
\subfile{../methods/methods}
\subfile{../results/results}
\subfile{../discussion/discussion}

\bibliography{../references/primary}

\end{document}

and a bunch of subfiles like my literature review chapter, litreview/litreview.tex, which look like this;

\documentclass[../thesis/thesis.tex]{subfiles}
\begin{document}
 \chapter{Literature Review}
 \label{chap:litreview}
 
 % Content goes here
 
 \ifcsdef{mainfile}{}{\bibliography{../references/primary}}
\end{document}

Both documents can be successfully compiled without problems.

Conditional actions with `subfiles`

One improvement I’ve made over the default subfiles configuration is the use of \newcommand{\mainfile}{}. This defines a pointless command called \mainfile if you are compiling thesis.tex directly. However, because it is in the body of thesis.tex, not the header, this command will not be defined if you are compiling an individual chapter.

This means we can use the \ifcsdef function (provided by etoolbox) to check if \mainfile is defined, and make things print or not print depending on if the document is being compiled as the whole, or just a part.

\ifcsdef{mainfile}{}{\bibliography{../references/primary}}

The above line prints a copy of the bibliography after the chapter, provided we’re just compiling the chapter on its own. This is useful, as if I’m working on an individual chapter, I still want to see the bibliography for that specific chapter, but if I’m compiling the whole document, I don’t want to see the bibliography after each chapter.

Using the same style file for each subfile

One problem that you run into with subfiles is that if you have a custom document class file like I do (cshonours.cls), you can’t write \documentclass{cshonours} in your main document, or other subfiles will look for the cshonours.cls file in their own directories, not in the main document’s directory. If LaTeX cannot find the style file there, the compile will fail.

One way to solve this problem is to have a copy of your .cls file in each subfiles’ directory, but another trickier way to solve it is to also put your main document (in my case thesis/thesis.tex) in its own subdirectory, and use a relative path that is correct for all subfiles AND the main file; \documentclass{..\cshonours}. You’ll get a warning message from LaTeX, but it will compile just fine.

Acronyms and abbreviations

If you’re like me and doing a thesis in an area with a lot of tech, chances are you’re going to be using a lot of acronyms and abbreviations to describe things. I’ve found both the acronyms and abbrevs packages useful for this.

Here is part of my thesis/thesis.tex header;

\usepackage{abbrevs}
\usepackage{acronym}

% Acronyms for common stuff
\acrodef{lowpan}[6LoWPAN]{IPv6 over Low power Wireless Personal Area Networks}
\acrodef{coap}[CoAP]{Constrained Application Protocol}
\acrodef{iot}[IoT]{Internet of Things}

% Abbreviation commands for common stuff
\newabbrev\lphy{802.15.4-2006}
\newabbrev\lowpan{\ac{lowpan}}
\newabbrev\coap{\ac{coap}}
\newabbrev\iot{\ac{iot}}

What the \acrodef does is defines an acronym, which you can then reference with \ac{acroname}. If you use that, the first time you use it, it will define the whole acronym, and subsequent times, it will just use the acronym. For example;

We can see that \ac{lowpan} is a good system by which to etc, etc.
\ac{lowpan} is also good for x, y, z.

will produce

We can see that IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) is a good system by which to etc, etc.
6LoWPAN is also good for x, y, z.

The abbreviations package is similar, in that it lets you define more simple abbreviations to map to LaTeX commands, or just text. This is different to using \newcommand, as it handles spacing a lot better. I use it to define some IEEE standards that I mention a lot, as well as even shorter versions of the acronym commands. This allows me to use this, instead of the above;

We can see that \lowpan is a good system by which to etc, etc.
\lowpan is also good for x, y, z.

which I find very convenient.

`fancyref` support for subsections

I also use the fancyref package for cross-referencing. fancyref provides a much smarter cross-referencing system that automatically describes the type of thing you’re referencing, and the page it is on.

One thing that fancyref doesn’t seem to have support for is referencing subsections. If you add these commands to your document header, it should be able to reference them;

% Source; https://github.com/openlilylib/tutorials/blob/master/aGervasoni/orchestralScores/example-materials/OLLbase.sty
\newcommand*{\fancyrefsubseclabelprefix}{subsec}

\fancyrefaddcaptions{english}{\providecommand*{\frefsubsecname}{subsection}\providecommand*{\Frefsubsecname}{Subsection}}

\frefformat{plain}{\fancyrefsubseclabelprefix}{\frefsubsecname\fancyrefdefaultspacing#1}
\Frefformat{plain}{\fancyrefsubseclabelprefix}{\Frefsubsecname\fancyrefdefaultspacing#1}

\frefformat{vario}{\fancyrefsubseclabelprefix}{\frefsubsecname\fancyrefdefaultspacing#1#3}

\Frefformat{vario}{\fancyrefsubseclabelprefix}{\Frefsubsecname\fancyrefdefaultspacing#1#3}

These are just some of the things I’ve done to improve my thesis’ LaTeX experience. You can see all of my changes on its repository page.

Useful tips for writing a thesis in LaTeX was originally published by Ash Tyndall at his personal blog on September 19, 2014.

Using Caps Lock for Windows 8 search

2014-09-01T00:00:00+08:00

Since upgrading to Windows 8, I’ve found that even with Classic Shell, I’m using the Windows 8 search function in pretty much every situation I would access the Start Menu.

Before Classic Shell, I was triggering the search by pressing the Windows key, then typing on the Start tile screen. However, I found it too distracting.

A much less distracting search is the one triggered by pressing Windows + S; it slides in from the side. However, it’s also a fiddly key combination. It would be much easier if I could map a unused key on my keyboard specifically to that; something like Caps Lock.

I did some investigation into the best way to remap it, and I couldn’t seem to find anything on how to change the Search trigger from Windows + S in the registry. I looked into scancode remapping, however while I have seen Windows 8 laptops with a dedicated search key, it doesn’t appear it is mapped to a scancode.

The Solution

It seems like the best approach was to develop an AutoHotkey script for the purpose.

I downloaded, installed, and opened AHK, choosing Yes to create the “sample script”. After some testing, to get what I wanted I needed to remove the sample code and add;

; CapsLock performs search
CapsLock::#s

instead, then place a shortcut to the script (it’s in My Documents) in %AppData%\Microsoft\Windows\Start Menu\Programs\Startup. This causes the AutoHotkey script to run at startup, configuring the Caps Lock key to trigger Windows + S.

Another script that I found on the AutoHotkey foums was repurposed to toggle Caps Lock by double-tapping the Shift key. However, I have turned this off, as my typing style seems to trigger it accidentally: Your mileage may vary.

; Double-tapping Shift enables CapsLock
Shift::
if (A_PriorHotkey <> "Shift" or A_TimeSincePriorHotkey > 300)
{
   ; Too much time between presses, so this isn't a double-press.
    KeyWait, Shift
    return
}
	if GetKeyState("CapsLock", "T") = 1
	 {
 	  SetCapsLockState, off
	 }
	else if GetKeyState("CapsLock", "F") = 0
	 {
	   SetCapsLockState, on
	 }
return

While simple, I’ve found both these scripts to be very useful.

Using Caps Lock for Windows 8 search was originally published by Ash Tyndall at his personal blog on September 01, 2014.

Infrared sensors and unforeseen roadblocks

2014-08-27T00:00:00+08:00

One thing that I’ve learned in the past few weeks is that your setbacks can emerge from nowhere, and aren’t necessarily within your control, or even your field.

Rachel and I agreed that the project should begin with a more general investigation of the sensor capabilities and requirements (the reliability criteria) before branching out into the other areas.

However when we went to order the Grid-EYE from Digi-Key, one of the best contenders in the options examined we were presented with the following message upon clicking “Add to Cart”;

Due to U.S. export controls, we are unable to add this item to your order.

Huh?

Confused, I emailed Digi-Key about the issue, asking if there was any way to order the sensor in Australia, and for more information about the restrictions. I got the following response;

Hello, thank you for your inquiry.

Thank you for your order. I apologize, but due to contractual agreements with certain manufacturers; we are unable to supply you with the part .

I apologize for any inconvenience this has caused you, and I look forward to doing business with you in the future.

This was very disappointing. The Grid-EYE was looking to be one of the best sensors for our purpose, and now it’s become a difficult part to order. Even if we circumvented the restrictions via a colleague in the United States, using such difficult to acquire sensor would go against the goals of low-cost and easy assembly.

The Alternative

For now, we’ve decided to investigate the Melexis MLX90620 as a substitute, as it does not appear to have similar ordering restrictions and seems to be based on similar technologies.

The primary disadvantage of the sensor is that it is in a 16x4 array, which is far less useful for scanning a square room than the 8x8 arrangement that the Grid-EYE offers. There are videos on YouTube of people hooking the sensor up to stepper motors and rotating it on one axis to get an effective 16x16 thermal array instead. This may be an option for the project.

For now, getting it working with a RPi for testing purposes is the goal.

Infrared sensors and unforeseen roadblocks was originally published by Ash Tyndall at his personal blog on August 27, 2014.

Research Proposal

2014-08-13T00:00:00+08:00

This week I drafted and submitted my research proposal. Here is a copy converted to markdown. You can find the original in my honours git repo.

Non-Technical Summary

With the proportion of elderly and mobility-impaired people growing, and the cost of small computing platforms and sensors dropping, now more than ever we can create low-cost sensor systems to use in a “smart home for the disabled.” One such sensor system is an occupancy sensor, which determines the number of people who are present in a given space. This has many applications in a such a smart home, like climate control, which studies have shown can be more efficient when computer controlled in this way.

This project will build on existing research to create an occupancy sensor and accompanying detection software that are well suited for a smart home for the disabled. This system will emphasise four key areas; low cost, non-invasiveness, energy efficiency and reliability. At the end of this project, a list of components and corresponding software will be produced, so that anyone can build the sensor prototype. The prototype will also be put to the test in real world situations around the UWA campus.

Background

The proportion of elderly and mobility-impaired people is predicted to grow dramatically over the next century, leaving a large proportion of the population unable to care for themselves, and consequently less people able care for these groups. [1] With this issue looming, investments are being made into a variety of technologies that can provide the support these groups need to live independent of human assistance.

With recent advancements in low cost embedded computing, such as the Arduino and Raspberry Pi, the ability to provide a set of interconnected sensors, actuators and interfaces to enable a low-cost “smart home for the disabled” is becoming increasingly achievable.

Sensing techniques to determine occupancy, the detection of the presence and number of people in an area, are of particular use to the elderly and disabled. Detection can be used to inform various devices that change state depending on the user’s location, including the better regulation energy hungry devices to help reduce financial burden. Household climate control, which in some regions of Australia accounts for up to 40% of energy usage [2] is one particular area in which occupancy detection can reduce costs, as efficiency can be increased dramatically with annual energy savings of up to 25% found in some cases. [3]

Significant research has been performed into the occupancy field, with a focus on improving the energy efficiency of both office buildings and households. This is achieved through a variety of sensing means, including thermal arrays, [4] ultrasonic sensors, [5] smart phone tracking, [6][7] electricity consumption, [8] network traffic analysis, [9] sound, [10] CO2, [10] passive infrared, [10] video cameras, [11] and various fusions of the above. [12][9]

Aim

While many of the above solutions achieve excellent accuracies, in many cases they suffer from problems of installation logistics, difficult assembly, assumptions on user’s technology ownership and component cost. In a smart home for the disabled, accuracy is important, but accessibility is paramount.

The goal of this research project is to devise an occupancy detection system that forms part of a larger `smart home for the disabled’ that meets the following accessibility criteria;

Low Cost: The set of components required should aim to minimise cost, as these devices are intended to be deployed in situations where the serviced user may be financially restricted.
Non-Invasive: The sensors used in the system should gather as little information as necessary to achieve the detection goal; there are privacy concerns with the use of high-definition sensors.
Energy Efficient: The system may be placed in a location where there is no access to mains power (i.e. roof), and the retrofitting of appropriate power can be difficult; the ability to survive for long periods on only battery power is advantageous.
Reliable: The system should be able to operate without user intervention or frequent maintenance, and should be able to perform its occupancy detection goal with a high degree of accuracy.

Success in this project would involve both

Devising a bill of materials that can be purchased off-the-shelf, assembled without difficulty, on which a software platform can be installed that performs analysis of the sensor data and provides a simple answer to the occupancy question, and
Using those materials and softwares to create a final demonstration prototype whose success can be tested in controlled and real-world conditions.

This system would be extensible, based on open standards such as REST or CoAP, [13][14] and could easily fit into a larger `smart home for the disabled’ or internet-of-things system.

Method

Achieving these aims involves performing research and development in several discrete phases.

Hardware

A list of possible sensor candidates will be developed, and these candidates will be ranked according to their adherence to the four accessibility criteria outlined above. Primarily the sensor ranking will consider the cost, invasiveness and reliability of detection, as the sensors themselves do not form a large part of the power requirement.

Similarly, a list of possible embedded boards to act as the sensor’s host and data analysis platform will be created. Primarily, they will be ranked on cost, energy efficiency and reliability of programming/system stability.

Low-powered wireless protocols will also be investigated, to determine which is most suitable for the device; providing enough range at low power consumption to allow easy and reliable communication with the hardware.

Once promising candidates have been identified, components will be purchased and analysed to determine how well they can integrate.

Classification

Depending on the final sensor choice, relevant experiments will be performed to determine the classification algorithm with the best occupancy determination accuracy. This will involve the deployment of a prototype to perform data gathering, as well as another device/person to assess ground truth.

Robustness / API

Once the classification algorithm and hardware are finalised, an easy to use API will be developed to allow the data the device collects to be integrated into a broader system.

The finalised product will be architected into a easy-to-install software solution that will allow someone without domain knowledge to use the software and corresponding hardware in their own environment.

Timeline

Date	Task
Fri 15 August	Project proposal and project summary due to Coordinator
August	Hardware shortlisting / testing
25–29 August	Project proposal talk presented to research group
September	Literature review
Fri 19 September	Draft literature review due to supervisor(s)
October - November	Core Hardware / Software development
Fri 24 October	Literature Review and Revised Project Proposal due to Coordinator
November - February	End of year break
February	Write dissertation
Thu 16 April	Draft dissertation due to supervisor
April - May	Improve robustness and API
Thu 30 April	Draft dissertation available for collection from supervisor
Fri 8 May	Seminar title and abstract due to Coordinator
Mon 25 May	Final dissertation due to Coordinator
25–29 May	Seminar Presented to Seminar Marking Panel
Thu 28 May	Poster Due
Mon 22 June	Corrected Dissertation Due to Coordinator

Software and Hardware Requirements

A large part of this research project is determining the specific hardware and software that best fit the accessibility criteria. Because of this, an exhaustive list of software and hardware requirements are not given in this proposal.

A budget of up to $300 has been allocated by my supervisor for project purchases. Some technologies with promise that will be investigated include;

Raspberry Pi Model B+ Small form-factor Linux computer: Available from here; $38
Arduino Uno Small form-factor microcontroller: Available from here; $36
Panasonic Grid-EYE Infrared Array Sensor: Available from here; approx. $33
Passive Infrared Sensor Available from various places; $10-$20

References

M. Chan, E. Campo, D. Estève, and J.-Y. Fourniols, “Smart homes—current features and future perspectives,” Maturitas, vol. 64, no. 2, pp. 90–97, 2009.
Australian Bureau of Statistics, “4602.2 - Household Water and Energy Use, Victoria: Heating and cooling,” Oct. 2011.
V. L. Erickson, A. Beltran, D. A. Winkler, N. P. Esfahani, J. R. Lusby, and A. E. Cerpa, “ThermoSense: thermal array sensor networks in building management,” in Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, 2013, p. 87.
A. Beltran, V. L. Erickson, and A. E. Cerpa, “ThermoSense: Occupancy Thermal Based Sensing for HVAC Control,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–8.
T. W. Hnat, E. Griffiths, R. Dawson, and K. Whitehouse, “Doorjamb: unobtrusive room-level tracking of people in homes using doorway sensors,” in Proceedings of the 10th ACM Conference on Embedded Network Sensor Systems, 2012, pp. 309–322.
W. Kleiminger, C. Beckel, A. Dey, and S. Santini, “Using unlabeled Wi-Fi scan data to discover occupancy patterns of private households,” in Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, 2013, p. 47.
B. Balaji, J. Xu, A. Nwokafor, R. Gupta, and Y. Agarwal, “Sentinel: occupancy based HVAC actuation using existing WiFi infrastructure within commercial buildings,” in Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, 2013, p. 17.
W. Kleiminger, C. Beckel, T. Staake, and S. Santini, “Occupancy detection from electricity consumption data,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–8.
K. Ting, R. Yu, and M. Srivastava, “Occupancy inferencing from non-intrusive data sources,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–2.
E. Hailemariam, R. Goldstein, R. Attar, and A. Khan, “Real-time occupancy detection using decision trees with multiple sensor types,” in Proceedings of the 2011 Symposium on Simulation for Architecture and Urban Design, 2011, pp. 141–148.
V. L. Erickson, S. Achleitner, and A. E. Cerpa, “POEM: Power-efficient occupancy-based energy management system,” in Proceedings of the 12th international conference on Information processing in sensor networks, 2013, pp. 203–216.
Z. Yang, N. Li, B. Becerik-Gerber, and M. Orosz, “A multi-sensor based occupancy estimation model for supporting demand driven HVAC operations,” in Proceedings of the 2012 Symposium on Simulation for Architecture and Urban Design, 2012, p. 2.
D. Guinard, I. Ion, and S. Mayer, “In search of an internet of things service architecture: REST or WS-*? A developers’ perspective,” in Mobile and Ubiquitous Systems: Computing, Networking, and Services, Springer, 2012, pp. 326–337.
M. Kovatsch, “CoAP for the web of things: from tiny resource-constrained devices to the web browser,” in Proceedings of the 2013 ACM conference on Pervasive and ubiquitous computing adjunct publication, 2013, pp. 1495–1504.

Research Proposal was originally published by Ash Tyndall at his personal blog on August 13, 2014.

Shortlisting Hardware

2014-08-05T00:00:00+08:00

I’m learning rapidly that the area of occupancy is booming at the moment, and the set of possible options for sensors and host hardware is of considerable size.

To help trim down my list to a set of viable and non-viable candidates, I’ve needed to come up with a more stringent set of criteria, and measure possible solutions against them.

Criteria

The set of criteria I am attempting to optimise for are:

Cost; the set of components required should aim to minimise cost, as these devices are intended to be deployed in situations where the user may not have much money.
Invasiveness; the sensors used in the system should gather as little information as necessary to achieve the detection goal; there are privacy concerns with the use of high-definition sensors.
Energy Efficiency; the system may be placed in a situation where there is no access to mains power, so ability to survive for long periods on only battery power is advantageous.
Reliability; the system should be able to operate without user intervention or frequent maintenance, and should be able to perform its multi-occupant detection goal with a high degree of accuracy.

Host options

There are are a variety of options for configurations that can host the sensor:

Raspberry Pi (battery): A Raspberry Pi with a set of sensors connected to it operates on a rechargeable battery pack.
Raspberry Pi & Sleepy Pi (battery): A Raspberry Pi with the Sleepy Pi addon operates on a wake-sleep cycle with a set of sensors connected to it.
Arduino (battery): An Arduino board with a set of sensors connected operates on a rechargeable battery pack, with on board data processing.
Raspberry Pi (mains), Arduino (battery): An Arduino board with a set of sensors connected operates on a rechargeable battery pack. A Raspberry Pi communicates with it and handles the data processing aspect.
TMote Sky (battery): A MoteIV Tmote Sky, the same as that used in the ThermoSense paper. [1]

Sensor options

There are similarly a variety of sensors that can either be used directly, or act as proxies for occupancy in a given area.

Thermal Array: A thermal array is used to measure temperatures in different sections of a room. The use of them to detect occupancy is covered in multiple papers. [2], [3]
Tagging: By assuming occupants have smartphones, it is possible to use them as a proxy for occupancy. [4]
Ultrasonic: Through the use of ultrasonic measurement of distance, passage through doorways can be directionally measured. [5]
Power Consumption: By assuming occupants will switch on electronic devices when they enter a room, broad power consumption can act as a proxy for occupancy. [6]
Network traffic: By assuming occupants will use computers when they enter a room, network traffic can act as a proxy for occupancy. [7]
Cameras: Computer Vision algorithms can be used on video and images to determine the number of people present in the scene. [8]
Fusion: Multiple different solutions can be combined to help optimise over multiple criteria. [9]

Comparison

Host	Cost	Energy Efficiency
RPi	$50	1000mA
RPi & SleepyPi	$105	dependent
Arduino Yun	$70	500MA
Arduino Uno	$125	50mA
TMote Sky	$105	25mA

Cost includes that of compatible 802.11 adaptor if it doesn’t have built in wireless capabilities.

Sensor	Type	Cost	Invasiveness	Reliability
Grid-Eye	Thermal	$30	Low	High
802.11 card	Tagging	$15	Low	Medium
HC-SR04	Ultrasonic	$5	Low	Low
OV7670	Camera (Arduino)	$10	High	Low
OV5647	Camera (RPi)	$40	High	High

I’ll be evaluating these options over the next week.

References

A. Beltran, V. L. Erickson, and A. E. Cerpa, “ThermoSense: Occupancy Thermal Based Sensing for HVAC Control,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–8.
V. L. Erickson, A. Beltran, D. A. Winkler, N. P. Esfahani, J. R. Lusby, and A. E. Cerpa, “ThermoSense: thermal array sensor networks in building management,” in Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, 2013, p. 87.
V. L. Erickson, A. Beltran, D. A. Winkler, N. P. Esfahani, J. R. Lusby, and A. E. Cerpa, “TOSS: Thermal Occupancy Sensing System,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–2.
W. Kleiminger, C. Beckel, A. Dey, and S. Santini, “Using unlabeled Wi-Fi scan data to discover occupancy patterns of private households,” in Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, 2013, p. 47.
T. W. Hnat, E. Griffiths, R. Dawson, and K. Whitehouse, “Doorjamb: unobtrusive room-level tracking of people in homes using doorway sensors,” in Proceedings of the 10th ACM Conference on Embedded Network Sensor Systems, 2012, pp. 309–322.
W. Kleiminger, C. Beckel, T. Staake, and S. Santini, “Occupancy detection from electricity consumption data,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–8.
K. Ting, R. Yu, and M. Srivastava, “Occupancy inferencing from non-intrusive data sources,” in Proceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings, 2013, pp. 1–2.
V. L. Erickson, S. Achleitner, and A. E. Cerpa, “POEM: Power-efficient occupancy-based energy management system,” in Proceedings of the 12th international conference on Information processing in sensor networks, 2013, pp. 203–216.
Z. Yang, N. Li, B. Becerik-Gerber, and M. Orosz, “A multi-sensor based occupancy estimation model for supporting demand driven HVAC operations,” in Proceedings of the 2012 Symposium on Simulation for Architecture and Urban Design, 2012, p. 2.

Shortlisting Hardware was originally published by Ash Tyndall at his personal blog on August 05, 2014.

The Sensing Trifecta

2014-07-31T00:00:00+08:00

One of the primary goals in my research into occupancy is to meet The Trifecta; low cost, low power consumption, easy assembly. This is proving to be a goal not easily achieved.

A paper recommended to me shows prior work in a system called ThermoSense. ThermoSense uses a Phillips Grid-EYE, which provides an 8x8 grid of temperature measurements that when mounted on a ceiling allow the measurement of the temperature in different sections of a room, and the extrapolation of occupancy therein.

Sensors

From the research I have done thusfar, the Grid-EYE would meet the cost requirements, with it being only around $30USD from DigiKey, however, it would require the manual development of a PCB to solder it on to, which would present significant difficulty given its size.

DigiKey offers an evaluation board, but this board is significantly more expensive.

An alternative that could potentially be breadboarded unlike the Grid-EYE is the MLX90620, but it is both more expensive (around $85USD) and in an inconvenient arrangement of 16x4 instead of the Grid-EYE’s 8x8.

Moving out of thermal completely, some interesting research has also been done into using ultrasonic ranging modules like the HC-SR04, which are much cheaper, but also would require a very different design.

Power consumption

Another concern that must be addressed is reducing the power consumption of the Raspberry Pi if it was to be used in this arrangement; a battery powered device of this nature should last at least a couple of weeks.

The RPi website suggests that the model B consumes between 700-1000mA @ 5V, which with a reasonably sized battery would lead to a very poor lifespan if left on continuously.

One possible solution to this was the Sleepy Pi, which uses a low powered Arduino board acting as a sort of watchdog to sleep and wake the RPi as necessary. With such an arrangement, the RPi could wake up at relatively long intervals (5-30 minutes), make measurements, and then sleep again. The Arduino could also be programmed to wake the RPi based information gleaned from a passive infrared sensor

However, using the Sleepy Pi goes against the concept of the occupancy determination being accessible in a RESTful way.

In a different vein, a system could be devised in which an low powered sensor on a battery (or energy harvesting device) reported back raw measurements on an energy efficient wireless link to a wall-socket-powered RPi, which could be responsible for the interpretation and RESTful serving of this data on a powered link.

Ideally, this could be the Mosquino, but the lack of manufacturing presents a difficulty in using that board specifically. This also brings back issues with integrating appropriate sensors (the Grid-EYE evaluation board requires USB support).

Finally, energy harvesting sensors like those provided by EnOcean could be used in conjunction with the EnOcean Pi module in a similar vein as the Arduino/RPi model, but with further power savings.

More research is needed.

The Sensing Trifecta was originally published by Ash Tyndall at his personal blog on July 31, 2014.

Beginnings

2014-07-25T00:00:00+08:00

I’m beginning my honours course in the UWA School of Computer Science and Software Engineering this month. I’m being supervised by Rachel Cardell-Oliver.

I’m planning to use this blog (powered by Jekyll) as a dumping ground for my current thoughts and developments on my research. Hopefully if I can get fully immersed in it, I’ll reap the rewards of that additional focus.

Currently, the area I intend to explore involves finding a low-cost way of determining occupancy in a given area. Ideally it’ll involve a novel combination of sensors attached to a Raspberry Pi.

This week I’ll be reading some papers in the area, and investigating the sensors available for the RPi.

Beginnings was originally published by Ash Tyndall at his personal blog on July 25, 2014.

Ash Tyndall

January progress update

Useful tips for writing a thesis in LaTeX

Use subfiles for a modular thesis

Conditional actions with subfiles

Using the same style file for each subfile

Acronyms and abbreviations

fancyref support for subsections

Using Caps Lock for Windows 8 search

The Solution

Infrared sensors and unforeseen roadblocks

The Alternative

Research Proposal

Non-Technical Summary

Background

Aim

Method

Hardware

Classification

Robustness / API

Timeline

Software and Hardware Requirements

References

Shortlisting Hardware

Criteria

Host options

Sensor options

Comparison

References

The Sensing Trifecta

Sensors

Power consumption

Beginnings

Use `subfiles` for a modular thesis

Conditional actions with `subfiles`

`fancyref` support for subsections