Go to Post I find it ironic how the game "Recycle Rush" can create so much waste. - bEdhEd [more]
Home
Go Back   Chief Delphi > Technical > Electrical
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #5   Spotlight this post!  
Unread 03-17-2011, 09:59 PM
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,748
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Intermittent Loss of Communications During Play

As I mentioned in another thread. I was volunteering in NJ in week one and saw issues with power on quite a few robots. There wasn't one root cause, but several that are pretty easy to differentiate between. The causes were very similar to previous years with the new control system.

One diagnostic I use is to count how long the robot stays disabled and observe what the BFL looks like.

If the robot halts for less than ten seconds, it is a watchdog or motor controller over-current situation. This isn't long enough for a reboot of any other component.

If the robot halts for between ten and forty seconds, I look at the cRIO reboot. It could be due to code or due to cRIO power. SW, especially Java and C++ can cause a reboot with a null reference, bad pointer, etc. The cRIO supports redundant power supplies. Not terribly useful in FIRST, but it means two positive and two negative connections. Despite this, the most common situation is to put the black and red connections on adjacent pins. There is often copper showing and it just takes a wiggle of the cables for the copper to touch and the cRIO to reboot. As with all of these, also check the other end of the cable.

If the robot halts for more than forty seconds, but not for the entire match, I look at the radio power. I saw one team with a loose barrel connector, I think Radio Shack, and probably five robots that were wired to the unboosted PD voltage rather than the boosted radio supply. Adding in the voltage regulator is certainly a good thing, but now there are additional connections that could be loose, or shorted.

If the robot halts for longer than a minute or for the entire match, I look at the radio switch and the SW. FTAs definitely fixed a number of cases where radio switch had been jostled into AP or auto. In other cases the issue was that the SW never switched from Auto to TeleOp. The BFL pattern indicate the mode of the packets being processed, not the SW that is running, so that isn't really helpful, but this issue is usually duplicated by a practice match in the pits or practice field.

If you happen to be watching the robot when the halt happens, sometimes the BFL will give hints. It will often dim with low battery level, and is helpful in spotting cRIO reboots.

Greg McKaskle
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 04:25 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi