Tuesday, 27 November 2012

Low cost solar traffic monitoring unit construction

As part of our work on traffic monitoring systems, we're aiming to demonstrate that self-contained solar powered traffic monitoring devices can be constructed for less than $100 per unit. Our most recent prototype cost approximately 450,000 UGX ($180) for all parts and fabrication.

For comparison, the US Department of Transport has an interesting page listing the unit costs of a number of congestion monitoring technologies. A set of inductive loop sensors at a single intersection cost 8.6-15.3k USD. Traffic CCTV installations (for the camera, electrical services, cabinet and installation) are estimated at 9.0-19.0k USD per camera, while a machine vision sensor at an intersection is estimated at 16.0-25.5k USD per installation. So we're looking at reducing the cost by two orders of magnitude.

The basic idea of our units is to house a battery, charging regulator and cameraphone in a steel box, as shown here:

The box is locked and mounted underneath a solar panel like this:

The charge in the phone is maintained by a 14W, 22V solar panel above the unit, and excess charge tops up a 7.2Ah battery pack via a charging regulator, in case of several consecutive overcast days. An arm extending from the solar panel allows the unit to be bolted to a wall or post, and the camera can be rotated through two axes.

A steel box is necessary for security but has the issue that it acts a Faraday cage, cutting out reception for the phone. In order to be able to upload images, we have to connect a wire from the phone's internal antennae to a wire coil outside the case.

The prototype unit has been pretty stable for the last month or so, and uploads a set of three images 0.5 seconds apart every two minutes. It's positioned at the main gate of Makerere, and although the positioning isn't great (as we had to make do with the lampposts available to mount it on), we're starting to get a picture of a day in the life of Kampala's traffic...


6:30am, not much activity
A little after 7am the morning rush is full swing
Evening rush at 6:15pm
Still slow traffic an hour later. It settles down by 9pm or so. The characteristics of the vision problem obviously change a lot at night, and we haven't looked into this a great deal yet.

Given all this data, the focus is now on evaluating the accuracy of the software assessing the flow speeds on the road. We also have permission for installation of another two units at different exits of Makerere, so this will be interesting to be able to start looking at the correlation of traffic speeds at different places.

Thursday, 13 September 2012

Automating Crop Surveillance – theory vs. praxis - part 3/3

Field Practice

With all these good ideas we set out to implement a national crop survey with NaCRRI this year.  The purpose is to test the mobile survey system that automatically updates an online map with survey data from the field in real time. As is always the case the theory underestimates the praxis – this case was no different, several issues we thought were significant and would be problematic actually turned out to be non-issues – this was the good part; the terrifying part were the non-issues that became issues. I detail several of these here spanning from the preparation, training and deployment phases of the apps on the phone and what was observed on two separate field test visits with the actual survey experts.

  1. Space/storage considerations on the phone – the image capture application uses the native phone camera application. We found that the default setting for the size and resolution of the images taken with the camera had to be changed from a 3M high-resolution image to a 1 M normal resolution image. The size of the images affects how much bandwidth will be used in uploading the images to the server and the capacity of the memory card to use in the phone. For the survey we expect each phone to take a minimum of 1000 images. So for the 8 phones we are using, approximately 10000 images.
  2. Screen/keyboard size of phone – during the training of the surveyors, the issue of usage of the phone keyboard came up. We are using the Huawei Gaga U8180 which has a display size of 240 X 30 px so its not all that big but still usable with some training. Issues of how to use the touch screen with dirty fingers (from digging up roots, etc.) also came up.
  3. Sun glare – this happened to be one of the most daunting issues. Collecting data in the gardens when the sun is all out was problematic because of difficulty in seeing the phone screen and hence difficulty in navigating the form. One solution round this was to set the brightness setting to auto on the phone. Some improvement is realized but this is something to take into consideration when buying more devices in the future. 
  4. Background clutter – for one of the field visits we tried to use a cardboard paper that was put behind each leaf before the photo of the leaf was taken. This was a very cumbersome procedure especially when trying to take an image of the whiteflies on the leaves because for the whitefly shot one needs to turn the leaf over as the whiteflies reside on the underside of the leaf. Taking the shot with the background required at least two people to execute. This was rejected and so images have to be taken with a cluttered background and the filtering done at the server end.
  5. Image capture – To score the severity of disease manifested by a plant accurately some diseases require that the examination of the whole plant is done, while for others this can be done from looking at the canopy of the plant. A 2D image of a plant unfortunately does not provide all the information for accurately determining the severity score of a plant – we thus had to settle with taking two representative images of the plant – one full plant image and a close-up canopy/leaf shot.
  6. Power/charging issues – the Huawei Gaga like most touch screen phones has about 1 day lifespan on the battery under heavy usage. We had to provide car chargers to the surveyors so the phones could be charged in the cars as they move from one garden to the next. 
  7. Server issues – Google App Engine can only support up to a limited amount of data storage and access for free. We had to enable billing to support this survey of an estimated 10000 geo-coded images.

Current Status

We are waiting on NaCRRI to sort out the necessary logistical issues related to the survey. It is expected the survey will be conducted in September 2012.

Automating Crop Surveillance – theory vs. praxis - part 2/3

The Science behind

To automate some of the expert processes we leverage some of the latest computer vision and machine learning techniques and apply them to three specific tasks in this survey.

1. Automated diagnosis

The objective here is to assess the feasibility of automated computer vision based diagnosis of CMD. Feature extraction techniques based on color and shape are used to extract features from the images of the healthy and CMD-infected cassava plants and classification using a set of standard classification methods (naive Bayes, two-layer MLP networks, support vector machines, k-nearest neighbor and divergence- based learning vector quantization) is applied to determine the diagnosis of the plant(image).  This diagnosis is either done at the server end or on the phone.
Depiction of survey process - (a) Image capture, (b) Automated diagnosis, (c) Real-time mapping

2. Automated whitefly count

Whiteflies are the major vector responsible for transmission of cassava mosaic disease and other cassava related diseases. To understand the spread of disease, experts are required to count the number of whiteflies on a leaf. This however is not a trivial task; the small size and volatility of the whiteflies results in inaccurate whitefly counts. We implemented a computer vision-based system on the mobile phone that automatically counts the whiteflies on a leaf from a photograph taken of the leaf or a video of the leaf image taken in real time.

Whitefly detection and counting

3. Determination of level of necrosis in diseased roots

For some Cassava Brown Streak Disease (CBSD) the major part affected is the tuber/root of the plant. Experts out in the field ordinarily dig up a set of plants in selected gardens and examine five cross-section cuttings of the root. A score of severity of disease is assigned to the plant based on the average percentage of necrotized root of all five cross-sections examined. We intend to automate this process so there is a uniform scoring of necrosis from a uniform system.

Necrotized roots infected with CBSD

Automating Crop Surveillance – theory vs. praxis - part 1/3


An annual crop survey is carried out in Uganda every year by the National Crop Resources Research Institute (NaCRRI) targeting the cassava plant. Normally experts are required to go out to different gardens in the four disparate regions of Uganda and fill out paper forms indicating the incidence and severity of diseases affecting cassava by visually examining cassava plants.

Automating this process is what we set out to do – the main reason being to enable policy makers access this data immediately as it is collected in the field, and secondly to make several component processes of the survey more efficient for example automated diagnosis and severity scoring, automated count of disease vectors on the cassava leaves and uniform scoring of necrotized cassava tubers.

Theoretical Solution

In brief…

Replace the paper forms with cheap mobile phones running Android OS and using the existing telecommunications network get geo-tagged surveys directly on to a map in real time from data collectors in the field.

Because of the available processing power on the phones, automate the cumbersome tasks of whitefly count and severity scoring on the phone so experts need not be the ones to carry out the survey and can use their limited time doing something else.


We built a system based on the Open Data Kit (ODK), Google AppEngine, the Google Map API and Google Fusion Tables – heck we even communicated using gmail ☺

ODK: We used ODK-build to build forms usable on the mobile devices (converting the paper form to an appropriate mobile format). ODK-Collect was used to collect the data on the mobile devices. ODK is presently only compatible with devices running Android OS.
Google AppEngine (GAE): Used GAE to host the server side of the system that receives the uploaded data from the mobile phones. It was implemented as an instance of ODK-Aggregate.

Google Map API: We integrated the API with GAE to display the uploaded data on a dynamic map.
Fusion Tables:
Used to seamlessly interface data in ODK Aggregate with the Map API.
A real-time map of the crop survey

Thursday, 6 September 2012

Second in video seminar series

The second in our series of live video seminars took place today, with Allan Tucker from Brunel University giving a talk on probabilistic analysis methods for some genetic, clinical and ecological datasets.

Last month, Charles Fox from the University of Sheffield presented some work on traffic flow modelling using UK number plate recognition data. The series gives us a way to hear presentations from AI and machine learning researchers around the world without the obstacle of them having to physically travel to Uganda.

The list of upcoming seminars is here.

Saturday, 25 August 2012

AI-DEV Paper Receives an Award in the AAAI 2012 Conference

AI-DEV group paper entitled "Coupling Spatiotemporal Disease Modeling with Diagnosis" in July this year (2012) won the Community Computing Consortium Outstanding Student Paper Award in the Computational Sustainability and AI track, AAAI-12 Conference in Toronto, Canada.

The idea in the paper can be summarized using the figure above. Disease density modeling (that may result in a risk map) and disease diagnosis are important tasks in biosurveillance. These tasks are always performed separately but can complement each other. For example, if the location of an individual to be diagnosed is known, the risk at that location can be used as a prior in the diagnosis and in turn, the map can be updated with the result of the diagnosis.

In this paper, we present a general framework of combining these two tasks and we use malaria as a case study to demonstrate the tractability of combining both tasks and the improvement in accuracy this brings about.
Avaliable as [PDF] [BiBTeX]

Tuesday, 21 August 2012

Kampala traffic video analysis example

This video shows some of the image processing we are working on for analysing traffic video streams in Kampala. The aim of this project is to use the cameras in phones as the basis for an ultra-low cost congestion monitoring system, furthermore one which is able to deal with the unusual features of developing-world city traffic. In this example we first use SURF features to calculate correspondences between each frame, giving us a set of motion vectors in the coordinates of the image. We then project those vectors into 'real-world' coordinates, allowing us to calculate speeds in km/h. The last part of the video shows how a regular grid in real world coordinates compares to the motion vectors.

In earlier stages of the project, we worked with Uganda Police to use their network of CCTV cameras. We were at least able to get some good example images with those cameras showing why traffic monitoring is not as straightforward here as it is in some other places:

The problem is that because those cameras can pan, tilt and zoom, the field of view can change very frequently. Rose Nakibuule tried ways of automatically calibrating the camera projection using the motion vectors, features of common vehicles which help us estimate scale, and so on. Conclusion: this is difficult to pull off reliably. In the end we decided that some manual calibration is probably unavoidable anyway, since we need to know the different regions of interest in the frame (lanes going in different directions, for example, which we need to be processed separately). So now we use camera phones in a fixed position and setup involves a user clicking on four points in the image corresponding to a regular square on the road, which seems to work pretty well.

Including the speed estimate the results look like this (screenshots from a Python/OpenCV port of the Matlab code used above):

Live testing of computer vision malaria diagnosis

Last week I tried out our computer vision diagnosis system Ocula in Lacor Hospital, Gulu. The prototype system is shown here running on a netbook with a Moticam MC1000 microscope camera. There is a malaria positive stained blood sample in the scope, and software on the netbook processes camera images in real time and highlights the positions of suspected parasites.

This was the first test of a few new software components. A lot of time had gone into reverse engineering a Linux USB driver for the Moticam (source code including Python wrapper is here, tested on Ubuntu. Motic, in future please release proper drivers so we don't have to waste time on this!). This test also included some developments on visual features which improved the specificity on test data; the most recent performance figures for parasite detection are precision 88.6%, recall 55.1%. This is an improvement on the results in our AAAI 2012 paper and might be good enough to be useful as an assistant to a lab technician, triaging their attention so that many slides can be processed quickly. But it isn't yet at the stage where it would be good enough for completely automated diagnosis. The live prototype was encouraging though - with the help of lab technician Isaac Otim we were able to verify that a few detections were in fact genuine parasites.

The video below shows the prototype running. The first clip shows Isaac operating the microscope while the analysis software is running. The second section of the video shows screen output on a sample from Mulago Hospital, Kampala, of hyperparasitemic blood with many malaria parasites in every field of view. Most of the detections are genuine parasites, though there are currently quite a few false negatives.

One thing I discovered is how much dust is a serious issue, as particles on one of the lenses can appear similar to an out-of-focus nucleus of a parasite in the image. This needs to be handled in software as dust is a fact of life in Ugandan clinics, though there are a few ways to approach this. For one thing, specks of dust on the lens appear stationary in the image even when the slide is moving; so we can just look for any blobs which never move and make sure they never trigger a detection.