Well Cow™ is a research tool used to measure the acidity of cows' stomachs. Cows are susceptible to rumen acidosis where the acidity of the stomach is abnormally high; this can cause the yield of milk and quality of meat to reduce greatly, but in its worst case, it can prove fatal for the cow.
This project allows farmers to monitor their cows' stomach acidity levels; a sensor (or 'bolus') is positioned in the cow's first stomach, and pH data is wirelessly transmitted to the web app via the "gateway" device in the milking shed.
The Gateway control panel for logged-in user 'Gregory Thomas', showing Animals and Animal Groups relating to the user's organisation.
In our team of three, I carried out these tasks:
The Cloud server control panel for logged-in Admin user 'Gregory Thomas', showing ability to create organisations for other users to be invited to.
The Gateway is a ruggedised Raspberry Pi to be placed in a communual area for the cows. The Gateway's firmware is a multi-process Python application, and its operation is asynchronous; it holds commands for boluses not within radio range, and as soon as the cow comes within range of the Gateway, its priority is to send and receive commands to that cow before it roams out of range. On a successful receipt of a sent command, data is downloaded to the Gateway from the bolus. Once bolus data has been received by the gateway, the data is uploaded to the cloud server provided the gateway is connected to the Internet.
The firmware uses multiple processes for the sake of performance, and ZeroMQ was used for inter-process communication.
The 'router' process handles incoming and outgoing commands for all boluses. This process takes priority over the other processes; it was never known how long a cow would be in radio range for, so it was worth ensuring commands were handled quickly.
The 'webserver' process serves the web app to the user, and handles bolus commands requested by the user by passing it to the router process and returning a response back to the user.
The 'janitor' process handles commands solely for the Gateway (as opposed to bolus commands), does regular data backups to the Cloud server, and performs general housekeeping.
Automated test suite using Python 'unittest' and 'webtest' libraries. A test controller was created to allow individual processes to be run in test mode, and allow other processes to be mocked.
A cow might have more than one bolus in its lifetime; this is due to the harsh conditions within the cow's stomach.
When a bolus first comes into contact with the Gateway, a Bolus object is created. This Bolus is 'unassigned' - it does not yet have a parent 'Animal' object (named Animal in case the system extended to other animals). The database architecture allows for an unassigned Bolus to be assigned to an Animal, and an Animal can be a part of a Group of animals.
The web app is hosted on the Gateway and runs in its own process. SimpleHTTPServer was used as it was unnecessary to use a HTTP server that supported multiple connections (especially in the early phase of the project). The user enters the Gateway's local IP in their client device's web browser - from there the user can see cow status, calibrate the bolus, and get a status report for the bolus.
There is heavy use of Asynchronous JavaScript and XML (AJAX) on the front-end code; the whole system is asynchronous, and the user interface needed to cater for that. The interface has to wait for responses from other processes in the Gateway system.
The Gateway Animal page for 'Animal14' of 'Langhill Farm' group, showing the Animal's current Bolus data.
The cloud server is a Google App Engine server written in Python. This server stores acidity data from all boluses, and can be used to send commands to a bolus remotely when the user is away from the farm.
Similar to the Gateway's test suit, an automated test suite was implemented using 'unittest' and 'webtest'. This similarity was helpful because I was able to write similar test code for two parts of the system.
An accounts system was implemented with Organisations in mind. Each user of the cloud server is a member of an organisation. These users have a clearance level; they of course are limited to what they can do with the system, specifically in the cloud server's Control Panel. For example, organisation admins can invite others to create an account, but organisation users cannot.
Each user can see the hierachy of groups, animals and boluses within their organisation.
The Cloud server Animal page for bolus #5149 in 'Animal14', with ability to see rows of data if uploaded from Gateway.