I’m writing a program that controls the robot from a netbook, however the trouble i’m having now is that i’m trying to make it user friendly, i want someone to be able to open up the program and it will automatically recognize which port the robot is connected to, and if no robot is connected, i want it to keep looking for one until it is connected. I did notice that the IFI loader has the ability to check and see if the selected port has a robot connected to it, i’m thinking of using something like that to check every port thats open to see where the robot is.
the Problem is that i cannot figure out how the Controller Verification works. is this documented anywhere? has anyone ever verified the controller with there own code before? it looks like it works no matter what user code is on the robot so i would assume that its a firmware thing.
The Serial Port (used for programming) on the Vex V0.5 Controller has TX and RX plus Clear to Send (CTS) and Ready to Send (RTS). (see Post #5 of Re: RX1, RX2, Serial Port) So the IFI Loader might be using a Hardware Method to locate the Vex Controller
The Vex Cortex Controller might support the RTS and CTS (or equivalent) as well. (I don’t have my Cortex Controller, yet…)
Or both Controllers might be identified in Software…
There is no documentation that I know of…
Is there any way you could write your own handshake routines???
Assuming that you have Bi-Directional communication between the Vex Controller and the Computer, you setup the Vex Controller to listen for a Command Sequence, like “hello!!”, and respond with “i’m here”.
Your Netbook Code would hopefully Enumerate the COM Ports, then try to open them one at a time, and if the open succeeds, then send the greeting “hello!!”, and listen for the response “i’m here”. If you only want one to communicate with One Vex Controller, then you have the correct COM Port. Otherwise, note that COM Port, and continue down the Enumerated Com Ports, Opening, Sending the greeting, if Successful, and Listening for the response.
Thank you very much, i’m glad you like the idea. If i can’t use the built in hand shaking routine then i probably will write my own (I am using .net framework for most of the code). right now i have only sent the robot data and had the robot read and respond to the data by sending moving the wheels. however i guess it was onlly a matter of time before i would have to have the robot send data back to the netbook.
would there by any chance be any good port monitoring program that i can use to monitor what the IFI loader sends and receives? if i could do that then maybe i could just see what the IFI loader sends to the robot when you hit the Varify button and then monitor what the robot sends back. then i wouldn’t have to deal with writing the hand shaking routine if it is built into the firmware
I am actually using the first Microcontroller vex ever made, the PIC microcontroller. i got a good deal on it and all communication between the netbook and the controller is conveyed through the USB to RS232 adapter (hardest challange was fitting the entire converter cable onto the robot :)).
by the way, if you want to know more about the project, I am working on a Telepresence robot that you can control from anywhere in the world through Skype (the name of the robot is the SkypeBot). I am looking for people to test it out so if you want to try it out, I can send you the latest client i’ve written to control the robot.
The farthest the robot has ever been controlled from is london. the vex robot was in florida while the person driving the robot was in london. that might be the world record for the farthest a vex robot has ever been controlled from
I would start with RealTerm, and Monitor the CTS and RTS lines. IIRC, the CTS is an Output, like the TX and RTS is an Input. I will find the diagram I made of my special RS-232 Cable, and add the RTS and lines CTS to it.
Great!!! The Original Vex Controller I have a few of…
I wrote all of the code myself using MPLab And examining many of your code samples. Setup was a nightmare but i eventually made a standard template that compiles consistently on my computer. The code is REALLY simple. all it is right now is f for forward b for backward l for left and r for right (sending these commands over serial). in order to keep the robot moving, the netbook must keep sending it commands. if the netbook jams up or the client jams up, the robot stops receiving commands and slows to a halt. to take care of lag and occasional data loss between client and server, the robot will go full speed when it receives a command and then subtract from its speed every one millisecond. this means that the speed is pretty much controlled by the speed of the skype connection. that way, you will always have time to react, even if what you see is a bit behind times.
I’ve sent you the Client program, have fun driving it
And thanks for the link to that forum thread. i’ll have to look into that more