Help with linking OI and RC over Internet....

[P1d40n3]

My team is trying out an interesting project; namely, we are making a robotic hall monitor that can be controlled over the Internet. But we've hit a roadblock of sorts.

We have 2 GW21W's (http://www.atop.com.tw/e/product/GW21W.htm), one connected to the Tether port on the OI, and one to the Tether port on the RC. I know that the two are connected (their status pages say they're connected to each other), but for some reason, there is no data passing between them. What I'm thinking the problem is that the serial port on the RC GW21W is improperly configured for outputting to the RC.

So what I need to know is this (If indeed my theory is right);

The flow control scheme that the RC uses, and the bit parity. Also, if you have any ideas (pitfalls to look out for, questions, etc.) feel free to post them.

A thousand thanks to all those help us :cool: .

-commander Adam 'P1' Burch

[Tom Bottiglieri]

http://www.ifirobotics.com/radio_modem.shtml
9600bps Full Duplex. Not sure if that helps. For the bit parity, I would say just brute force it and try all of the available options.

I hope you're going to have some kind of local object detection system on the robot, or at least some kind of emergency shut-off in case of packet drop. The last thing you want is a router to shut off and your robot to slam into a person in the hall.

[Greg Marra]

We have 2 GW21W's (http://www.atop.com.tw/e/product/GW21W.htm), one connected to the Tether port on the OI, and one to the Tether port on the RC. I know that the two are connected (their status pages say they're connected to each other), but for some reason, there is no data passing between them. What I'm thinking the problem is that the serial port on the RC GW21W is improperly configured for outputting to the RC.

I'm not particularly familiar with the communication schemes used by the RC, but have you gotten these boxes working with other serial devices? You've probably already tried this, but if the problem lies in the GW21W instead of the RC, you could be banging your head against the wall. Try putting another serial device through them and see if that works.

[EHaskins]

If I remember right radio and possibly the tether ports are rs422 not rs232.

[Dave Flowerday]

We have 2 GW21W's (http://www.atop.com.tw/e/product/GW21W.htm), one connected to the Tether port on the OI, and one to the Tether port on the RC.
Ouch, you better be careful with this or you'll damage things. The tether port is NOT a standard serial port. Yes, it does use RS-232 to communicate with the RC (the radio modems use RS-422), but it also carries power and ground (think about how the OI powers up when you tether it). In addition, the OI and RC only switch over to using the tether when they detect that it is connected by monitoring the connections on the pins.

Bottom line is that you'd have to build an adapter for each side to make the right connections. And if you screw up there's a good chance you could fry a $500 controller.

9600bps Full DuplexThat's the throughput of the radios. They actually communicate with the OI and RC at 19200. As do the tether and dashboard ports.

The settings are 19200, no parity, 8 bits, and 1 stop bit, with no hardware or software flow control. But again, this really isn't a good thing to be experimenting with unless you know exactly what you're doing.

some kind of emergency shut-off in case of packet dropThat's already built into the RC firmware. However, driving a robot which is not in direct view of the OI sounds really dangerous to me. If you're driving it out of range of the standard radio modems then it's probably too far away to be safe.

[divergentdave]

You may want to investigate the tether specs further, because I think that the OI might be trying to draw power from the robot through it. If your serial connectors don't supply voltage through the right pin, it might turn on some failsafe feature on the OI.

[Kevin Sevcik]

To further add to the confusion, it's possible that the tether uses characters that could confuse your adapter. It looks like COM1 will switch to a console if you send 'Z' or 'z' 3 times in a row. So I'd be safe and use COM2.

[Tristan Lall]

That serial box is available with RS-422, according to the specifications (well, one place says -422, but there are no subsequent mentions of it). You might want to ask whoever sold it to you to exchange it for the RS-422 model, to connect via the radio ports instead. With luck, the hardware would treat it identically to the E-Wave modems that we use now.

[Kevin Sevcik]

Think again, Tristan.

IFI Radio to Wifi FAQ (http://www.ifirobotics.com/forum/viewtopic.php?t=405&sid=0c8532faaae1e90745d24b3a4896c15e)

Modems have tons of commands that tell the modem how to connect to the other modem, etc. The RC isn't expecting to see an OI at the end of the radio port. When its setup commands aren't replied to, it just won't work. If this did work, you could just hookup the RC to OI with an RS-422 crossover cable and get much better max distance than with the tether thanks to the differential signalling.

[Tom Bottiglieri]

That's already built into the RC firmware. However, driving a robot which is not in direct view of the OI sounds really dangerous to me. If you're driving it out of range of the standard radio modems then it's probably too far away to be safe.
Yes, but the connection from the host computer to the robot would not be broken. The connection from the client to host computer over the internet would. The robot would still think the OI is present, even if it was giving garbage data. It may not be very probable, but this system is just an injury waiting to happen.

This all goes to prove a very good point. If there's people or valuables around, and you cant see the robot, don't drive it!

[Astronouth7303]

You may want to investigate the tether specs further, because I think that the OI might be trying to draw power from the robot through it. If your serial connectors don't supply voltage through the right pin, it might turn on some failsafe feature on the OI.

The OI only draws power from the RC if it isn't plugged into the wall. (Personal experience: Plugging-in OI can solve "chasing LEDs" problem.)

[P1d40n3]

Thanks for help all!

Just so we're clear, the team and P1 also plan to attach a wireless webcam to the robot, so as to get a live feed from the robot. The goal is to set it up as a hall monitor you cna use from anywhere in the world. As long as you have the right password. :)

[cdfps]

I read the posts and I don't fully understand what you are doing. I get the perception that you want a computer somewhere in the building and the robots f in the hall.

The last time I did this, I put a laptop on the robot, used a free timelife giveaway usb camera, a power wheels 6 wheeler, a car battery ,ran Libranet with apache, and wrote CGI in c to control the 225in/oz steppers I was using to move it.

The stepper driver kept the motors constantly hot so battery life was low.

The forward, backward, etc, etc scripts were called when a button on the web page was clicked.

The robot was a simple build and worked easily from inside the school, getting through the school firewall waws a lot harder.

I probbably have the c cgi source as well as the web pages used, and maybe some documentation. If you want I can take a look and send it along to you.

For a while I had a telerobotic tethered turtle in my office which anyone in school could access. Turns out there are two kinds of people. The kind that spin the telerobotic turtle around 5000 times to wrap up it's teather and the kind that would drive it into you.

[Hieb]

Just so we're clear, the team and P1 also plan to attach a wireless webcam to the robot, so as to get a live feed from the robot. The goal is to set it up as a hall monitor you cna use from anywhere in the world. As long as you have the right password. :)

A possible option to consider -- mount the OI on the robot, directly tethered, so it is receiving the information it wants. Then look for a Wi-Fi adapter to connect to the serial port of the RC. I recall seeing one when I was considering a similar project, but I don't remember where. That way you have your video feed and control all through the network. As mentioned before, definitely include a failsafe so a dropped packet will disable the robot.

[Matt Krass]

Also don't forget the IFI communications system tries to maintain a sync at about 38Hz, latency induced by the internet transmit may cause timing issues and force an RC shutdown due to "unstable communications". The radio port is designed to control E-wave modems and I don't believe it'd work connected straight to this device, and as others pointed out the tether is sensed by the direct connections of certain pins which the adapter probably doesn't emulate (Why would it? it's non-spec).

I think pairing up the OI/RC works, as long as you have a remote kill switch. Talking to the RC via serial port with those adapters is likely to work much better.

[P1d40n3]

I probbably have the c cgi source as well as the web pages used, and maybe some documentation. If you want I can take a look and send it along to you.


That would be very nice. But how did the laptop connect to the RC? Or was the laptop acting as the RC?

The original plan was to have the Operator Interface connected to the first GW21W, and have that GW connect to the other GW via the schools WiFi. This last GW would then send the OI data to the RC. But appentally, the OI and RC use non-spec communications...

I think pairing up the OI/RC works, as long as you have a remote kill switch. Talking to the RC via serial port with those adapters is likely to work much better.

When you say the serial port, do you mean the Program port, or the TTL pin-thingies?

[Dave Flowerday]

Yes, but the connection from the host computer to the robot would not be broken. The connection from the client to host computer over the internet would. The robot would still think the OI is present, even if it was giving garbage data. It may not be very probable, but this system is just an injury waiting to happen.
This isn't the way it works. The RC goes into disabled mode if it doesn't receive a valid packet within some (short) timeframe. Garbage data will not keep the connection alive. There's a checksum on each packet that must pass, as well as receiving the correct team number and probably a few other things. These checks are all still in place even when using the tether. Well, technically I guess the team number check is removed since it will just program whatever team number it finds, but the checksum must still pass.

{edit}OK, I realize that this setup isn't quite what I was thinking. I thought you were just trying to remotely locate the OI but still use the OI for controls. How would someone remotely over the Internet actually control the robot? Are you thinking of interfacing a computer to the OI to do it?

I think the suggestion of going straight to the program port is the best. And, I don't think you even need to put the OI on the robot - if you set it to team number 0 it will run in autonomous mode without the OI (I believe). Then, just put all your code to read in commands from the serial port in the autonomous loop.

This would be an interesting experiment to try in a safe environment, but again I don't think you should use this in the halls. Even with a webcam on there, think of the problems: if the webcam stream stops, whoever is driving remotely may not realize what the robot is actually doing. Additionally, webcam streaming over the Internet usually involves several seconds of buffering. This means that what you see on the screen will be several seconds old, so by the time you see someone in the way of the robot and move to avoid them it may already be too late and you've already hit them. I can't imagine the school would ever allow you to do this anyway due to the liability. Are you going to have eveyone in school wear safety glasses? ;) {/edit}

[EHaskins]

The OI sends data through the dashboard port even when its not connected to the robot. You could set the OI to output the OI values, and connect your WiFi serial things to the dashboard of the OI and the program port of the RC. You would get all the joystick and switch information through this connection. You could also write software to drive the robot from a computer.

You would still need to write the software to interpret the dashboard data, but that is well documented, and would be relatively easy.

I did not check to see if the 2006 OI will output the values, but while I was typing this I tested a 2005 OI and it worked the way I expected.

The dashboard specs are in the install folder of IFI Dahsboard or aviable from IFI's website.

Hope this helps

[Hieb]

When you say the serial port, do you mean the Program port, or the TTL pin-thingies?

I was refering to the 4 pin connection that the camera uses. I'm sorry I can't provide you with more detail, but when I first considered this a couple months ago it was because I stumbled across an adapter or wifi web device that I thought would work for just this application. Unfortunately I've been spending more time trying to raise money so we can compete this year and not enough playing with robots.

[Matt Krass]

That would be very nice. But how did the laptop connect to the RC? Or was the laptop acting as the RC?

The original plan was to have the Operator Interface connected to the first GW21W, and have that GW connect to the other GW via the schools WiFi. This last GW would then send the OI data to the RC. But appentally, the OI and RC use non-spec communications...



When you say the serial port, do you mean the Program port, or the TTL pin-thingies?

You could use either, but I was referring to the program port.

[Astronouth7303]

The OI sends data through the dashboard port even when its not connected to the robot. You could set the OI to output the OI values, and connect your WiFi serial things to the dashboard of the OI and the program port of the RC. You would get all the joystick and switch information through this connection. You could also write software to drive the robot from a computer.

You would still need to write the software to interpret the dashboard data, but that is well documented, and would be relatively easy.

Note that the OI requires some kind of connection before sending data, even if it's just a radio w/o a robot. I think of the dashboard as the raw data sent or recieved; if the OI isn't trying to send data, you won't get it on the dashboard.

What this means is that an OI without a tether or a radio won't send data. (At least the 2005 won't.)

[EHaskins]

I tested it and got good values from an OI with a radio, but no robot near by. I have not tried it without a radio, but what I said above will work as long as you have a radio connected to the OI.

[P1d40n3]

You could use either, but I was referring to the program port.

Forgive my ignorance, but how on earth would you do that? Does the code even have alias' for the program port?

[Matt Krass]

If memory serves (and it may not, it's been a while since I touched one of these) the standard C functions printf() and scanf() are tied to that port, allowing scanf() to receive data from it and printf() to output. The only problem I can see with that is scanf() may be blocking and thus might break the timing of the code. Kevins Bells and Whistles 2006 camera code used the serial port for receiving single byte commands to control the camera, maybe look in to how he did it? I think it involved accessing the serial received buffer and plucking the data right out of there, which is how I typically use serial ports on 8-bit micros.

If this reply made no sense to you, sorry, I'm just getting up (Colleges are full of strange germs that tend to crush freshman). If you'd like to talk more one on one I can try to elaborate on it for you.

[EHaskins]

You should download Kevin's serial port code(this is what he used for the camera) from www.kevin.org/frc (http://www.kevin.org/frc). If you search CD you can find alot of help for this serial port driver. To use the code you follow the instructions in the readme to add the code to you r project, and configure the speed and other setting for each port.

Most of what you would use in your code is explained in the readme or in this thread (http://www.chiefdelphi.com/forums/showthread.php?t=31931) http://www.chiefdelphi.com/forums/showthread.php?t=31931.

If you have any questions PM or e-mail me haskinseric@hotmail.com. :)

[seanwitte]

This is not an ideal solution, but you could get something working fairly quickly using this dashboard framework: http://www.chiefdelphi.com/media/papers/1765

That application includes a UDP packet relay that will forward the incoming data packets from the serial port to another instance of the dashboard running on a separate PC. It allows you to share the data stream over a network. You would have to write a dashboard view control for the laptop on the robot to forward the command to the RC, but since you can define the protocol you can keep it simple.

The system would involve two PCs, the OI, RC, and a wireless network:
1) Laptop1 connected to the OI running the dashboard app configured to forward packets to laptop2.

2) Laptop2 connected to the RC via the programming port running the dashboard app with your custom view to package and send commands to the RC. Laptop2 is set up as UDP listener.

3) Custom code running on the RC to listen for commands on the serial port and update the motor outputs. Robot needs a robust set of collision sensors to disable the robot when it hits something. Also requires a watchdog timer to disable motors if data is not received within a threshold time limit.

4) MSN Messenger running on both laptops with an active videoconference open.

[EHaskins]

Why would you have a computer on the robot? The dashboard data is not that complicated. If you had the dashboard data being feed through the wifi serial ports, and a WiFi camera on the robot you wouldn't have a problem. There is no reason to risk your laptop on a robot.

[seanwitte]

Why would you have a computer on the robot? The dashboard data is not that complicated. If you had the dashboard data being feed through the wifi serial ports, and a WiFi camera on the robot you wouldn't have a problem. There is no reason to risk your laptop on a robot.

I guess I should have qualified the comments. If you do NOT have $400 worth of wifi serial adapters, but do have an old laptop, if would be fairly straight-forward to prototype something similar. For the price of one wifi webcam you could get two USB webcams, one for the robot and one for the operator. If you use MSN Messenger and open a videoconference to the robot you get bidirectional video and audio, useful for telling people to get back to class. Plus, if they can see you they might be more willing to cooperate.

[seanwitte]

Several years ago I wrote a VB application to control the robovation (mini RC) controller from a PC using a serial cable on the program port. I don't know if the latency of the wifi adapters would affect it, but you can give it a shot. The code should port to the full size robot controller, but if you have a mini-rc you can use it without making any modifications. When you run setup it will add help.txt to the installation folder with basic information about how to get it working. The joysticks don't automatically re-center when you release them, but right-clicking will do it.

http://members.cox.net/seanwitte