Audio Recording/Playing

A feature for the feeder is to play the owners voice from the feeder to attract the cat(s). To do this, the owners needed the option to upload a recording. Using HTML5's ...

To upload the file, the POST method was used on the same page and would upload the file to a temporary directory and would then move it to the correct directory which would be the folder where audio is played from. 

The max file size able to upload was also changed to 10 MB from the default 2 MB. This was changed in the php.ini file (/etc/php5/apache2/php.ini). It was also important to note that the uploading process took between 30-40% of the CPU usage as this could potentially overload the CPU whilst the cameras are streaming.

To play the audio uploaded first I tried the in-built aplay from the ALSA system, however it did not play the audio and instead just played noise. So instead the mpg123 package was installed and tested. This was easily installed and used a small amount CPU between 1-5%. After modifying the permissions for the site to be able to run the mpg123 package on the audio folder, the audio could be played as many times as possible. To make sure it can only be played once,  a setuid was used to kill the process at any point - as this is a prototype this is acceptable to show the behaviour of the system, however its likely this would need changing to ensure that this does not open a security issue. 

After testing the audio from mobile devices, the mobile audio was in the format .m4a. The package mpg123 only plays mp3 formatted files. So initially converting any file to MP3 was considered, but it would be the most inefficient method. Instead, more console players were looked into, and eventually the player called SoX was found which supported a lot of different formats. Following the same process for setting up mpg123, SoX was easily installed and was successful with running mobile recordings. SoX also has a built-in function to repeat audio files however many times specified. This was implemented later as an additional function which seemed beneficial to the system - as owners call for their cats multiple times sometimes. This would add a layer of personalisation.

Once implemented, there was one issue that was incurred randomly, where the speaker would not be recognised when all of the usb devices were plugged in, usually this could be resolved by restarting the RPi. However, in an effort to eliminate the issue, I decided to overclock the device to the preset Medium setting for overclocking (along with a small amount of overvolting). This did improve the issue and did not appear too frequently, and hopefully provided an added level of stability with the amount of devices connected.

Video/Audio Streaming Testing

The following options were looked into for video streaming and/or VoIP:

• uv4l
• Motion
• MJPG-Streamer
• Asterisk & freebpx

The first attempt at achieving this function was using 'uv4l', which allows for streaming video and audio over various platforms. It was able to be hosted on the RPi. The primary reason for trying this software was due to the convenience of how both video and audio could be streamed between the RPi and another device in a browser. The software is exactly what was required. However, testing the server on a mobile device showed how it would not work on mobile - although this was on iOS, and is likely to have worked on Android. This was due to the software using video files that the mobile device did not understand. As a result of this I decided to look into other options.

Motion was the next option looked into, where the software features the ability to detect motion in the video. Instead of being an encoded video, it was images captured from the camera and then encoded into a format that would be able to be viewed on any device. Out of all of the software tested, Motion was by far the easiest to setup and configure. It was configured to update the the feed every second, but if motion was detected (which is done by detecting a specified amount of change from the previous frame) then the fps would increase to around 5fps to get a smoother stream. The biggest drawback with using Motion is that only a video stream is produced, there is no audio - so the research continued.

Similar to Motion, MJPG-Streamer compiled images into a simple video stream of JPG images. Motion was easier to setup and implement, however MJPG-Streamer performed better and allowed for both cameras to run, this can be seen below when it was implemented onto the website. As this simple stream did not use stream audio, I carried on my research in an attempt to find a better solution which supported 2-way audio streaming.

The final software looked into was the software Asterisk and freebpx. These are to be used together as a pure VoIP method. This would be accessed externally to the video stream, and would require the use of an external VoIP app such as Zoiper.

However, in attempts to do this, the Asterisk and freebpx did not work and resulted in the use of just streaming video - not audio. As a result, I needed to make sure the video streaming was optimised for the project. Therefore, further testing using MJPG-Streamer to ensure the best output for mobile and ensuring the RPi would not be overloaded by the process.

Initially, at 640 by 480 resolution for each camera without compression, each stream took up between 35-45% of the CPU and showed a lot of delay in the FPS along with approx. 600ms latency. To help all of the issues here, I decided to use different parameters. Below shows the results.

This resulted in the choice to use 160x120 without compression at 20 FPS. The compressed version was not chosen because the image was noticeably worse.

Researching server options to be hosted on Raspberry Pi

After deciding the best method of being able to operate the feeder and comply to its required functionalities was to host a website on the Raspberry Pi server. So I began looking into possible options.

Below are some of the most popular and most well known that were recommended to use on the Raspberry Pi:

• Apache - Free & Open-Source - Most Popular Web Server (Netcraft)- Written in C, XML
• Lighttpd - Free & Open-Source - Written in C
• Nginx - Free & Open-Source - Written in C
• Monkey - Free & Open-Source - Written in C
• Tornado - Free & Open-Source - Written in Python

Apache appeared the most suitable and is pre-installed on the Raspberry Pi. Therefore it was selected as the web server of choice.

References:
http://news.netcraft.com/archives/2015/11/16/november-2015-web-server-survey.html

Testing RFID Readers

After initially testing the Phidget 1023 RFID reader, the Raspberry Pi was selected as the core for the cat feeder system. This meant the RFID reader would need to work on Linux Debian.

The Phidget 1023 tested already was then ready for testing on a Linux machine, this required installing the Phidget 21 library along with the python library. Once installed, example .py scripts were used to test the functionality. Below shows it working in Ubuntu and a tag being read.

However, when the libraries and Phidget RFID reader were migrated over to the Raspberry Pi, there was an issue with either compatibility or the RFID reader itself. This meant no tags would be recognised and in general nothing worked consistently. Therefore another RFID reader (Parallax RFID Reader, which can be seen below) was tested on the Raspberry Pi. This used a serial implementation and simply required the Serial port access library to operate. The device operated successfully on the Raspberry Pi, but did lack range - this is likely to be due to the lack in power from the Raspberry Pi's USB port.

Using the serial library, I was able to produce a simple python script that would search for a reading from the reader and would retrieve the tag's ID. This would later be used for the system cat recognition.

Update:
Below is a video demonstrating the implementation of setting up the RFID reader with the cat feeder:

References

https://youtu.be/6pXWhGzX4Fg

http://pyserial.readthedocs.org/en/latest/pyserial_api.html

Servo Motor Control (In Progress)

My cat feeder design is simple - there are 4 boxes (food containers) on each side of the feeder which are spring loaded, which will open if the lid is not kept closed. So these boxes will be kept shut to keep the cat food fresh for as long as possible. They will be kept sealed by using servo motors at each box position that will prevent and stop the lids from being sprung open. This then simply requires a simple rotation on the motor to stop the lid from being kept shut. Once the servo is not rotated on the box lid, it will open and provide access to the food.

 I will also be using these motors with the raspberry pi so that all of the feeders functionality is available from the single device that will later be contacted (this may be done by having simple commands in a facade pattern call specified scripts for different functions). I have researched into directly controlling the (two) servo motors I have available to me, but it seems as if I need an additional wire to divide the pins up onto the GPIO board correctly - this would be an issue too if I was to try and connect more to control.

Furthermore I decided that I needed to research into this more and see how connecting a total of 9 servos would be possible. The first device I came across was the Ardunio which is a micro controller that can control servo's PWM (using analogWrite from the library available). Further research into the device proved some of the Arduino models but there seemed to be constraints such as requiring external PSU's when there are a lot of servos (2+ generally was suggested). This would be an issue as I require 9 and would prefer to not need more than the raspberry pi being powered - but this is still a viable option.

After looking into the Arduino I decided to look into other options, and so I came across another option called the Adafruit 16-Channel PWM / Servo HAT. This device is specifically made to power servos with the raspberry pi - the HAT aspect (Hardware Attached on Top) allows for this. The device allows for up to 16 servos to be connected meaning it would be able to operate the desired 9 for my cat feeder. The device similar to the Arduino, has a Python library (this would be beneficial for the web server aspect I plan on implementing). However, there is an issue with it as it is also likely to require an external power source (PSU). This would likely increase the cost quite a lot if using a DC plug - an alternative option provided is using 4x AA batteries. Using batteries would obviously also bring an issue of replacing them if they ran out, but as the cat feeder is not meant as a commercial product, this is not too much of a concern. If it was a commercial product I would look for a method where a PSU is not required, but most options that are inexpensive seem to require similar features of the Adafruit HAT here.

I will look further into this subject of operating the servos, but at this point I have made a small comparison between the two devices I have looked into below.

By Jonathan Grant

References:

https://www.arduino.cc/en/Main/ArduinoBoardUno

https://www.adafruit.com/products/2327

Phidget RFID Reader Testing

A new feature which I have decided to implement into the cat feeder I will produce is an RFID system. This means a RFID reader will be in place and will recognise when a compatible RFID tag is within range of the reader. Today I have got the reader and tags and will be testing its functionality. Below shows the reader (Phidget 1023) and tags used for this test.

To test the RFID reader, I installed test software (Phidget 21 Library) for the model I am using. This would allow me to understand the range and functionality. Below shows the me having the software open, then having a tag placed close to the reader - this results in the id string being displayed in the program.

After doing several tests with the device I had several findings that are worth noting. The first is the radius and that putting a tag either side of the board produced a better radius range result than putting on the edges of the board. The max radius was approximately 6cm - 6.5cm away from the device. From the edge of the reader it was about 3cm until the string appeared. In addition to this, the speed at which the tag travels across the reader is also important, as if it goes across it too quickly, it will not be recognised. The suggested speed of the tag to cross the reader is of at least 50ms. As this technology will be used in a cat feeder that will need to feed 2 cats, it was important I tested how the reader responded to multiple tags within its range. My results showed that the device could not handle more than one tag at a time as the id string would simply disappear once there was another tag added to a single tag - this is unlikely to be an issue with feeding two cats due to the small range and constant movement of the cats - but for more animals/tags this is more likely to be an issue. I researched into this and came across multiple sources suggesting that it is possible, and that anti-collision methods can be in place to do so. It may seem as if the reader I am using does not use these methods and therefore cannot detect more than one RFID object at once.

Along with the id string provided from reading each tag was the protocol used for each object read. For the tags used, the protocol EM4100 was in place. After researching this, I came across what the format of the protocol. The tags I used with this protocol have 64 bits of ROM, meaning it's data cannot be changed.

 For my project, it will be important that the device can be controlled using the raspberry pi and the device tested supports linux and many porgrammng languages (including C# and java). This means I can use the devices API to control and read it's operations. The Phidget 1023 RFID reader seems to be a suitable choice to use in the cat feeder.

By Jonathan Grant

References:
http://www.phidgets.com/docs/1023_User_Guide
http://www.priority1design.com.au/em4100_protocol.html
https://www.wewear.org/assets/1/7/RFIDBasic_Paxar.pdf