Spotty Radio Communications!

[Mr. Lim]

Our robot communicates fine with our OI... for the most part.

but once every 30-40 seconds or so, the RC's Radio Modem light flashes red, and our robot disables for a split second (not noticeable by our drivers).

The only reason why we did notice this is we have some very fast pneumatics that suddenly switch states. Our disabled state is different from the state we normally run them in.

We noticed the problem worsens when we have two robots (with different team #s) running nearby.

I don't know if any other teams have experienced this, but basically, if you run your robot hard, and follow it around and watch the LEDs, you might notice the Radio Mode light blip red.

I don't know if this can be attributable to a noisy 900 MHz channel. We tried changing from channel 40 to 1, and it got marginally better, but it was still occuring. And yes, we changed our team number >2048 and tethered up to change the radio channel.

Are any other teams experiencing this? We had Team 1558 visit us, and they were experiencing the same problem in our practice facility, and we visited 1114's practice facility, and we experienced the same problem there.

I'm trying to figure out if this problem is more widespread than just us!

Thanks in advance!

-SlimBoJones...

[kaszeta]

Originally Posted by SlimBoJones

Our robot communicates fine with our OI... for the most part.

but once every 30-40 seconds or so, the RC's Radio Modem light flashes red, and our robot disables for a split second (not noticeable by our drivers).

Have you checked your backup battery? We've seen very similar problems, but it traced back to a undercharged backup battery---as the drive train started to draw full current (4 CIMs pull a lot of current), the main power bus would drop low enough to cause the bot to reset, which if you are in autonomous mode can cause some very weird behavior. (It took a while to debug, since the bot ran perfectly if put up on blocks (motors freely spinning), only showing up when we put it down for real tests).

A fresh backup battery solved the problem for us.

[Mr. Lim]

Originally Posted by kaszeta

Have you checked your backup battery? We've seen very similar problems, but it traced back to a undercharged backup battery---as the drive train started to draw full current (4 CIMs pull a lot of current), the main power bus would drop low enough to cause the bot to reset, which if you are in autonomous mode can cause some very weird behavior. (It took a while to debug, since the bot ran perfectly if put up on blocks (motors freely spinning), only showing up when we put it down for real tests).

A fresh backup battery solved the problem for us.

Yes we've checked out backup battery, and it is fully charged.

It seems to also happen when the robot is perfectly idle.

So if you just let the robot sit there in operator mode (not disabled), and stare at it for 30-40 seconds, you might see the red radio light blip once or twice.

-SlimBoJones...

[Jeremy Roberts]

Our team, including most of the teams at the Peachtree Scrimmage have had the same problem. When our bot was just sitting still the radio kept going in and out. I attributed this to the fact that maybe someone else was running on the same channel. Once we made sure everyone was on a different channel everything seemed to work well. I just realized that we never switched our team number back since the scrimmage so I'll do that and see if we have that problem with no robots around.

[Jeffrafa]

I had noticed our pneumatics acting strangely and sort of spotty lately too.

I've only noticed when the bot is still and nothing is being driven, but two of our solenoid valves seem to trip occasionally, and neither are to their idle state (both are in their pneumatic position without power and flip briefly occasionally). One of them is a three position valve on our main boom that causes it to move just a quarter of an inch or so every once and awhile when it blips. The other is with the plastic festo valve, which seems to flip much more often in comparison, but never long enough to cause the pneumatics to really move, just enough to release a little air and spook you.

I am yet to relate this to a radio issue, although its something i'll look into before we ship. I also don't know if its related at all to the back-up battery, although i'm fairily sure ours was dead at the time - just to note.

I did look into it more after the festo valve was hooked up and was acting up much more frequently than the other had. The spike relay it was hooked up to seemed to flip states very briefly each time it happened (it was so brief i had to watch it through many occurances to finally spot the light change to confirm that it was an electronics/programming issue).

I'm glad i'm not the first to notice something odd with this, i'll look into if its a radio problem today and post back if I find out anything new.

--Jeff

<edit> A note after jeremy's post - i've experienced ours acting strangely both at our facility with no other robots around as well as at the scrimmage competition.

Our robot did however experience rather severe radio interference during the scrimmage - our first round out the robot drove into the center goal during autonomous, with no autonomous code of any kind. It also was extremely irratic and out of control the rest of the round - we ran into a number of other robots, even after hitting our disable button, and our robot did suffer damage as a result - making it immoble for the rest of the day.

- I urge teams to tether when not competing and double-check their channel whenever they run so that others may not encounter this problem! </edit>

[Mr. Lim]

Switched out all our radios (OI and RC) and cables one by one.

Still experiencing the same problem.

I don't think I've seen enough responses regarding this to consider it a widespread issue, but we'll see =).

-SlimBoJones...

[dez250]

Originally Posted by Jeffrafa

Our robot did however experience rather severe radio interference during the scrimmage - our first round out the robot drove into the center goal during autonomous, with no autonomous code of any kind. It also was extremely irratic and out of control the rest of the round - we ran into a number of other robots, even after hitting our disable button, and our robot did suffer damage as a result - making it immoble for the rest of the day.

This is not a radio issue as to another team being on the same channel and operating your robot. IFI has a failsafe type design where if the RC is receiving multiple feeds of data the RC will lockup and just go into disable mode. Now I don't know how the multiple robots were being controlled at the Peachtree Scrimmage (if it was a homemade arena controller setup or just all on their own with radios) but at the UTC Scrimmage with the FIRST field, we didn't seem to experience this issue of teams resetting or having pneumatics firing on their own.

[Chris Hibner]

Have you tried recreating the problem using a tether cable? This should tell you if it is a radio problem or not.

What is controlling the valve? Is it actuated automatically via some routine in your code, or is it controlled when one of the drivers presses a switch?

If it is a switch control through the OI, you might consider adding a debounce to the switch. In other words, make your code require X number of consecutive samples before it changes the relay state. For instance:

    // debounce closing the claw
    if (!closeClaw)
    {
        if (closeClawSwitch == ON)
        {
              closeClawDebCount++;
        }
        else
        {
              closeClawDebCount = 0;
        }
        if (closeClawDebCount >= DEBOUNCE_LIMIT)
        {
            closeClawDebCount = 0;
            closeClaw = TRUE;
        }
    }
    // Debounce opening the claw
    if (closeClaw)
    {
        if (openClawSwitch == ON)
        {
            openClawDebCount++;
        }
        else
        {
            openClawDebCount = 0;
        }
        if (openClawDebCount >= DEBOUNCE_LIMIT)
        {
            openClawDebCount = 0;
            closeClaw = FALSE;
        }
    }

Where the variable closeClaw controls the digital IO pin connected to the spike that controls your Festo valve.

[Marc P.]

Could it also be interference from radio devices around your build space? Older cordless phones can operate in the 900MHz range, as well as some walkie-talkies. I'm not sure how the RC would respond to random noise on it's specific channel, but with wifi networks (802.11 b/g) signals from a 2.4GHz cordless phone can cause packet loss and an unreliable signal for intermittent outages. However, I was under the impression the RC's were designed to identify/validate and respond only to uncorrupted packets from the OI, and ignore all other signals.

How frequently does the problem occur? Is it every 30 seconds, every minute, every 5 minutes, and is it regularly occurring and predictable, or completely random?

[Mr. Lim]

We can't recreate the problem with a tether. Everything is rock solid using a tether.

After we switched to channel 1, the frequency of the red radio light blips went down. It's now possible to run a 2:15 match, and have it only happen maybe once or twice.

It's not a debounce issue. We've printf'ed the OI variables, and they too are rock solid.

What's happening is when the radio modem light blips red, the robot becomes disabled for a fraction of a second causing our Spikes to go idle momentarily.

My wild guess is the 900MHz frequency might be noisy in our school(s). I wouldn't know how to check that though.

-SlimBoJones...

[Bharat Nain]

At the scrimage in our school we had something similar happen to us, but only because another team left their controller on and their robot turned off. It kept cutting in and out(they were running the same channel, and team number, i think). Turning off the controller solved the problem.

[N7UJJ]

Originally Posted by SlimBoJones

My wild guess is the 900MHz frequency might be noisy in our school(s). I wouldn't know how to check that though.

-SlimBoJones...

See if someone has access to a scanner.

or goto http://www.qrz.com/i/names.html and type in your postal code in the search fiels and you will get a list of amateur radio operators in your area. I'm sure they would be thrilled to help.

[Jeffrafa]

Our problem seems to be different than team 188's, although I think chris answered why ours is acting up.

I tried ours out tethered and it continued to act oddly, randomly and frequently firing two of the solenoids very briefly. My guess is that its a debounce issue like chris suggested, although i havn't had a chance to consult it much with the programmers and check printf's and such.

I'll be sure to check all this out as soon as we get the robot running at our regional, thanks for the help.

Jeff