Close

Research Methodology

A project log for Media Center automation

Using OpenCV and 6 x Raspberry Pi to detect if rooms are occupied and them turn on and transfuse media to the relevant OpenElec frontend.

Simon EverettSimon Everett 01/09/2017 at 14:590 Comments

Introduction

This project is split up to a number of different stages, first being data acquisition. The project uses the Raspberry Pi camera module due to the ability of three Raspberry Pis through the University of Derby for the purpose of this project. Any IP CCTV cameras would have sufficed, but through using with a standardized platform such as the Raspberry Pi improved the setup and monitoring aspects of this project.

The test environment will consist of three televisions in three different rooms, the living room, kitchen and bedroom. The kitchen and living room are adjacent to each other and the bedroom is on the next floor. Face detection will be recorded as defined below, allowing for an infield analysis how effective the face detection is before the impletion stage as well as any anomalies that exist with the technology or cameras usage.

Research Strategy

Due to the optical detection methods to detect the rooms are occupied or vacant status there will be variations in the quality of the data that is collected due to changes in the light levels caused by time of day. For example, once the sun has set and user turn light on artificial lighting the main light source is generally dimmer, and in most cases mounted on the ceiling. This leads to shadows being cast over the users’ faces, affecting the accuracy of face detection. Conditions such as rain storms can also have the same effect on the accuracy of face detection as already outlined by (Belaroussi & Milgram (2012) whose research outlines the importance of lighting conditions as well as angles in faces when detecting faces.

In order for the system to take this into account, an externally mounted CCTV camera without night vision has been used to calculate the lighting conditions in real time, allowing the system to drop into night mode if the external light levels become too dark. See image below:


Data capture

Every 10 seconds a photo of each room is taken using Raspberry Pi camera modules, the images ares then uploaded to the central server for processing. The image is then passed onto a Python script which uses OpenCV to process the image and identify the number of faces that exist in the image. The results are then passed onto to PHP, which then looks at the GRB values to estimate the brightness of the image. The results are stored in the database against a time stamp; some of the images are stored for debug purpose.

From this a separate PHP service runs every 10 seconds, which is offset by 1 second to establish which rooms are occupied based on the data in the database, unless night mode is enabled where the room light levels as used to determining the occupancy status. Night mode can also be enabled by the time of day a using a PHP built in feature called ‘date_sunset’, which takes the longitude and latitude (PHP, 2015) to establish dawn and dusk times. Each media centre is then queried to see which are currently playing media and which are occupied. If any of the rooms are occupied but not playing media the television in that room is turned on and content is transferred. After a room has been unoccupied for the time out period of 5 minutes the media is stopped and the TV is turned off.

Each room has been calibrated to take into account the strength of the artificial lighting, for example the install for this project considers the living room as a 80, the bedroom as a 90 and the kitchen as 100. For further information this data can be viewed in the PHP file, under the setting directory.

Data Analysis

The below graph is an example 2 hour window with 2 individuals watching a TV program under artificial light during the evening. At the end of the program the TV is left on for a while before the TV and room lights are turned off. The graph below shows wide fluctuations in light levels as well as well as fluctuations in the number of faces detected during ideal conditions where subjects are looking directly towards the camera.

This 2 hr data set shows how clearly the light being turned off is depicted in the data, and how under artificial light the accuracy the face detection decreases.

below shows wide fluctuations in light levels as well as well as fluctuations in the number of faces detected during ideal conditions where subjects are looking directly towards the camera.

This 2 hr data set shows how clearly the light being turned off is depicted in the data, and how under artificial light the accuracy the face detection decreases.

Motion BlurImage removed
Angle between the cameras or subject in the way.Image removed
Good data/ detectImage removed
False positiveImage removed
Unexpected detectImage removed
Low Lighting conductions (Failed)Image removed
Not LookingImage removed
Failed due to (ANGLE)Image removed

This data supports previous assertions that problems are amplified in low lighting and under artificial light because of the non-directional nature of artificial lighting whereby shadows are cast over the subjects 3d human faces. In the diagram below, the two locations were the green faces are denoted on the floor plans show where the system struggles to detect faces because the light source is directly behind the subjects face. The middle location on the bottom row does return detection because it’s illuminated by the TV screen assuming it is on.

This evidence is further supported by the data collected in the bed room whereby only around 10% of face detection occurs when the users are watching TV in the location under artificial lighting conditions. This is caused by the layout of the light sources, the location of the TV in relation to the users.

The second floor plan of the bedroom demonstrates that users sitting on the bed

watching TV have light source on the right of them. This in turn casts a show reducing the chances of face detection. It was not possible to move the location of the light or the windows to improve rates of detection.

Software – Myth TV

To provide live TV for the user MythTV’s backend server has been implemented. XBMC contains built in supported plugins that allow XBMC to access MythTV frontend allowing live play back and access to the recorded TV programs. Live TV will be provide to the Media Centre (XBMC) from the MythTV backend which is utilises two Freeview tuners (Amazon, 2015)

This allows two separate channels to be recorded at the same time, One of the reasons that MythTV was selected for this project is because of its ability to use a feature called viral tuners. Viral tuners in theory can allow MythTV to record up to 12 separates channels at the same time using only two physical Freeview tuners (MythTV, 2015).

This is achieved because Freeview is divided up into a number of multiplexes (ref http://www.digitaluk.co.uk/industry/Multiplexes). At present there are 8 different multiplexes in the UK, coverage dependent. When a user selects a channel the turner tunes to the relevant multiplex and ignores everything but channel requested by the user. MythTVs viral tuners feature allow MythTVs to uses all of the multiplex that is it is currently tuned to. An example of this would be that all of the BBC channels are on the BBC multiplexes (BBC A) and all of the ITV channels are on the ITV multiplexes (SDN). If tuner 1 was receiving multiplexes (BBC A) and tuner 2 was receiving ITV multiplexes (SDN) during the time you couldn’t watch channel 4 but users could receive BBC 1,BBC2, BBC 3, BBC News, ITV , ITV2,ITV4. There are usability downsides to the setup, there are often times when certain channels aren’t available this is because they exist outside of the currently recorded multiplexes and there is not a free tuner available to capture that particular multiplex. This can become confusing for end users to understand although this feature is perfect for this project, because more than one media centre will be required to view the same channel without having without add physical tuners.

Control:

CEC:

CEC, consumer electronics control, also needs to be taken into consideration in the design of this project to allow XBMC to utilise the built in TV remote, as well as allowing XBMC to control the TV. CEC is part of the HDML 1.3 [ CITATION Hit06 \l 2057 ] specification, but manufacturers have their individual implementations that often contain a subset of features. An example of this would be Samsung equipment where the CEC has been branded as Anynet+ Control Pass, the CEC control device can not adjust the volume due to the implementation not supporting this feature.

NFC:

The media centre (XBMC) can be controlled directly in a number of way using a standard keyboard and mouse, remote control, CEC via the HDMI as well as JSON API which can be accessed using a Mobile app or Web interface.

Other feature of XBMC that are relevant to this project is that many different XBMC instances can share a common database as well as the same media (Kodi, 2015), this is key for our project otherwise each instance of XBMC would index the media folder and potency give the same media different unique identifier. Because XBMC can share its library it means that the Movie 66 happens to be A-Team on every ALL of the XBMC instances. The XBMC Android app for currently controls Media Centres using the topologies as depicted in the below diagram. The app itself is not aware of its proximity to any of the media centres; it is only aware that it is on the same network:

If a user scans a static NFC tag attached to the TV to, for example, start BBC 1 the proposed logical topology can be adjusted by the system to:

This is achieved because the tag states the content on the relevant media centre then instructs the Android XBMC Remote App to change media centres and to display itself on the phone. This information is determined by the NFC tag itself. The static NFC tag simply contains a URL such as:

which informs the system where it is and what the user expects. An example of a movie would be:

NFC tags can be written using a simple smartphone app such as NFC Tools by and tags are at an affordable price for the constraints of the project and easily available from amazon for around 3 pounds (Amazon, 2015b). The following table shows the four images of the process to scan a static NFC, this tag is located on the bedroom TV and is set to play channel 1.

The project has further extended the physical control by using surface mounted NFC tags that can be programed to instigate and display TV channel. This physical control surface can is used in a number of two distant ways, either attaching an tag on a wall near the media centre allowing a user to select BBC 1 or by attaching tags to DVD cases and reading the TAGS using an static reader. This could be an NFC enabled phone or a Raspberry a project named Raspberry Kiosk could provide an suitable platform as recommended by Raspberry Kiosk (2013).


For the purposes of this project static NFC tags are used with smart phones, this has the added benefit of once the Media centre started the playback commands can be issued to the smart phone to display and setup the relevant media remote control (Yatse, 2015) for the relevant media centre on the user’s phone. It is also possible to query the data stored in the library, it would be possible to setup and NFC tag to play the most recently recorded episode of “Marvel's Agents of Shield” assuming that XBMC has indexed the media.

The first image demonstrates that the wrong media centre is selected.


The Second image shows the NFC being read and loading the webpage.

Third image demonstrates the XBMC remote app loading and changed to the correct Media Centre.

Last image shows the TV turned on, and displaying the required channel. BBC 1 in this case.

This last image shows the interaction between the XBMC remote app and Firefox, Firefox looks like the XBMC remote in the preview because Firefox has called the XBMC app.

Discussions