Robot to PC – 2 Way Wireless RF
I have been experimenting with wireless communications between PCs and microcontrollers for several years, looking for the ability to remotely monitor and control my robot. What seemed to be a fairly simple task turned out not to be. But I now have a very functional wireless interface that does this:
I can monitor all of my important robot variables and send commands and variables to the robot. The PC software, MailboxPC, acts as a master and requests data from the robot, updating an internal data base that mirrors a block of RAM in the robot’s microcontroller. The RoboControl screen, shown above, interfaces with MailboxPC which is a Windows ActiveX server. The system uses low cost RF radio modules and works at comparatively low baud rates (mine works at 4800 baud) at distances that cover a normal house. You could easily have such a system operational for under a $100. Expect to spend some time on this, even with the information I provide. The PC software provided should be usable by all Windows users. The Atmel AVR drivers are written in AVR GCC 3.2 and come complete with code and executables, primarily for an ATMEGA8 target. AVR GCC is ANSI standard c so porting to a different architecture is possible (not dead simple, but possible).
There are RF modems out there that, for a couple hundred bucks, will get data from the uC UART port to the PC RS-232 port. That solves just one part of the problem. The system I describe here takes data from your uC RAM right through to an application program like RoboControl.
If you plan to put together your own RF system you will need a few skills and a few tools. You need to have a functional microcontroller development environment using the c language, preferably for the Atmel AVR. If you plan to develop a Windows application interface such as RoboControl you will need skills in a Visual Windows language such as Visual Basic or C++ Builder. For troubleshooting both a second PC with a spare serial port and an oscilloscope are very valuable. I have an RS-232 cable with a MAX233 (RS-232 to 5V interface) built in which is very handy during testing. Much of what I've described can be put together on a breadboard - that's where I would start. You need some serial cables with all pins connected through. You'll need one that has pins 2 and 3 reversed - a Laplink or crossover cable.
Summary of Attachments
PC Robot Interface, written in C++ Builder
PC Screen Shots
SPI slave routines and excerpts from my robot code showing MB Ram setup and access
Wireless RF in General
Compared to our familiar hardwired UART link, wireless RF has a number of constraints that make it more challenging, and help explain why we’re not all doing it already. Here is a good site for more information on RF data transmission issues.
The low end RF modules run at 2400 baud while high end devices work at rates up to 100 KBaud. Couple this with the 2 bytes/byte protocol and sync characters and you cut the rate again. I have been usefully using 4800 baud modules and can sustain data rates up to 120 bytes per second. As usual speed costs. Unless money is not an issue you will likely be operating a lower rates than you would be with a wired connection. 120 bytes can contain a lot of information however. My robot data amounts to about a quarter of that so I can update the display four times a second. Use one byte characters wherever possible and pack true/false variables into bits of a single byte to reduce the byte count.
Radios of this type allow only half duplex communication, which means communication can only go one direction at a time. While this is not an insurmountable problem, it does force the system designer to think about how devices interact. You cannot allow each end to "talk" whenever it pleases or some transmissions may get lost. The best arrangement is to declare one device to be the "master" and have it control the flow of data. This would be the situation where a master polls slaves for data – the master sends a request, the slave responds with information. In my setup, the PC is the master although this could be reversed if desired.
Radio communication is a much less secure means of data transmission than wire. Radio receivers go to great length to filter out an endless stream of interference to pick out the desired signal. Even then much gets through and the packet controller must filter out the incorrect characters received.
The result is a variable data dropout that varies with distance, location, time of day, your neighbor’s use of appliances and who knows what else. In good reception areas 100% of data will be received – as reception drops off, the dropout rate will rise to the point of unusability.
As a result, the receiving equipment must be capable of handling data loss situations. For critical operations, a handshake may be set up with a retry routine.
RF receivers need to "sync" with the transmitted signal. If the transmitter shuts off (as it must for 2 way communication) sync is lost. The transmitter must send several sync characters before the radio can reliably receive data. If the transmitting signal drops off momentarily sync is lost and the data packet is lost. This can occur due to sending several "0"’s for instance.
Character Set Limitations
As a result of the need for synchronization, characters with flat bit patterns, i.e. $00 and $FF can cause the radio to lose sync. A subset of the ASCII character set that has bit patterns close to 50% on and 50% off (called 5050 characters) is used to ensure good communications. This infers that 8 bit communications can not be used. Data is first converted to ASCII Hex, i.e. the number 168, which is equivalent to 0xA8 hex, is converted to "A" followed by "8". "A" and "8" are in turn converted to 5050 before transmission and converted back at the other end. The software abandons any packet that contains non-5050 characters.
The software drivers at each end look after the messy details of converting from multi-byte variables to single byte data to 5050 characters and back again.
In order to satisfy the radios need for continuous data, the data must be "packetized", that is grouped into a packet with a preamble, data and checksum. As a result data can not be sent continuously, although there are radio modems available that make this process relatively invisible to the user. The sender must somehow inform the receiver of the length of the packet. The Mailbox packet has the length embedded in the incoming message header.
Let’s start with the simplest setup and work our way up. A one way comm link, as described in my two earlier articles, is the place to begin. One way communication is much simpler than two way. My first article, based on a 68HC11, is pretty much obsolete now. The temperature transmitter article describes a one way link pretty well and, with the latest MailboxPC software and c programs, is up to date.
With this setup, with MailboxPC in slave mode (check "Receive unsolicited writes"), you can transmit data at a periodic interval as dictated by the uC. You need only add the Mailbox RAM and RF transmit routines to your bot program, install an RF transmitter module at the robot and receiver at the PC end. If you keep the transmitter module on all the time the radios are always in sync and this will work very well. If you need to shutdown the transmitter sometimes as you will for 2 way, or for power saving, or something else, your receiver will loss sync. When it does this it tends to go somewhat crazy and forwards a barrage of garbage characters to the PC UART. Mailbox PC is programmed to filter out that noise. I have found, however, that PC UART’s are not the most robust things around. Out of five com ports that I have on two computers only one works in this mode. Before I loaded XP on PC #1 I had three working, but that another story. If you can keep the transmitter on continuously, or if you’re just plain lucky, this setup may work just fine.
However, it didn’t work on machine #1 so I constructed a PC RF interface (effectively an RF modem) that consists of a microcontroller between the radio module and the PC. The uC handles the garbage and passes on only clean, crisp data to the PC. The only difficulty here was that low cost chips, like the ATMEGA8 I used, have only one UART. The PC interface was therefore based on a software UART running at 19200 baud. The inner workings were based on RF routines I had already developed.
You could get a one way system operational with just a slight modification to the RFSlvTst.c program. Set up a call to the mbRead function about once a second, giving it the starting address and number of bytes to transmit. My temperature transmitter board accomplishes the same thing using a slightly different technique.
On to two way comm!
With the addition of an RF transmit module the PC end is decked out for 2 way comm. At the robot end we need to add receive capability. We have a problem similar to the PC port problem at this end. Although your microcontroller UART can reliably handle it, the barrage of garbage creates a lot of interrupt traffic, possibly more than you can handle in a busy robot. At 4800 baud it will create an interrupt every 2 ms. The receive ISR requires about 20 ms to complete its data conversion and database update on completion of a packet(although less than 1 ms before global interrupts are enabled). I therefore added a separate interface similar to the one at the PC end. You could in fact use the same interface that is used at the PC end and talk to the robot uC UART, although I have not tested it in this manner. I instead created an RF module to SPI interface because I prefer SPI, I had the routines already developed and I needed the UART for other things. I installed this new uC, an ATMEGA163 on the front board of the robot and had it do some basic data collection in addition to its RF interface duties. It wrote all the data collected to the Mailbox RAM in the robot uC. Such an interface is also required if you plan to share the port with other devices in a multi-master network.
So here is the complete setup:
You may find that you do not need the RF interface uC at either end. I would design your system with that goal in mind and only add the interfaces if required due to PC port problems and robot uC constraints. The interfaces add complexity and decrease throughput. I will discuss these in more detail later in the article.
What is "Mailbox"?
At its heart Mailbox is a microcontroller networking topology. The idea is that multiple uC’s, and PC’s, can exchange data via various communications methods with a host microcontroller that contains the "Mailbox RAM". I call it multi-port, multi-protocol serial RAM. I envision Mailbox as a simpler alternative to low volume microcontroller data sharing than methods now in use. The topology is multi-master, single slave where each port has a "busy" line that is monitored, and set, by the participants. Each master needs to know nothing more than how to read from and write to the Mailbox RAM. The host slave just serves up the data. I have a test setup with 3 uC’s talking SPI , 2 talking over a UART along with a PC very successfully. I plan to roll this out in the near future. I have UART 8 bit and SPI master and slave drivers that need only to be tweaked slightly before release. I am also updating the header to 3 bytes (allowing 16K address range) for the non-RF interfaces.
On the host microcontroller a Mailbox Array is set up (see file MB.h) as an array of unsigned char. Local access routines for 1,2 and 4 byte variables are included. Remote access slave routines for UART, UART RF and SPI have been developed. All devices connected to the network share the data in the Mailbox RAM. Take a look in the Mailbox host test program (RFSlvTst.c) for examples of local interface with the Mailbox RAM.
In the meantime I have used Mailbox protocol for my RF interface. All of the interface routines are built up in modules so I can combine, for example, an RF slave module with an SPI master module, make a few minor adjustments, and have an RF to SPI interface. The Mailbox PC software operates as a Mailbox master or slave and keeps an updated copy of the Mailbox RAM (at least the portions it’s read).
You really don’t have to use the Mailbox method. Any routines that can send and receive the packets defined below will work. Mailbox allowed me to generalize the routines and avoid writing customized packet construction and deconstruction functions.
Mailbox also has a specific packet structure, very similar to MODBUS. A 2 byte header 8 bit data write packet looks like:
Bit representation: AAAAAAAA LLLLLRRW DDDDDDDD DDDDDDDD DDDDDDDD … XXXXXXXX
In byte representation – ALDDD…X
A - Address bits, arranged MSB to LSB, 0 - 255
L - Length, 0 -31 bytes - number of data bytes written or read
R - Reserved
W - Read / Write Flag: 1 = Read, 0 = Write
D - 8 bit data
X – 8 bit Checksum of all above bytes
Once converted to RF 5050 the packet looks like, in byte representation:
U Ascii U - the sync bytes
c Start bit (5050 for ":")
aA LSB and MSB of 8 bit address converted to Ascii Hex then 5050
lL LSB and MSB of 8 bit length/ R/W converted to Ascii Hex then 5050
dD LSB and MSB of 8 bit data converted to Ascii Hex then 5050
xX LSB and MSB of 8 bit checksum (A through last D) converted to Ascii Hex then 5050
Refer to Help section in MailboxPC for further discussion of packet format.
This packet structure limits the address range to 256 bytes and the packet data length to 31 bytes. The 3 byte header under development will increase the address range to 16000+ and the packet length to 256 bytes.
The Radio Modules
I used the TXM-433 transmitter and SILRX-433 receiver from Radiometrix. These are capable of operation at 4800 baud. I purchased these a couple years ago but there are now lower cost modules and higher speed modules available for the same price that I would consider. Here is the result of some research on sources of low cost RF modules. I have not used any of these and cannot vouch for their performance. Make sure that both transmitter and receiver use a 5 Volt power source. Connections are pretty straight forward on all the modules I have looked at. Follow the manufacturer’s recommendation for the antenna. A short wire, about 4” long, is all I use for my radios. Most modules operate in the 433MHZ region, which may be why they don’t work as well near my 450MHz computer. I get much better performance with the radios located in the next room away from my computers. I have found that they work well all over my house although performance does degrade slightly at the far extremities. My performance yardstick is the Read Timeouts stat on MailboxPC. That tells me how many times data was requested but not successfully returned. The ratio of successful requests usually runs over 90% and sometimes approaches 99%.
I recommend buying at least one spare of each type of device you plan to use to help you through the troubleshooting phase.
The PC End
MailboxPC is the heart of the PC interface. The internal comm engine encodes and buffers all internal read and write requests, decodes and checks out all incoming data and updates its internal database. It can be setup for RF 5050 or straight 8 bit data format. It can operate in master or slave mode. Hook two PC’s together with a crossover cable and test your PC setup. Because it can speak RF 5050 it can talk directly to the robot RF interface for testing. It also has internal loopbacks. It is very useful as a diagnostic tool during the debugging process. This version is a major upgrade to that included with the Temperature Transmitter article in June, 2002. Features have been added and it has been toughened up quite a bit.
The control panel displays all incoming/outgoing data, allows the user to set up read / write requests with defined packets at specific intervals, shows parsed data, comm statistics and more. It also includes a data scroll screen, for a rolling historical display, a database display, an auto packet setup window and a configuration window. It is very usable on its own without any application programs.
In addition to its standalone capability, MailboxPC is an ActiveX server and a DDE source. The RoboControl program shown above was written in C++ and interfaces with MailboxPC, which was written in Visual Basic, using OLE object calls. You can make these calls from Visual Basic, Excel, C++, and many other Windows programs allowing you to utilize your captured data at a higher level. I have included examples of Visual Basic, Excel and C++ programs that access Mailbox PC both as an ActiveX server and a DDE source. You would be wise to get a good language reference manual that discusses ActiveX interfaces and use it along with my samples.
MailboxPC must be installed before the sample programs are installed as they call MailboxPC when they run. The sample programs should be copied into the same directory as MailboxPC. Refer to the program help files for further instructions on how to use MailboxPC.
You will need to construct an RF board for the PC end per this schematic, or, if you’d like, you can move right to the uC based interface described later. Note that Pin 4 of the 9 pin D-Sub is connected, throught the MAX233, to the transmitter Vcc pin. The power to the transmit module must be only allowed on when transmitting, otherwise it interferes with the receiver. MailboxPC controls the DTR signal to accomplish this. You need to ensure your connecting RS-232 cable has all the pins connected – some don’t.
The Microcontroller End
I have become a big fan of the Atmel AVR series microcontroller and use them exclusively at this point. They have models from the Tiny series all the way up to 128K flash versions that all work more or less the same way. The entry price, for a good quality development environment, is less than $100. What I have designed here could be implemented on a wide range of microcontrollers. All you need is a UART, a timeout timer, 2.5K of flash memory and about 128 bytes of RAM and you are good to go. High speed is a nice to have but not essential.
To start off, lets put together a very basic system that has a single ATMEGA8 microcontroller that contains the Mailbox RAM and RF slave routines, plus a simple test program that writes a couple changing variables to the RAM. Connect up your microcontroller as shown in this schematic and load in the RFSlvTst.rom hex code, located in the MBSlaveRF.zip file along with the source files. This is set up for 4800 baud, if you need a slower rate you will have to make the change in mbRFSlv.h and recompile. Once working here, these routines can be added to your robot software.
Fire it Up
Forget the radios at this point and connect your uC UART, through an RS-232 converter chip, to your PC RS-232 port and get MailboxPC up and running. Install a jumper that selects between hard wired and radio on the receive side (it doesn’t matter on the transmit side), set to hard wired for now.
The uC is operating in slave mode, waiting for a command from the PC, the master. Configure Mailbox PC for 4800 baud, Big Endian, 2 byte header, RF Header off, Use RF 5050, Checksum enabled. Start a read request in auto with a ms/scan of 1000 (1 second), parse string of “IICC” and address of 100. Hit the “Start” button at the top, center of the screen to see the transmitted and received data. If all goes well you should see data in the received raw data window and see the variables update in the read column. If this is working, try writing data to an address and then read back the same address. You now have an operational RF link, without the RF.
If this is working you’re ready to test the radios. Install the radio module board at the PC end and move your jumper over to RF on the uC board. Apply power to the PC RF board and the uC and, if all goes well, you see returning data from the micro in MailboxPC.
It Doesn’t Work!
If you arrived at this point with a working system I would be quite surprised. There are just too many things to go wrong. If all’s not well you’ll need to methodically go through the system, find out what is working and narrow down the problem. Take a look at the Timing Diagram for reads and writes, based on having uC interfaces at both ends of the link.
Here's a few things I’ve learned the hard way:
Rule #1 – Transmitting is easy – receiving is the hard part.
Rule #2 – Timing is everything.
Rule #3 – Get it working hardwired first – then add the radios
Start with the PC. Connect it to another PC with an RS-232 crossover cable (sometimes called a Laplink cable – pins 2 and 3 reversed). Run MailboxPC on both PC’s. Make sure your config parameters are as described above and check “Received Unsolicited Reads and Writes” on the PC which will be the slave. Start some read requests on the master and see if they show up on the slave PC. The slave PC will behave exactly like a slave uC. Open up the Database window on the slave and manually enter some data directly.. Try some writes and then read them back and see if they took. If this is not working you have cable problems, configuration problems or you’re still running Windows 3.0. If this works you know your PC is behaving.
Make an RF board for PC#2 just like the one you made for PC#1 and add the radios (or modify your uC board). Try the same thing with radios instead of the crossover cable. If this is not working check the signals at the radio pins with your scope. Are you getting a transmit burst at your master transmitter? Are you getting a power signal on the transmitter? Are you getting data on the slave receiver pin? You should get a stream of garbage characters with the odd coherent string that looks something like UUUU ccA<C<<<<ZN. If not you have radio problems. Try a lower baud rate. Switch modules. Try your spare. Are the jumpers in the right place? If the raw data into MailboxPC works for a while then freezes then you have a com port problem and will need to build a uC interface to the radios as described in the next section. Once you know the radios are working plug them back into the uC board.
One simplification you can try is to call ReadMB directly from the main routine in RFSlavTst about once per second. This bypasses the receive routines and tests your uC transmit side only. On MailboxPC check “Received Unsolicited Reads and Writes” and see if you receive packets. If its still not working then check your receive, transmit and transmit power signals at the radio for activity using the scope.
If no answers here then you likely have timing issues to deal with. This would be most likely at different baud rates than 4800 which is the only rate the system has been tested with. The primary timing settings are found in mbRFSlv.h. Try some larger, then smaller values. If it’s still not working at this point then you may need to get right in to the routines. The RF receive interrupt function SIGNAL(UART_RCV_INT_VECTOR) is where the action starts. I use the comm LED to show progress through the routine. Relocate the RF_LED_ON() statement in each case statement and then down into the ReadMB and WriteToMB functions and see where it stops working. If it all seems to work then try the same trick in the SIGNAL(UART_REG_EMPTY_INT_VECTOR) function which is where the characters are transmitted. If still nothing, then get a good night’s sleep and retry these techniques, or try your own.
It just takes one problem in the chain of events to bring the whole train to a halt. So work from one end to the other, verify all transactions and have patience.
Now that your bots talking to your PC how do you get the most from it? Use the Read and Write request boxes on Control Panel to send and receive data. The Read Parse String is made up of C, I or L's for Character (1 byte), Integer (2 byte) or Long (4 byte) variables. This string sets the length of the packet. The maximum number of variables per request is 12. The returning data is parsed into the data types specified and, of course, it must match the variable types at the other end. You can hit the "D", "H" or "B" buttons to display the data in Decimal, Hex or binary format. Writes can consist of all bytes or all integers only. Specify the number of bytes and the address. The buttons send a one time request, the Auto checkboxes send a request every x ms/scan.
Transmitted and received raw data is displayed in the center windows after the start button is pushed. MailboxPC starts up with this off as it uses a lot of CPU resources (and gives me a headache). It's very valuable for troubleshooting. Autostop stops when a valid packet has been received.
Use the Data Scroll to log every received packet. This works very well for watching variables over time. It logs the time and each parsed variable in the packet. This can be confusing if multiple packets are being used. You can enter headings at the top of each column so you can remember what each column represents. Note that the data is added to the top of the screen, not the bottom.
Use the Database Window for an overview of the incoming data. This is a byte array so multibyte variables will not display correctly. You can manually enter data into the grid that can then be read by remote devices.
The AutoPacket setup table is used primarily when external software is using MailboxPC's ActiveX capability. The Windows application just reads the database periodically to obtain its data. The applications can also use object calls to generate the requests instead of having MailboxPC handle it. I have been using MailboxPC auto reads but generating write requests in the application as they are usually asynchronous.
I use the comm statistics at the bottom of MailboxPC Control Panel for much of my information. The Read Xfr Count tells you how many reads and write requests have been issued from MailboxPC. Read timeouts tell you how many time a valid packet was not returned within the timeout period (about 300 ms). This reading is the best indicator of RF performance. It usually hovers between 90 and 99 % of the total count. The "Reset Counters" button resets this and all other statistic counters. Whenever I make an adjustment, I reset to see how well it's doing. Play around with your packet sizes and frequencies and see what effect it has on this value.
The "Calculated CS" box, shows the current checksum value and turns red if the received calculated checksum does not match whats embedded in the packet. This tends to increase with longer packet sizes, but is usually not a big problem.
If the send buffer starts to fill up it's an indication that you are requesting data at a rate faster than the system can handle, or that communication has stopped altogether. All read or write requests attempt to send immediately, but if a transmission is in progress, the request is put in the buffer and will be retried as soon as the transmission completes. The maximum buffer count indicates, since the last reset, what the maximum buffer size has been. If the buffer is building up then reduce the request rate (increase the ms/scan) or the number of requests.
The DSR box indicates the status of the DSR line. This is active if using the RF uC interface, or if connected to a multi-master network. It will flash red when being told that the line is busy. This is normal and is an indication of how busy the receiving device is. You can configure the DSR Enable to cause MailboxPC to wait for the DSR OK signal before transmitting. You can set the "DSR Wait time", a unitless value that specifies how long the request routine waits before abandoning its attempt and adding the request to the buffer. Values in the 500 to 2000 range will work. Smaller values will likely increase overall throughput, larger values will ensure the latest request gets serviced first. As you increase the number the number of DSR timeouts will decrease, finally to 0. These timeouts are not a data loss - the request has been buffered and will be sent when able. The "Set DTR" checkbox allows you to manually set the DTR line, which MailboxPC does automatically when connected to a multi-master network and when "Enable DTR Handshake ..." is set. The checkbox is just for troubleshooting.
The turnaround time reports the time, in milliseconds, from when a request was received until the read response has been registered. The value has no meaning for writes or unsolicited data.
The "Unsolicited" box turns yellow when a valid unsolicited read or write packet is received. If "Allow unsolicited Reads and Writes" are not checked then this has no effect. If they are checked then the database is updated or a return packet is sent in response to a read request.
There is more information on this in the MailboxPC help files.
RF Interface Modules
I will briefly describe the interface modules in case you decide you need them. The purpose of the module at the PC end is to clean up the data entering the PC RS-232 port because the port was locking up. Here is a schematic of the PCRF board. Construct the board with an ATMEGA8, load the software from MBRFInt_UART.zip, and connect it up. Configure Mailbox PC to 19200 baud, 2 byte header, RF Header on, RF 5050 off. The RF Header setting adds a “UU:” to the front of an 8 bit packet, required by the soft UART. MailboxPC uses the DSR line to sense when the interface is ready for new data so ensure your cable has all signals connected. Test it by hooking the output to PC#2, configured for 4800 baud (or whatever you are using) ,RF Header off, RF 5050 on, check “Received Unsolicited Reads and Writes”. Set the dip switches for the correct baud rate and set the loopbacks off. You should be able to read from and write to PC#2. Use the loopback switches for troubleshooting – when set received data is sent back to the source PC.
The interface board at the uC end serves three purposes. It filters out the barrage of RF noise and reduces it to a simple, fast, SPI call for every valid packet received, reducing the load on the host uC. I also use this chip to handle some miscellaneous data gathering chores, in my case the robot Sonar and I/R distance sensors. You could, in fact, use this chip specifically for that purpose, without any RF interface. It writes all its data to the Mailbox Ram in the host uC which can then read the values directly. The third purpose is if the RF data line is sharing the Mailbox host uC port with other devices. The RF signal would tie up the port for a long time preventing other devices from talking. Converting the signal to a quick SPI transfer eliminates this problem.
Here is the software
for the SPI Interface and the software drivers for the
host uC. I don’t have a schematic
for this interface – the software describes which pins need to be
connected. Install a 220 ohm resistor in
series with each pin to protect against high to low shorts. Connect up a standard ATMEGA8 (or ATMEGA163
if you want more pins) with crystal and add the SPI interface. Start by connecting to the PC via a hard wire
with MailboxPC set for 4800 baud, RF
Header off and RF 5050 on. You should be
able to read from and write to the Mailbox Ram on the host uC. If this is operational, add the radios.
Here is a picture of the ATMEGA163 interface
mounted on my robot.
Here is a picture of the ATMEGA163 interface mounted on my robot.
I will offer flashed ATMEGA8 chips on my website for those who are unfamiliar with AVR’s but could handle the electronics.
As you can see, a two way link is not simple, but it certainly is achievable. I have provided 80% of the solution, you will need to add the other 20%. Once it’s working it’s a lot of fun to play with. Some of the numbers in my robot, were, well, not what I expected. I’ve been going through and stomping out those fires. I can now sit at my PC and monitor my robot as it wanders aimlessly about the house, then get into mapping, moving towards my “Robot come to me” goal.
The other intriguing way of accomplishing this is using wireless Ethernet. This equipment has been dropping in price substantially over the last year. The trick there would be to build a microcontroller to PCMCIA interface. You still have do deal with the data once it gets to your PC of course.
Good luck with your own project and drop me an e-mail with comments, suggestions and questions. email@example.com