Here is a Troy 500 Wireless serial port server. It connects wirelessly via Wifi to the local LAN and provides an RS-232 serial port to allow the robot to talk to my PC. An RS-232-to-TTL converter is used to interface between the RS-232 port and the robot controller.
Since the port operates over a LAN, it is possible to control the robot remotely over the internet.
I got this on eBay for $50. The current version is made by Silex and is called an SX-500.
While it does work beautifully for communication, it does not allow the robot to be programmed wirelessly. (Hey, Vexlabs, you guys need to work on your programming code to allow it to work with things like this.)
The connectors used to wire everything up are covered in this thread. You have to supply 5v to the RS-232-to-TTL converter and also to the Serial Port Server. I connect to the secondary serial port on the top of the robot controller, but a suitable cable could easily be made to connect to the primary serial port on the end of the controller.
So what else can you do with this?
Like in the direct control menu thingy you can control the robot using the computer as the remote control?
Also, what part is the part that plugs into the compy? or by over the internet u mean it goes through your wireless interface card?
And if this is the case, wouldnt it interfere with any wireless signals coming into your compy?
There is software in the PC that creates a virtual serial port. Whatever software is running on the PC communicates as if the comm port were on the back of the PC. The virtual serial port software sends the communications over the LAN to a wireless access point, or to the wireless card in your PC.
For example, I have a wireless DSL router at my house that provides internet access and file sharing to several computers in my house. Each of these computers has its own IP address on the network. The serial server also has an IP address on the network. There is software on my PC, downloaded from silexamerica.com, that creates a virtual serial port, in my case, Comm4. To any software on the computer, Comm4 looks like a standard serial port, but the software redirects the communication to the IP address of the serial server. I can load up the Vex DDT software on my PC, set it to talk on Comm4, and control the robot wirelessly over the wireless LAN in my house. If I chose to, I could open up a pinhole in the DSL Router and control the robot from another location via the internet. Add a wireless IP internet camera so you can see what you are doing, and you could easily run your robot from anywhere in the world. I don’t use the DDT software, but rather custom software written in Visual Basic. But the idea is the same.
Oh, so what you are saying is that the wireless thing is acting as a computer in itself, and is is sending the information back and forth as if file sharing between the wireless serial port and your computer?:rolleyes:
So does the wireless serial also has its own MAC Address and IP?
And one more question:
with that, noting actuall connects to the computer, so any computer on the LAN can use this as a virtual serial port?
I suspect that the processor inside the serial server is a more powerful computer than the robot controller.
Yes, the information is sent back and forth between the wireless serial port and the computer. The serial server has a MAC address and an IP address. Any computer on the LAN that is running the virtual serial port software can talk to the wireless serial port. I presume there are safeguards to keep more than one computer from talking at once.
Couldn’t you use the programming kit connector and take off the USB converter part then connect the serial part to the server and the other end to the micro-controller? So that way you could use it to program the MC. It seems like that would be possible.
That was the first thing I tried. Unfortunately, it didn’t work.
I suspect that there are some time lags introduced by the radio link that cause the loader software to time out. Rather than sending each character as it is received, the radio saves up characters until either its buffer is full, or a certain amount of time has passed after the last character received, then the entire buffer of characters is sent as one packet. My guess is that the IFI loader is expecting a quick response from the programmer or the robot controller, and that the delays caused by the buffering process are too long.
What you describe could certainly be a problem, but there are probably more incompatibilities that would have to be overcome. For more info use Search to find the “building a substitute for the programming cable” threads here and at the Chief Delphi site.
I think it’s the com port shim that’s abstracting the reverse telnet connection that might be slowing things down.
These things support raw TCP/IP connections to the serial ports via ports 3100, 9100, and 9200 (RFC2217 connections). You should be able to telnet to these ports directly and see how quickly the data comes back.
This assumes, of course, that you have a good idea of what codes should be flowing back and forth on the connection.
What would be interesting is a shim that doesn’t buffer the characters coming back then push them up the stack, but rather pushes them up as they come in.
Thanks for your work on this.
Now that you’ve gotten into the Computer to controller link, can you see the robot controller’s output ?
(what the sensors are reporting through the digital ports ?).
We’re trying for a dashboard tool (running on a PC) so we can observe the robot controller’s internal activity during autonomous running.
I had code developed that would allow the robot to scan the surrounding area and present a map of the surroundings on the PC. I could then click on a position on the map and the robot would orient itself using a magnetic compass and drive to that position, using the wheel encoders to measure the distance. All the while, it would report back its position,orientation, and other live variables to the PC console.
The communication routines were interrupt driven and worked in the background. The PC console software was written in Visual Basic.
Then I had a hard drive failure and lost everything. Months of software down the drain. I’ve been so disgusted, I haven’t touched the robot for over a month.
Moral: It’s not “if” your hard drive will fail, its “when”. Back up often!
It’s sad how often I have preached that to people and then didn’t follow my own advice.
Another solution is to use two XBEE Pro Wireless UARTS as I have done for my Vex Animation Controller. These modules allow you to communicate with the Vex Controller on your robot using 115200 Baud, 8 data bits and 1 stop bit so that you can issue the controller digital commands or DDT command messages. You can see the Vex Animation Controller system that I am currently developing using SchmartBoards.
The Vex Animation Controller even has the capability to train a robot (like a teaching pendant) and record and playback motion scripts. This is similar to a tape recorder play/record and the Animatronics displays used in Disneyland and Epcot Center.