Primate Biologist, Tony DiFiore, tracks monkeys in the Amazon rain forest in Ecuador:
At present, he is using the Telemetry Solutions RS 4000 GPS collars to track the monkeys’ locations at specific times during the day / night. The biggest difficulty regarding the retrieval of GPS data from these collars (see an example of a collar below) at present is finding the monkeys in the forest and positioning the antenna for a successful download. Currently, Tony and his research assistants must track the collared monkey via radio telemetry, and then stand within 10-20 meters of the monkey in a heavily wooded area with dense foliage and moisture, point the antenna towards the direction of the animal, and then manually press a button on the Telemetry Solutions software to activate download of the GPS data.
Collar example:
Suzanne Kirkpatrick and I worked together in an attempt to make this data gathering process easier for primate biologists who track monkeys in the field. We know that the monkeys come to the salt lick a few times per week, and we know that the camera trap could have a motion sensor connected to a microcontroller to sense when an animal has passed by the salt lick. Our project idea is to set up an Automated GPS Data Downloading base station inside the camera trap that will automatically download GPS data from a monkey’s collar when it passes by the salt lick.
Suzanne and I decided to explore the two paths below to solving this problem, in order to see which solution would be the most efficient and effective.
Solution 1: USB Bus Pirate
Our first path was to investigate using a USB Bus Pirate, a universal serial interface tool, to “sniff” the GPS data incoming from the collar via the UHF antenna to the PC.
The Bus Pirate connects to a PC USB port. We can program a few commands to the Bus Pirate from a serial terminal on the PC, such as “read data” and “write data” that will make a copy of the GPS collar data being sent to the Telemetry Solutions software program. There is a standard set of bus pirate communication commands that we looked at to set the mode to UART (asynchronous serial), select the data display format, etc.
We ran into a block when we needed to set the PC side serial port speed, because we didn’t know the baud rate (bps) that the Telemetry Solutions base station is using to download data via USB. We asked Telemetry Solutions for this information, but they didn’t respond to our request.
If we had known the baud rate, then we would have tried to use some of the bus interaction commands, such as bus start / stop conditions, read byte, write values, and repeat.
Solution 2: Robot Class
Upon discovering that Telemetry Solutions had a new product similar to what we were interested in building, we contacted Matt, their engineer, to inquire about how this product works.
Telemetry Solution’s product: Automatic GPS data recovery system
The main difference between their product and our idea is that we would like to conserve power and lower the cost of the download unit (which currently costs $2,500) by having it function through a motion detector, so that it would only be using power once motion is detected. Telemetry Solution’s system is automatically set up to ping on a constant basis, continually searching for collared monkeys and therefore having to use a lot more power. To top it off, their automated software costs an additional $500.
In short, we are interested in designing an affordable product that will conserve power by using a motion sensor to detect when any animal has passed by the mineral lick, which will then trigger Telemetry Solution’s Automatic GPS data recovery system, and then to detect if any of those animals were the collared monkeys whose data we are trying to capture.
Our solution would be to write a batch script, similar to the “Automator” Apple scripts in the Mac operating system. According to Wikipedia, “In DOS, OS/2, and Microsoft Windows, a batch file is a text file containing a series of commands intended to be executed by the command interpreter… When a batch file is run, the shell program (usually COMMAND.COM or cmd.exe) reads the file and executes its commands, normally line-by-line. Batch files are useful for running a sequence of executables automatically and are often used to automate repetitive or tedious processes.
When we contacted Matt from Telemetry Solutions in regards to the Automatic GPS data recovery system, we asked him if there would be a way to build a batch file that talks to their software code for the Automatic GPS data recovery system. We also wondered how much power this system requires and how it’s powered. Finally, we asked about the range of the base station.
Telemetry Solutions eventually responded with the following answers to our questions:
1. 32mA is the base station current drain during a remote download.
2. The Auto Download software has a settings.csv file. You can probably affect the settings.csv file with motion sensors to control the software which controls the base station
3. The base station is powered by a battery, not getting power from the computer’s USB.
4. No, the only difference between the base station that Tony uses now and the automated system isn’t just the software, we need to modify the base station, it only takes us 1 day to do that. So it needs to be sent back.
5. The range of the base station is not affected by the auto download software, it will work at the same range whether being controlled manually or by the auto download software.
In order for you to obtain the software you just need to return the base station and we will make the modification. The software sells for $500.
After receiving this response, we began researching different methods for how to automate the software; we considered using Girder early on in our project. An automation software, Girder seemed relatively easy to use at first, although we soon realized it would not be ideal for this particular project once we explored it further and realized it was actually quite complex. Instead, we decided we should stick to a program we are already familiar with–Processing.
Once we moved on to Processing, we became very interested in how the Robot Class might come in handy.
Will Jennings and Erica Newman have apparently worked with this class for another project involving Kinect opening the iTunes software, which proved to be successful–having looked at their example, we are excited at the possibility of using the it for our project as well.
In order to be able to use the Robot Class, we need to know the X and Y coordinates of our mouse. To do so, Suzanne and I downloaded a very useful program called xScope (the trial version, which lasts a lengthy 40 hours).
Aside from using the Robot Class to automate the GPS software, we are interesting in how the Robot Class can be used to “wake up” the unit, so that power can be conserved when motion is not detected, and data is only acquired when necessary.
While both of our solutions are good attempts at making our own custom script solutions, neither one of them yet solves the problem of waking up the computer from sleep when motion is detected near the salt lick. Further investigations are required to figure out how to conserve power and how to wake/sleep the computer after each automated download.
In sum, we were fairly limited in our project experimentation by the gaps in our knowledge about how the Telemetry Solutions automated base station is configured. Had we known more about the product’s power system and general power consumption, and the specifics regarding the base station software, we could have gone deeper in our pursuits to build a solution that would really integrate with the Telemetry Solution RS 4000 GPS collars.
UPDATE:
We now have a working Processing code using Robot class, which I have cut/pasted below. While this code is not complete, it currently allows us to have an idea of how a motion sensor (or for the purposes of our experimental code below, a “counter”) would trigger the robot code to wake up the computer and move the mouse towards the software, so that the data gets downloaded. A small part of the code also includes a “key pressed” command–which we aren’t planning on actually using on our final sketch, but was useful in getting to study the various Robot Class functions.
The current code:
//ROBOT CLASS WAKING & SLEEPING COMPUTER
//import libraries
//use robot class to wake computer up/put it to sleep
//trigger robot class w/ incoming serial data from motion sensor (using a counter in this example)
import java.awt.Robot;
import java.awt.event.InputEvent;
Robot r;
int xCoor = 400;
int yCoor = 0;
int count = 0;
int counter = 0;
void setup() {
background(255);
size(950, 500);
//create robot instance – our friend Erica told us we should include this part!
try {
r = new Robot();
}
catch (Exception e) {
println(“error”);
}
}
void draw() {
//trigger mouseMove
// if(monkey passes in front of motion detector)
// {
// if (button pressed ==false) {
//r.mouseMove(x coord, y coord);
// }
//}
//substitute counter for sensor
counter++;
println(counter);
if(counter == 100){
counter = 0;
count++;
r.mouseMove(800/count, 300/count);
}
}
void keyPressed(){
if (key == CODED) {
if (keyCode == UP) {
yCoor –;
r.mouseMove(xCoor, yCoor);
} else if (keyCode == DOWN) {
yCoor++;
r.mouseMove(xCoor, yCoor);
}
}
}
Recent Comments