My fellow Thingicans and Thingocrats; thanks to your help, this project is well under way!
The Wowwee Rovio ( http://www.wowwee.com/en/products/tech/telepresence/rovio/rovio ) is a IP-based Wifi Mobile Webcam, sometimes marketed as a simple telepresence robot. At a price point of about $200, it's money well spent; the system is very well designed both in hardware and software, and you'd have a /very difficult/ time duplicating the ability of this robot for twice the price.
The robot itself is rather hackable, with a well-documented and full-featured web API. The source code to the mainboard was grudgingly released a while back, too, but I've not examined it and I'm told it's useless.
The robot uses a system from Evolution Robotics called "Northstar" for indoor spatial positioning. The system is very simple at it's most basic concept; the robot has a tiny pinhole camera mounted on it's top. The camera looks at the ceiling for two infrared dots that are projected by a 'Truetrack Beacon.' You could think of it as working very much like a Wiimote.
Evolution Robotics makes sales-level information available here, for an overview of the system: http://www.evolution.com/products/northstar/
The system uses an 'encoding' to allow the Rovio to uniquely identify up to 10 different tracking beacons; the base station it comes with (beacon #0) and up to 9 additional beacon units, which WERE sold separately for a very short time (advertised here: http://www.wowwee.com/en/products/tech/telepresence/rovio/truetrack-room-beacon ). The additional beacon units have a simple switch to select the ID.
Sadly, the Rovio is a dead-end product; the manufacturer (Wowwee) never supported it very well and now has confirmed that they have stopped production and don't intend to ever bring it back.
New tracking beacons cannot be gotten for love or money, and despite the popularity of this product among hackers at one point, there is no data on the actual signaling protocol used by the Northstar system.
Unfortunately, they won't talk to me, and they want /thousands/ for the development kits for the Northstar product, so following legitimate channels is out. In addition, if they /were/ to fork over the details, I'd bet it would put my under an NDA that would prevent publication.
As I don't have /ANY/ tracking beacons (except the one built into the base station), my Rovio is somewhat limited in it's automatic positioning abilities.
WHAT WAS PREVIOUSLY KNOWN:
All the gritty information on the Rovio seems to be concentrated on one site; robocommunity.com.
Here's a thread where some folks dissect the robot and tracking station:
The board we're interested in here is the round one, which is the Northstar beacon projector PCB. There's a lot of great info on it specifically on this thread and the comments:
Unfortunately, no information on how it actually signals.
WHAT I'VE LEARNED SO FAR:
From looking at the photos in the above thread before I got my robot (I've only had it for one day!) I'd guessed that the signaling protocol was as simple as flashing the two IR lights at different rates. That seems like the simple and obvious method to tell both one light in a beacon from the other, and to tell one set of lights for a beacon from the other.
So I opened up my beacon in the base station (instructions in the linked thread), and put a scope on the transistors that drive the LEDs. From my photos, you will see my conjecture seemed to be correct; the LEDs were being blinked at very specific and different rates.
Wiring up a quick circuit with an Arduino to blink a couple of LEDs at the same rate, I took the Rovio and exposed it to my LEDs.
SURE ENOUGH, it immediately recognized it as Tracking Beacon #0, the home station. SUCCESS!
The MAJOR problem is - I only know the signaling speed to reproduce beacon #0, and you can't have two #0s in a network, so what I have so far is only good for people whos base station is destroyed. With the signaling rates here, you can easily build a charging/dock/beacon0 unit from scratch.
If you want the actual rates, they're in my o-scope photo(s). :)
I built an automated scanner, which I'll leave to run all night, but it's already produced results! I have a workable ID for NAV BEACON #1. That's one down, 8 to go!
Even if I find them all, though, I could STILL use someone with a scope and real beacon to double-check my work...
I'll be posting some pretty graphs and photos and probably the fuzzing circuit and software shortly.
I've been running my scanner for the last day and I'm posting some quick charts as well as the data I've gotten so far. I'm not going to make any claims the data is good, but it has yielded some interesting points!
I also uploaded the latest copies of the scanner software but I'm not sure I've made any noteworthy changes.
I've built a simple tracking station and placed it in my home, and begun testing. Two things I can report immediately:
1) Getting proper coverage from an LED is not easy, and I'll either have to use an array of LEDs, or a lens, or try the wide angle LEDs I have on order, or some combination of the above.
2) The actual frequencies for room ID #1 reported by botman work better than my 1/3rd frequency in practice.
This is mostly a summary of what's in the comments below.
I've decided to move forward using stations based around a pair of transistors (I'll likely use some FETs since we're going to push > 100ma - maybe much > and also because they reduce component count) driving current into a pair of TSAL7200 LEDs (sourced here: http://www.rentron.com/remote_control/IRLED.htm) with the gates switched by a Atmega8, which can be programmed to a given station ID through SPI.
I'll post the circuit the way I have it laid out so far; if anyone can come up with a good single-sided layout for printing and etching at home you'll be doing better than I am; I keep ending up with a few jumper wires required. Keep in mind this circuit hasn't actually been built or tested as posted.
Here's a quick reference of the known station ID frequencies:
3030 and 2010 = Room 0
3150 and 2070 = Room 1
4170 and 3210 = Room 2
4290 and 3330 = Room 3
4410 and 3450 = Room 4
4530 and 3570 = Room 5
4650 and 3690 = Room 6
4770 and 3810 = Room 7
4890 and 3930 = Room 8
5010 and 4050 = Room 9
HERE IS A LINK TO THE THREAD I STARTED AT ROBOCOMMUNITY just for completeness, but let's be honest, those forums are a bit dead. I think I missed the exciting times for this product. :)
SOME ACTUAL INSTRUCTIONS!
There are a perl file and Arduino project (c++ avr) attached.
Wire up two infrared LEDs to an arduino, one on pin 9, the other on 10. Put them directly on or above your bot's sensor and run the test() function in the perl module to check to make sure everything is working. You should get the max value for signal strenght (65535) when it is right, and something low when it is wrong.
Then you can use the perl file to scan whatever frequencies you think Northstar might have used and make your own beacons from them!
I'm still scanning, more details as they arrive - but it's going VERY well. I've attached a fancygraph of the results that are in thus far. My fiance would kill me for the unlabeled axes; they are X+Y frequency of LED blink in hz, Z = bot's reported signal strength. The script also tracks which beacon ID is reported for each sufficiently strong signal, but I couldn't figure out how to get it on the graph. :)
I'll post plans for a circuit as soon as I've developed it further than "stick a couple LEDs on a Atmega, switched by transistors."