Running A Robotics Contest with XBEE..Please help!

[Kevin Pace]

I have been running a robotics competition for the last 4 years and we have been using the PROP with the XBEE PRO 802.15.4 Modules. In the past few years the contest has not had a large number of bots....Maybe 60 or so. This year we expect about 200 Robots in attendance. Although we have a system that is working...Its far from perfect and Im looking for some advice from some of you that have a lot more experience than I do with the XBEE modules and the PROP. I have talked with the tech support at Digi for quite some time and have continued to improve communication with the XBEES but I'm not sure we have exhausted all avenues.

The biggest issue we have right now is erratic behavior. One person will be driving their robot and it will start doing bizarre things and the driver loses contro of the robot. This happens frequently and is concerning for those who are driving!

Here are the settings we have programmed the XBEE modules with:

* We are spreading the Channels out. We are using all 12 channels and putting a standard number of robots on a single channel. Around 16 Robots on a single channel.
* We are using a 4 digit PAN ID for each PAIR of xbees. (We have an xbee as a transmitter and one as a receiver coupled on both sides with a Propeller.)
* There are at least two digits that are different in each PAN ID. An example would be one pair with # 2015 and another pair with # 2026
* We are using a PS2 Controller for robot control.
* The DL and MY values for each pair are opposite numbers . On a transmitter we might have a DL of 5968 and a MY of 5967 They would be reversed on the Receiver.
* On the level 1 robots we are using a POWER LEVEL of "0" because they only have to transmit across an 8 foot span.
* On the level 2 robots we have a power level of 4 because they have to operate about 40 feet away.
* We are running at a baud rate of 9600 (This matches the baud rate of the PS2 Controller)


Accordng to DIGI these are the main settings that we can control. We are using the XCTU program to program the software and I have made the latest FIRMWARE updates on each module pair. (Currently 10ED)


Are there any advantages to running the xbees in another configuration mode?

Since we have a PROPELLER on the transmit and receive side would it be possible to write some PROP CODE that could determine whether data is coming from the correct xbee and tell a servo or DC motor etc to GO or STOP based upon that directive?


I have attached the code we are currently using on the TRANSMITTER and RECEIVER. Along with the objects we are also using.

We have a great deal invested in the XBEE and PROPELLER and we feel confident we can work out these bugs with help from those of you much smarter than I am!

Thanks for any support you can give.




(I only ask this because DIGI has told me that I have ALL the settings correct and that we shouldnt be getting wild behavior)

[W9GFO]

It would be great to see some pictures of the competition.

I would think that a faster transmission rate would help. I run mine at 115K in an effort to reduce to a minimum any lag. It should not make any difference what the speed of the PS2 controller is since it communicates directly with the Propeller.

[Kevin Pace]

We tried running the PS2 and the xbee at different baud rates but could not get data to transfer. We used the PST program to monitor the data and had no luck. I have often thought that the rate could be a factor.

[Phil Pilgrim (PhiPi)]

One thing to note about XBees and baud rate: the baud rate you program into the XBee is the rate used to communicate with the attached external device. It is not the RF baud rate. That rate is fixed and dependent only upon which XBee family you are using. For example, for the XBEE PRO 802.15.4 Modules, it's 250 kbaud. Because the programmed baud rate affects communication with the connected device only, you can use different baud rates at different ends of the RF link to communicate with your attached devices.

-Phil

[stamptrol]

Wow! That's a lot of RF activity in a small space!

From my own use of the XBees, it sounds like you're doing everything according to the instructions. I would suspect you are seeing some anomalies just due to the amount of RF happening on relatively close frequencies. And, just like trying to herd cats, you may also have a few "rogue" operators firing up their systems with their own ideas of what the radio parameters should be.

From a security-of-operation point of view, you would normally not depend solely on the radios for the security of the data getting to the right place. The data itself should be able to tell the receiving end processor that it is meant for that receiver. That can be a simple inclusion of an identifier character the transmitter adds to the data string and the receiver checks for.

Similarly, a simple check-sum added to the data stream can help check for garbled data strings and shut the system down if data comms are lost or not making sense. With Props available, you can add those features easily with no additional negative effect on operation.

Due to other constraints, my current system is not on Parallax equipment, but is BASIC and I can provide details if you PM me.

Cheers,

[Kevin Pace]

I'm glad someone else is seeing this issue the way I am. Thanks so much for your input. I'm going to spend some time looking at code. We did try a test the other day which used a single character as an identifier and it did allow us to get down to about 90 different characters. So about 2 robots using the same character as an identifier. I'm not quite sure how to get beyond that at this point. Programming is not my strength but I can usually work through it slowly.

[Mike Green]

The xBee devices already do their own error detection and correction and they identify each message with the sender and receiver IDs (and only respond to packets addressed to them). It's redundant to add additional checksums and identification to the messages. Your main problem (which you're addressing) is making sure that the participants obey the rules about channels, PAN ID and DL / MY code assignments. In an environment with a lot of xBee packet traffic, you will see a slow down in throughput as the xBees interfere with each other and have to repeat their transmissions (automatically) to get through without error.

[Kevin Pace]

What i'm finding is that as the xbees retry to connect, there is generally a very short delay. This hasn't created a lot of issues at this point. However, what I am seeing is that after the robots are running for a few minutes we will start to see erratic action in the servos that the robot is utilizing. I believe what is actually happening is that there is a loss of connection in the ANALOG control that links the PS2 analog button on the controller. When the communication link is temporarily broken, the servos dont have any code that is controlling their action so they just take off and run. This creates quite an issue as you can imagine. I'm looking for a way through programming to keep the motors under control when this loss of analog link occurs. I'm not a great programmer with the PROP but Im sure someone who knows code well, could help me work through this hiccup.

[Mike Green]

Your explanation doesn't make sense. The transmitter sends a block of information to the receiver and the receiver doesn't act on it until the whole block is received. As such, if some of the data is delayed, the program will just wait. The servos are driven by a separate cog which continues to control them based on the information in the "servos" array which doesn't change until after the received data is processed. On the transmit side, if the xBee link slows down because of interference, the PS/2 controller just gets sampled less frequently. There's no "out of control" except that rapid changes to the PS/2 controller settings (joysticks, buttons, etc.) might be missed. The person working the controller just has to slow down their movements to match the response of the robot. It's difficult to make any suggestions given the limited information you've provided on how the PS/2 controller controls are used and the specifics of the dysfunctional behavior you're seeing. It might be possible for the transmitting program to detect that the throughput of the xBee link is decreasing by looking at the number of PS/2 readings transmitted per unit of time and averaging several successive PS/2 readings if things are slowing down. That would slow down any erratic movements, but at the cost of response time. Once the effective throughput rate goes up, the averaging can be stopped.

[Kevin Pace]

Let me try to make some sense of what is happening...Using the code that Attached at the tip of the thread we are running a lot of robots in a small area. I use the parameters that DIGI provides for their xbees, and I program each pair of xbees with a common channel, a common Pan ID and a DL and MY that allow them to send and receive only to each other. I use a 9600 Baud rate for the PS2 controller. If I program 3 or more pairs of xbees on the same channel with different PAN ID's and Different DL and MY I generally get robots that make servo or DC motor movements that are not called for by the PS2 controller. For example a student might be driving his robot which has two wheels a lifter and gripper and without his control the lifter might start moving up and down erratically. In other cases, motions might make a servo push in one direction as if a button is being held to make it move (But the controller of the robot is not pushing any buttons on their controller)
I even did a test where I had three robots in a small area programmed as listed above and I cut on the Transmitter and receiver of each but did not touch any of the controls on any robot. I just let them sit as if they were waiting for data to be sent to them. After a few minutes, we will often see a robot arm or dirve motors just make erratic motions. In order to gain control of all the robots when the transmitters and receivers are started the ANALOG button on the PS2 controller must be pressed. If the analog button is NOT pressed once the Transmitter and receiver are on any motors connected to Prop ports just take off and run. When the ANALOG button is pressed, the motors stop moving and are ready to be controlled. The erratic response I get from multiple robots on the same channels remind me of when the analog button is off...BUT its still on when the erratic motion occurs. I have LED's connected to the TX and RX lines on the xbees and I see no dropout of communication when this occurs. I have been thinking that there might be a way of preventing the motor movement by writing some code that looks only for a specific xbee signal and if it doesnt get that signal, motors dont move. I am currently using this command "repeat until xbee.rx == "!" and if I use every character available I have around 90 possible characters that I can use instead of an Exclamation point. I'm running some tests with this application to see if this helps. However, Im not a great programmer so Im sure a skilled programmer could look at my code and might find some issues that could be causing the action im getting. I hope this helps clarify the problem. Thanks for any help you can provide.