If you are using a cheap wireless card based on the RTL8185 chipset, but are having horrible signal strength, you need to use the custom realtek drivers from realtek's website. The standard linux driver is the rtl8180 module. The RealTek driver is named r8185b, and it doesn't work 1n the 64 bit kernel.

The RealTek download page is: http://www.realtek.com.tw/downloads/

The 64bit build has these errors:

make[1]: Entering directory `/usr/src/linux-headers-2.6.32-28-generic'
CC [M] /home/markw/drivers/old/rtl8185/r8180_core.o

A company, Vgo or "Vgo Communications, Inc." develops a robot that is basically a mobile robotic teleconferencing system. Is seems to be little more than a sleek looking, remote controlled "robot" that is tied into a video conferencing software architecture. It is a pretty cool, albeit, obvious design.

The Linux P.C. robot does this, more or less, out of the "box" with a 3rd party H323 system. When I give my presentation at IEEE in New Hampshire, maybe I can demo this sort of operation.

I did a presentation at MIT on January 19, 2011 for BLU (Boston Linux Unix user Group). I'll make my presentation available on this sit after I do some edits.

I could not get the network setup for the robot. My underlying assumption that if I brought my own wireless access point and managed my own network that it would "just work" proved incorrect. I could not get reliable connectivity.(It may have had to do with MIT's internal wireless network.)

For some time now the robot has been a "velocity" based motor control system. I have been working enable vector based motion, i.e. move forward x centimeters at a specific speed. All was going well until I found that the mouse based wheel encoder system could not keep up with the maximum speed of the motors. Thus making the robot run away.

This is the crux of the challenges of this type of system, obviously the problems are solvable,it will just take a little more effort than originally expected.

I have upgraded the MTask system in Phoenix and robot code to enable multi-threaded task management. I also changed some of the settings to reflect new wheel sizes. (64cm - they were 104cm previously)

I am in the process of retuning the motors. The multi-threaded version behaves differently! I need to research what the effective differences are and either fix them or, if they are functionally "correct," document why they are different.

As some of you may know, the robot has had a single process "task" based pseudo-realtime system. I did it this way thinking that one real time process managing the various systems of the robot would perform better and be more predictable. It was an experiment that I'm not sure I accept as a success. I think simply spinning off threads or processes for each of the various systems will be less problematic and may even perform better.