By their very nature, monkeys are incredibly mobile. They are a self-organizing network. They are the perfect self-forming “mobile nodes”.
How can we design according to wildlife constraints, and use these constraints to our advantage?
I’ve been thinking lately about how to use monkeys’ natural advantages and strengths for data sharing purposes. I’ve come up with a great idea for my final project in our “Wildlife Observation and Monkey Tracking” class that leverages primates’ existing behaviors: their mobility and consistent roaming patterns in the forest, their frequent social interactions with one another, and their loyal returns to the salt licks where camera traps have been placed.
I would like to design an asynchronous mobile data mesh network and communications protocol for monkey radio collars that will tell primate biologists 1) where the monkeys travel, 2) when and 3) how often monkeys come into proximity with other collared monkeys, and 4) where and 5) for how long these social encounters occur.
What is a data mesh?
A data mesh is a distributed storage network that uses a synchronization system to update copies of data sets between two or more devices, according to a set of communication protocols established among the devices.
In the “Mobile Monkey Mesh” that I would like to design, each collared monkey carries a recording, storage, and communications device (in this case, a radio collar) attached to its body that serves as a “mobile data node”. Each device records and stores GPS data about the monkey’s location and proximity event* data whenever that monkey comes into contact with another collared monkey. The camera traps and salt licks also each house a recording, storage, and communications device inside the camera casing that serves as a “stationary data node”. Each of these devices also records and stores proximity event data whenever a monkey comes near the camera trap. So, for example, if we have 8 collared monkeys and 4 camera traps, then we have a total of 12 data nodes in our mesh.
Whenever one of these storage devices comes in proximity of another storage device, the data being locally stored on each device is shared across devices. If the data has already been synced before in the past, then only the changes made in each device since the last synchronization will be exchanged between devices, and information about the date / time of each sync is recorded to both devices. In this way, the data captured about many monkeys is shared and distributed across multiple devices, mobile and stationary, in an asynchronous, opportunistic fashion.
By syncing data from each other on-the-fly, the monkeys are actually doing most of the legwork required for data logging and collection in the depths of the jungle, which hopefully would save biologists a lot of time and energy otherwise spent gathering this data from one tranquilized monkey at a time.
What is used in the field today?
The monkeys’ roaming range is anywhere between 4 hectares (200x200m) to over 600 hectares (2×3 kilometers). Some of the monkeys have a very small geographic range in which they roam, and others have a much larger geographic roaming range.
At present, primate biologist Anthony Di Fiore and his team use three different types of radio collars to track the physical movements and behaviors of 10 local species of monkeys in the Yasuní Biosphere Reserve in the Ecuadorean Amazon forest:
- traditional radio transmitter collars,
- collars with radio and GPS transmitters,
- collars with radio transmitter and proximity sensor
All three of these solutions work fairly well individually, but they require the biologist to locate a specific Monkey “A” via radio telemetry (which could take several days), retrieve that specific Monkey A’s data, and then repeat the process for all collared monkeys in the study group which is very time consuming, physically exhausting, and, from a data collection standpoint, inefficient.
Asynchronous mobile data mesh network
What if it were possible to retrieve Monkey A’s data from Monkey “B”? Furthermore, what if it were possible to not only retrieve Monkey A’s data from Monkey B, but to retrieve the most recent data for Monkey “C”, Monkey “D”, and Monkey “E” all at once just by finding any given monkey in the group who happens to be near you?
To do this, we would need a single collar that incorporates all three of these technologies of radio, GPS, and proximity detection, with a simple communications and data syncing protocol that sends and receives data in a point-to-point relay between nodes whenever those nodes come into physical proximity with one another.
Monkeys as mobile relay nodes
One of the biggest challenges about communications in the jungle is our limited access to cellular towers; it’s very difficult to establish traditional communications networks or wifi clouds that normally enable us to sync data across a network cloud. At the Yasuní Biosphere Reserve, there are currently no cell towers anywhere within roughly 10 km of the Tiputini Biodiversity Station.
I’d like to explore a way around this dilemma by designing a mobile mesh topology ecosystem that relies on the monkeys themselves as mobile relay nodes, plus the placement of a few stationary nodes at the salt licks / camera traps or other commonly known waypoints.
In this way, as long as a given node, Monkey A, can reach another node, Monkey B, that is acting as a router in the mesh, then node “Monkey A” remains in the network. This is particularly useful for monkey tracking, since some animals wander further than others, and not all of them wander together in a pack at any given moment, but most all of them interact socially with each other from time to time.
In addition, if a hub node were established at a salt lick, a place where we already know the monkeys like to come to snack, then we could even write a config.xml file on that hub node that would update the other mobile nodes when one monkey came to the salt lick, because that monkey’s updated device would then carry the updated config file to the other monkeys whom it came in contact with.
How would it work?
Each collared monkey would have its own unique electronic identifier, radio and GPS transmitter, and 4GB or 16GB mini-SD card storage capacity. Each monkey’s device logs GPS data for that individual according to a prescribed schedule (e.g. every hour or two), so as not to waste power, and each device broadcasts a unique ID code (ping), while simultaneously listening for others nearby.
When Monkey A comes within a set distance of Monkey B (typically as determined by the radio range of RFID devices attached to the animals, e.g. 10 meters), Monkey B’s receiving device will record a date / time stamp of when the encounter occurred, how long the encounter occurred, and the ID code of Monkey A’s transmitting device. Monkey A’s device will also listen and record the same. When this event occurs, it will then trigger a data sync protocol between the two mobile nodes, such that Monkey B’s receiving device will ask Monkey A’s transmitting device if it has any data stored that is different than its own data set. If so, the delta in the data sets will be bi-directionally shared via radio electric pulses. Like the example above, Monkey A’s device may be a gold mine! because it stores the most recent data for Monkey “C”, Monkey “D”, and Monkey “E”, so Monkey B’s device will receive the entire updated data set all at once without ever coming into contact with the other monkeys in the group.
The strength of this design is that the data is not lost if one animal is lost or suddenly becomes untraceable. The data sharing architecture in this system is redundant, so that copies of the data are stored at each end point. I think this flexibility is very important in austere environments where you cannot always depend on a fixed, central point.
Here is an architecture diagram to show how this works:
Sources of inspiration
In 2006, after returning from Afghanistan, I helped run an international humanitarian disaster-response exercise called Strong Angel III that focused on experimentation in the use of cutting-edge techniques and technologies to facilitate improved information flow and cooperation across the civil-military boundary in post-disaster and post-conflict field environments. As part of this event, the SA-III team experimented with the “Pony Express“, an asynchronous data mobile mesh system constructed from a 4WD Jeep with wifi router and Groove mobile relay server. They drove a route twice each day that allowed the formation of a temporary wi-fi cloud for 2000 feet around the car, thereby syncing all waiting information in Groove workspaces between the relay server in the vehicle and the users within the temporary cloud.
This gave me the idea for a Mobile Monkey Mesh!
Based on the Pony Express model, Microsoft built and released FeedSync, which combines subscription models like RSS with data synchronization. FeedSync then evolved into Mesh4x which builds a data mesh that allows for two-way synchronization of information in a peer-to-peer symmetric way. Microsoft also released Live Mesh, based on FeedSync technologies, that allows files, folders and other data to be shared and synchronized across multiple personal devices and up to 5 GB on the web. Google has also developed something similar called Table Cast.
Our worst enemy in the field is always power. How much power is needed to run this asynchronous mobile data mesh network? That is what I need to research, because that will really determine the sustainability and reliability of this design.
There are a couple of ways to “trim” our electrical waistlines in this system. One, I already mentioned above, is to prescribe a fixed schedule or interval for GPS retrieval and proximity pinging, so that we’re not constantly draining the battery power.
Another power saving method is to prevent ‘memory flood’ on the data storage devices by setting the data sync process to only run if the proximity event* has occurred more than one or two hours ago. This will help reduce power consumption and redundant logging. The Sirtrack Proximity Collar (Proximity E2C Logger), currently used by Di Fiore in the field, works in this same way to anticipate the problem of memory flood when animals den together or when three or more animals meet at once.
Some potential limitations to consider are related to the proximity sensing devices. When we ran some small tests with the Sirtrack collars in class last week, the results were only semi-accurate both times. One of the Sirtrack collars seemed to record data more accurately than the other. In 2009, ITP students Carolina Vallejo and Kenny Chiou tested proximity event detection using infrared sensors. Based on their tests, they observed that the IRDA sensors may need a direct line of sight. Therefore, not all proximity interactions will be recorded. My suspicion is that this could be the case for the RFID sensors as well.
I found a research study online “New Radiocollars for the Detection of Proximity among Individuals“, conducted on raccoons in 2006 by Suzanne Prange and Trevor Jordan. The findings were published in the Wildlife Society Bulletin. The researchers found that the “recorded contact duration deviated from actual time by ≤3 seconds for short-duration (10–300 sec), and by ≤30 seconds for extended-duration (8–14 hr) contacts recorded as a single event. There was a tendency for the collars to record extended-duration contacts as multiple events, with the frequency dependent on settings.” And they go on to say, “We downloaded 35 of the 42 proximity detectors deployed on free-ranging raccoons. Of these, approximately 57% were functioning properly, 9% exhibited problems apparently correctable in the field, and 34% exhibited problems not correctable in the field.”
What kind of data can we get with the Mobile Monkey Mesh?
Location data for an individual’s position:
- date / time stamp (month, day, year, hours, minutes, seconds)
Event data for two or more individuals:
- unique IDs
- frequency of proximity
- duration of incidences of proximity
- location data for two or more individuals triggered by a proximity event (longitude, latitude, altitude, date / time stamp)
Synchronization event data:
- unique IDs
- date / time of sync event
- error log (sync failure)
What hardware is needed for this collar?
The current Sirtrack Proximity Collar (Proximity E2C Logger) weighs 45 grams and lasts 170 -200 days (6 – 8 months) with VHF turned on. VHF frequencies available from 148.000MHz to 173.999MHz. The collar is made of leather and generally is placed around the monkey’s neck, with a width of 10 mm and circumference range of 160-200 mm. This device already contains an RFID transmitter / receiver, radio transmitter, real-time clock, battery, and storage container, so I would need to add the GPS component and the data sync protocol code.
Traditional radio collars have a duration of 18 months – 3 years, depending on battery size. However, adding the GPS transmitter reduces the field life to approximately 8 months (that is using a very intermittent schedule attempting satellite fixes only every 1/2 hour, during a 12-hr daytime). Given that the proximity collars are also said to last 6 – 8 months, I would venture to guess that this Mobile Monkey Mesh collar would last approximately 6 months in the field.
If I were to design a DIY collar myself, then I would need the following:
- radio transmitter
- GPS transmitter (30-45mA, 5-9g)
- RFID transmitter / receiver
- real-time clock
- storage and logging device (OpenLog is 2mA idle, 6mA at maximum recording rate)
*A proximity event is where two animals are determined to be within a predetermined minimum distance of one another, which will typically vary between different species.