Match Communication Problems

[ALTrammell818]

Our team was wondering if any other teams have been experiencing communication problems during matches. For our robot, it would sync up before the match correctly, sit through autonomous, then as soon as teleop began, we would lose communication. One thing that was also noticed is that our driver jumps on the controls as soon as teleop begins and our robot drives about 2 feet until all of the other drivers get on their controls. As soon as everyone else begins driving, our robot communication drops. In the entire traverse city competition, we were able to play 1 full match properly, 1 for 3/4 of the time, and another for about 20 seconds.

The weird thing is, outside of the match, our robot works fine under both tethered and wireless settings. Also, before the competition today, we were allowed to try and resolve this problem by running on the actual match field before the competition resumed. In this time, we ran through 4 complete cycles of auton/teleop on the match field, simulating the exact technology that we would have to play under minus the other robots. We have tried swapping the wireless gaming adapter on the robot with a replacement and relocating the box, but that did not help.

Another thing brought up was the large amount of data being processed wirelessly during the competition and our code may have to many standby functions that are just sitting in the program. There is also the idea that there may be an ip conflict somewhere in the area causing problems. We will be at the detroit competition and see if this problem still occurs. I'll try to remember and update it after we compete there.

Any feedback on other teams having comm problems would be great.

[gorrilla]

Check your wiring, you could have a broken or loose wire that could be causing interference...

[pitzoid]

Originally Posted by ALTrammell818

There is also the idea that there may be an ip conflict somewhere in the area causing problems. We will be at the detroit competition and see if this problem still occurs. I'll try to remember and update it after we compete there.
Any feedback on other teams having comm problems would be great.

No chance of an IP conflict, you're on a VPN, thats what all the WPA key headache is. The fields run a monitoring system to detect area RF interferrence. If everyone else is running ok, its something with your hardware/software. You mentioned you tried a different radio. If your bot is connecting for testing and then has some sort of issue when connected to FMS my guess is its something in your code. I'd find someone really familiar/successful with how ever you're programming and have them check your code to see if they can find an obvious issue. Testing to Field competition should seemless if you're coded according to best known practices.

[ALTrammell818]

First note that a friend posted the earlier message.

I think that there is something on our robot causing interference with the overall wireless connection, thus causing a small bottleneck.

When auto starts we are connected. If we get to our controls first we can drive for a split second. The moment everyone else starts driving we disconnect.

I believe that between our code and a possible hardware malfunction we are unable to stay connected while there are more than 1 robot running at a time simply due to this bottleneck.

Any thoughts?

[samir13k]

on the bottom lefthand corner of your Classmate PC, there is a little box that usually says things like

Teleop Enabled
Stop Button not connected
Disabled
etc...

did your drivers look at that box? From what youve said, it sounds like theres an error in your code. if that bottom left box says "Watchdog not Fed" then you have a coding issue. That usually has to do with a coding error in which its waiting for a certain feedback and doesnt recieve it or something of the sort...

Theres someone who could go into much further detail most likely. But being "Watchdogged" sounds like the error to me

[randalcr]

Were you having the problem in just one station or did it occur everywhere?
We had a problem like this, but for us it only happened in red and blue 2 stations anywhere else we ran fine.

[Jack Jones]

Been there, done that last year when we would die in about 1/4 of our matches.

It's such a shame that such a beautiful wiring job as yours would have those kinds of problems. But the cold hard fact to face is that we have a labortory instrument (cRio) talking to a desk-top gaming adapter riding on a 150# robot @ 10fps, when neither of which was intended for that application.

But it is what it is - so here are the things to look for - and don't stop just because you find something, there may be multiple glitches.

#1: Cat connections at cRio and bridge. Get a good connection and hot-glue - use a Cat-5 AB switch for teathering.
#2: Power to the CRio and bridge - both are lame for this application - hot-glue the bridge connection, or hardwire it (if rules allow that?)
#3: Main Breaker - have heard of them tripping without opening the lever, and without excess current. cRio has no battery back-up and will want to re-boot when power is interupted - even for an instant.
#4: DB37 cable to d-side car - make sure it's screwed in at both ends.
#5: Your code - I know you use Lab View, but have you written a custom vi? Check your memory allocation. If you access a pointer without having allocated memory {eg. pntr = new Thimajig(1,2);} you will get a "watchdog not fed" error and die when you try to read or write to that address. I observed that you don't die till teleop, and then not at any particular time during that period, except maybe when kicking. Look for something you don't do in auto-mode that you do in tele, with special attention to your fire control.
#6: Something I've seen in common with bots having dropped com issues is that either the cRio or camera is mounted on a large sheet of polycarb. The NI rep postulates that the polycarb can build up a surface charge. Since the polycarb is usually attached to the isolated frame, the only way to discharge is thru the cRio or camera frames, which are grounded. Neither the cRio nor bridge will tolerate spikes!!!

-

[kwotremb]

Something else that could be a problem, we dont know ... For holding back our kicker we are using a strong electro-magnet (300 lbs of holdback I believe, hey it was free). Dont know if this could be any issue or not, but it seems like we lose connections both when its on and off. We really havent been able to find any sort of pattern with this problem, and have not been able to replicate it besides during matches. It happened on both the blue and red side and at multiple stations.

Before our second to last match, someone from 2771 told us to try running without the camera. We did, and ran for part of the match, but then lost comm part way through (At least we were able to kick the ball 40 feet a couple of times without fully winding up the kicker). Then with only 3 matches inbetween we go out for out last match, and again nothing. Didnt touch a thing besides turned our robot on and off and such. Hoping we can find something so we can at least compete down at the Detroit District.

[martin417]

You might want to look at this thread. It sounds like the identical symptoms. Are you using the PSOC?

[jspatz1]

We had this identicle behavior at Kansas City which caused us to have poor or no communication in at least 3 matches. Problems occured only on the field FMS, never when tethered or wireless elsewhere, and never before we first hit the field. We were told that review of field data later revealed we had a communication conflict (sorry no specifics) with another team on at least one occasion.

The field staff recommended the following procedure to avoid problems with linking up and with proper ID at the field. It really should be part of the event instructions for everyone. Basically problems can occur when your system is started before your team ID has come up in the FMS. We never had a problem after sticking to this procedure, and know of at least one other team that solved their problems this way also. We recommend it to everyone, especially if you experience flakey behavior on the field:

1) Do not log into your DS or power up your robot before entering the field. If you need to do so to check something or to charge your pneumatics, do so early enough to log out and power off your robot.

2) When entering the field, wait for your team number to come up on the banner before logging into your DS. We have a robot handler signal the DS handler that the team ID has come up, then we wait a few seconds before logging on.

3) Log onto the DS and wait for confirmation that communication is established. We have the DS handler signal the robot handler that the DS is linked and ready.

4) Power on your robot only after the DS is on and linked. Stay with it until your indicator light confirms it is ready. Don't leave it to the field staff to check your status for you, they are busy. See to this yourself.

I would also reiterate the suggestion that you read the threads discussing problems with the KOP USB hub. We suspect we had problems with it as well, and replaced it.

Hopefully this will help others avoid some heartache.

[joek]

try checking that none of the teams are on the same channel.
another thing is that if there are a lot of bridges running in the area, it causes severe comm issues, as i observed at the practice competition

[byteit101]

we had a similar issue at Buckeye, we were driving, until something jarred our robot in just the right way, then we died. You might have a different issue, but we found out that the circuit board was being pressed on the button in the front of the gaming adapter by the power cable, and when we were hit, the board would trip the button

[dtengineering]

Well, we had a communication problem before a practice match in Seattle... then the field crew pointed out that the comms work better when we plug our ethernet cable back in to the cRio BEFORE we put it on the field.

Ooops.

Seriously, though, we had no comm problems in Seattle, despite launching our 8wd robot over the bump several times, and coming down hard enough to smash an AM 2007/2008 kitbot wheel hub. The electronics can probably handle more "g" than the robot.

Jason