I have built a remote control robot that is controlled wirelessly using 2 RouterBoard 133s and 2 Ubiquiti XtremeRange 5 radios. The RouterBoards are configured to bridge the radios and all ethernet ports. I use a hardware MPEG4 video encoder to send video from the robot to the operator's control panel using UDP. I operator's control panel PC uses custom software to send UDP messages to control the robot. The robot side is setup as an AP and the control panel side is setup as Station WDS. I have been experimenting with different settings for the radios and RouterBoards to achieve the most robust connection and have found that 802.11b 1 and 2 Mb modes seem to be the most reliable with this mobile application. I chose to use UDP to avoid having the system hang because the signal may drop out from time to time due to obstacles, multipath, etc.

One issue I have been having is that sometimes when controlling the robot it will stop responding and "buffer" several seconds worth of commands and then start processing them again later. I believe that this issue probably lies in the robot control software or the PC OS but I would like to know if it is possible that the RouterBoard or radios could buffer the data somehow.

Is it true that even if I use UDP that at a lower protocol layer there is an ACK mechanism being used by the radio or router hardware? If so is there a way to disable this?

Any suggestions on how I may be able to configure my wireless system to increase reliability of my connection would be greatly appreciated.

Thanks
Chris

One issue I have been having is that sometimes when controlling the robot it will stop responding and "buffer" several seconds worth of commands and then start processing them again later. I believe that this issue probably lies in the robot control software or the PC OS but I would like to know if it is possible that the RouterBoard or radios could buffer the data somehow.

Is it true that even if I use UDP that at a lower protocol layer there is an ACK mechanism being used by the radio or router hardware? If so is there a way to disable this?

Any suggestions on how I may be able to configure my wireless system to increase reliability of my connection would be greatly appreciated.

This is certainly a wireless "problem". (It's not a problem for typical implementations of of 802.11b). The protocol is designed to keep resending packets (UDP, ICMP, TCP, whatever) until it gets back an ACK or times out.

If you look in WinBox in the Interface properties for the wlan1 interface, you'll find the relevant settings under the Advanced tab. There is a 'Hardware Retries' and 'On Fail Retry Time' setting. You should set the hardware retries to 1 (you could try 0, but sometimes 0=unlimited).

How can you be using the XR5 with 802.11b? It's a 802.11a card! Did you mean XR2?
For maximum reliability, use a 5 MHz channel (default is 20 MHz) and 1 Mbps.
If you want to go even further, switch to 900 Mhz.

Chris, please post a list (including model numbers) of the major components in your device.
I'm especially interested to know what camera, MPEG4 encoder, and controller you are using on the robot (I have my own similar project).

I believe that the router is allowing me to select 802.11b modes on that card because it still sees it as a 2.4GHz radio. I think that this is because the OS on the router does not fully support the XR5 card and just sees it as an XR2.

Thanks for the suggestions, I will try changing the hardware retries and bandwidth settings this week.

I am using a laptop PC on the controller side and a VIA M series 600MHz motherboard with an embedded processor on the robot side. Power to the MB is supplied with a mini-box.com PW200 DC-DC converter which is fed by another DC-DC converter that supplies 12V from the main 24V source that powers the main motor and pneumatic solenoids. I am using a Labjack U12 and a Pontech SV203 on the robot for motor, servo control and sensor input. The main drive motor was stripped from an old mobility scooter and is voltage (0-5V) controlled with the Labjack. This effectively simulates the potentiometer input that the scooter had. The video encoder is a 4XEM IPVS1E network video server. Latency could be better on this unit but is still < 300ms. I have been using a web browser for monitoring the video feed but just got their ActiveX control sample to embed in my VB app. Hopefully that will improve the video performance.

I would love to know more about your project!

The problem with using UDP over 802.11 to control a robot is that a two way link has to be established for the robot to do anything.
Ideally, it should be possible to control the robot even when the robot can hear you but you can't hear it (like a regular RC car).

There has to be a way to send packets without having a two-way connection. The most obvious method is by dynamically changing the SSID.
An even better (but more difficult) approach would be to do some low level programming.
You can extend the range of the device if you design a control system that functions when only 10% of packets makes it.

Here is what I'm working on: http://forum.mikrotik.com/viewtopic.php?f=7&t=21222

rk @ rontec.net

There has to be a way to send packets without having a two-way connection.

How about Multicast?

Does using multicast prevent the use of ACK responses at lower (physical and link) layer protocols? Is there any special configuration required to use multicast other than changing the destination IP address?

Thanks

To be honest, I really don't know much about it but I've heard other's on the forums mention it and it sounded like it might fit in here.