Tag Archives: behaviour

Mongoose 2000 in the wilds of Uganda

One of our most ambitious projects: Mongoose 2000, is now up and running after 6 months of testing. This is a Raspberry Pi and Android tablet system to synchronise and store masses of data for a long running behavioral experiment recording the activities of packs of mongooses in the field site in Uganda. They broad aims of the project are to study mongoose behaviour in order to understand the evolution of society.

use

The timespan that we are working with is long, and the location – while not as remote as it could be (there is some internet access and power) required some consideration – so this was a project where we really needed to employ an appropriate technology approach which is manifested in various ways:

Open source software: means that Foam Kernow are not a bottle neck to continued development, as we do not have exclusive control over the source code (which is released into the commons). New developers can be found if required (for whatever reason) who do not need to start from nothing – this gives the research team more control and future proofing.

Use of commodity hardware: it’s likely that the hardware in use will become obsolete in this timeframe. The lifespan of android software should mean it can be installed on compatible devices for a long time, and the team can make use of advances in sensor or battery technology. The raspberry pi we are using is already an older model now, but as it’s a standard linux setup we can easily move it to other machines in the future. Currently it acts as an ‘appliance’ which just needs to be turned on, but we can add a web interface to control it from the tablet – or eventually replace it with a peer to peer syncronisation system.

The Ugandans working on the project have an healthy DIY relationship with technology, they expect to be able to repair or modify things themselves, and I’d like to figure out ways we can work with this more. The UAV toolkit project provides some indication of what can be done with programming these kinds of devices in the field. Part of the decisions on the hardware (and the design of the software, e.g. using a scheme interpreter) were to use devices that were open to a more end-user programming approach in the future.

use2

use3

Syncronising a tablet with observations previously recorded on the Raspberry Pi:

use4

Wild Cricket Tales

We have a brand new citizen science project starting with the wild crickets research group at Exeter University! These researchers are examining how evolution works with insects in their natural environment, rather than in lab conditions. In order to do this they have hundreds of CCTV cameras set up recording the burrows of field crickets, resulting in many hundreds of hours of footage. This footage needs to be watched in order to determine the various events that make up the life story of the insects. Each individual it turns out has quite distinct characteristics, and we thought it would be fun to open up this process and make it into a citizen science project – partly to get some help and speed up the job, but also the vast quantity of material (hundreds of thousands of hours in total) has it’s own appeal – and it would be great to be able to use it for a creative project like this.

Here is an example of the footage, rather sped up – check out the frog and the sudden switch to daylight mode:

This is the first interface sketch – my plan is to focus on the individual insects and visualise the information coming together by displaying their characteristics, along with which players are their ‘biggest fans’, i.e the people who’ve put the most time into tagging them:

sketch2

The video tagging interface itself is the focus of the first prototype I’m working on at the moment. I’ve got a database set up for storing relationships between crickets, their movies and events that people create based on a combination of django and popcorn.js. Below is the first attempt, the buttons add new events as the movie plays that get recorded on the database, and displayed on the timeline bar at the bottom. Currently all players can see all the events globally, so that’s one of the first things to figure out how to handle.

ui-1

Mongoose 2000

Mongoose 2000 is a system I’m developing for the Banded Mongoose Research Project. It’s a behavioural recording system for use in remote areas with sporadic internet or power. The project field site is located in Uganda in the countryside and it needs to run for long time frames, so there are big challenges when it comes to setting up the system and debugging it remotely.

In order to make this work we’re using a Raspberry Pi as a low power central wifi node, allowing Android tablets to communicate with each other and synchronise data. There are a couple of types of observations we need to record:

  1. Pack composition: including presence in the pack, individual weights and pregnancy state.
  2. Pup focal: studies of individual pups, who’s feeding them, when they feed themselves or playing.
  3. Group events: warning calls, moving locations, fights with other packs.

We also need to store and manage the pack information, so names, collar and chip ids of individual animals. The data is passed around a bit like this:

web

The interface design on the tablets is very important – things may happen quickly, often at the same time (for instance group events happening while a pup focal observation is being carried out), so we need multiple simultaneous things on screen, and the priority has to be on responsiveness and speed rather than initial ease of use. For these reasons it has similarities to live music performance interfaces. We can also take advantage of the storage on the tablets to duplicate data on the Raspberry Pi to add redundancy. Data is transferred from the field site by downloading the entire database onto the Android tablets, which can then be emailed using the normal internet, either when it’s working locally or by taking the tablets into the nearby town where bandwidth is better.

IMG_20131105_185918

The project is a mix of cheap, replaceable hardware and mature well used software – Raspberry Pi’s mean we can afford a backup or two on site, along with plenty of replacement sdcards with the OS cloned. The observation software can also be updated over the Android play store (for bug fixes, or changing the data gathered) without any changes required on the Raspberry Pi. The platform is based on the one I built for the ‘Crap App’ along with experimental stuff I was doing with bike mounted wifi nodes with Kaffe Matthews, and includes SQLite for the underlying database on both platforms (providing atomic writes and journalling) and TinyScheme for Android and Racket for the Raspberry Pi allowing me to share a lot of the code between the hardware platforms.

Little J

little-j-roundel+text Little J is a research project to explore citizen journalism, and find ways to use technology to connect journalists working on local news (an industry currently under threat) with the public, grouped under the term “hyperlocal news”. This is a project between REACT (Research & Enterprise in Arts & Creative Technology) and Behaviour (a psychological creative agency based in Cornwall) and is focused on the communities in and around Port Talbot in Wales as a test bed for a series of events.

The project is a great chance to explore Ushahidi more deeply, after using it for borrowed scenery and halfway through working on doris we can start looking at adding new features. I’ve started by setting up a test site to fiddle with and we are now focusing on creating a wide range of methods for people to get their stories into the site and into the hands of the journalists as we can. The obvious place to start is a facebook app, and looking at ways to integrate social media with the database of stories and do it in a way that encourages some good information. Another area to explore are mechanisms for encouraging people who are specialists in specific areas to be represented by new kinds of reputation systems. As a prototype we will be covering a lot of ground quickly, finding what works best for future development.

You can read more about this on Behaviour’s site and on the REACT blog.