XBee + GPS + Google Earth

Jay Kickliter

In case you don't know, Google Earth can be controlled by AppleScript (on Macs, Windows probably has similar options). I took a couple of projects I've been working on, and came up with a cool little real-time google earth tracker.

Equipment:

Prop protoboard
GPS
5 degree of freedom board from Sparkfun
XBee 900 100 mW modules

On the computer I have a cocoa app monitoring the XBee over a serial line, and parsing the strings coming over it. Through AppleScript, the cocoa app moves the Google Earth's camera around, to follow the remote tracker. For fun, I even had the tilt of the camera be adjusted by the tilt of the remote IMU, which was kind of annoying so I turned it off. Also, the azimuth of the camera matches the GPS's course over ground. So the effect is that google is following the remote tracker. The annoying thing is that GE doesn't allow for dropping crosshairs via apple script, so it can be difficult to tell where exactly the camera is looking at. Maybe on the windows side there is more control, I don't know. Even at 900 MHz and 100 mW, the XBee doesn't really work more than a block away here in NYC. I think I'll take it into Manhattan were GE is full of 3D buildings and see if I can monitor a remote fly-through between the buildings. I'll keep the computer-side antenna outside to see if that gets me better distance.

Anyways, I just did this for fun, so the code isn't post-able yet, and maybe never will be, but if anyone wants to to do something similar, PM me and I'll email it to you.

I have a question for you guys. According to the manual, this XBee should have a latency of only a few ms. But I'm getting a latency well over one second, any ideas?

Phil Pilgrim (PhiPi)

Interesting! You hardly need onboard cameras anymore!

As to latency, the XBees probably use packet transmission. If the amount of data that you're transmitting is less than one packet long, it could be waiting to "fill" the packet before transmitting, giving up after a second or so, and filling it with nulls. You could do the same to test the theory: just send a bunch of zeroes or other fluff between data bursts and see if this speeds things up a bit. Another thing that will affect latency is distance between units, obstructions, etc. Since the XBees are error-correcting, it may take muliple packet tries if the receiver detects errors and asks for a retransmission.

-Phil

Jay Kickliter

Seriously Phil, with large local cache of Google Earth and the ability to interface with it 100% (which they don't allow), you could remotely fly an RC plane.

You're right about the latency. There was a setting to lower the time-out delay. It still feels sluggish though. I think there is a way to force it to transmit by using flow control.

Chris Savage

Jay,

I recently submitted an article to a magazine which should be published in June for a GPS tracker that logs the data to a USB Thumb Drive in KML format. When you double click the KML file, Google Earth shows your path. This sounds like a real-time version of that. Is this a good analogy?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

J. A. Streich

I was thinking about doing something like this with my bot. Grr, you beat me to it. Not that I won't still do it...

What setting did you change and how did you change it, Jay. I'm running into latency/delay with my joystick controller and if this setting can fix it, I'd be very happy.

Jay Kickliter

Chris, yep, that about sums it up. It really isn't practical unless you're with in line of sight of the other tracker. Instead of using Applescript, I've moved on to using KML directly. I read about other people doing it that way. I load a KML into GE whose job is to just reload another KML at a set interval, which is actually more like a real-time version of what you're doing. This way I can drop placemarks or creating a 3D line from a live position set.

J.A., somebody beat me to this a long time ago, so don't feel bad. As for fixing the problem, I don't think I have if fully cured yet. I lowered the timeout period. Also, using a the fasted serial link between the XBee and whatever is connected to it helps. As far as lowering the timeout period, you can do it with the XBee XCtu software, or manually through AT commands and the terminal. I think either using flow control to force sends, or using API mode will be necessary to totally get rid of the lag. As it is now, I still wouldn't be able to control a car, let alone a plane. There's a guy on DIY Drones who is using an XBee and a Prop to control a plane, and he says he cured the latency problem. He's using API mode, which I still don't understand.

J. A. Streich

I upped my baud to 19200, and set RO (timeout) to 0 (as Salem suggested for XBee Boe Bots, so it should work with my propeller based bot). My 9v died, so I tried it with BOE's battery clip which can't power the servos... Communication worked, but I won't know what the latency until I have a new 9v. Alas, it's late, so I'll have to stop tomorrow.

steve_b

I'd be interested to know how you interface to the serial port via cocoa/applescript!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<FONT>Steve



What's the best thing to do in a lightning storm? "take a one iron out the bag and hold it straight up above your head, even God cant hit a one iron!"
Lee Travino after the second time being hit by lightning!

Jay Kickliter

Steve, for serial I'm using an open source class called AMSerialPort. I don't know of anyway to open a serial port with AppleScript. I really don't like AppleScript, and I only used it in this instance since I didn't know any other way to manipulate Google Earth.