Possible FMS problems.

[Alan Anderson]

Originally Posted by Canon reeves

...I connected, enabled, then drove forward slightly and rebooted. The CRIO didn't reboot until enabled and drove?

That could be caused by a bunch of things. Two seem likely enough to be worth investigating. Maybe your battery was essentially dead and couldn't provide enough current to run your drive motors. Maybe you have a couple of frame shorts that bring the cRIO power return to a high enough voltage that 24v on the power supply isn't sufficient to keep it running.

A bad Ethernet cable won't cause a cRIO reboot.

[Fifthparallel]

One thing I've noticed is that this problem seems very particular to the 4 slot cRio and will occur with very secure power connections. I've seen this happen to about 11 robots over the past two years, where the robot will be hit rather hard and will reboot for no apparent reason.

I even troubleshot this with a rookie robot where we discovered that if we dropped the robot (above 1" drop height) while the cRio was relatively not constrained to the robot, the cRio would reboot. Driving the robot at fast speeds and stopping quickly or tugging the wiring in different ways (which would have exacerbated any loose wiring) did not cause the cRio to reboot. However, driving at high speeds into any solid surfaces or getting the robot hit (even with a swift kick to the bumpers...) would cause the cRio to reset based on the force used.

Does the 4 slot cRio have a force-sensitive sensor inside of it that tells it to reset if a threshold is met? This seems much too silly to be the cause, but it seemed too consistent to not be the problem. It was even a problem for Team 1410 at the 2014 Utah Regional, where our cRio reset after hard connects with other robots.

[Alan Anderson]

Originally Posted by Fifthparallel

...a force-sensitive sensor...

A main circuit breaker with a certain kind of fault can do a good job of detecting impacts in specific directions and briefly shutting off before returning to normal. A piece of metallic debris near certain components, or a stray bit of wire strand, can cause a loss of power when the robot is jerked in a specific way.

There really ought to be a better way of finding such intermittent situations than just banging and tugging on things at random, but when pressed for time anything more systematic might not be worth trying.

[TheRamAlakazaam]

Do you use a smart dashboard..
Our robot would reboot after autonomous because of it.
Turns out only Java Users can use it. So my team decided to set it to false along with other teams and we are all driving "blind" basically.

[RobotKnight2014]

At the Utah regional right? I was wondering if you ever fixed that issue, glad to hear you got it figured out.

Originally Posted by Richard Wallace

^+1 to what Mike said above.

We had a similar issue in one match. Afterwards we found an intermittent short to our frame that had gone undetected during inspection. We fixed that, and never saw the problem again.

[Greg McKaskle]

The cRIO does not have a shock sensor. The data sheet showing the shock and vibe testing is here .. http://sine.ni.com/ds/app/doc/p/id/ds-354/lang/en.

If you are in a relatively static-free environment, you can clean debris from the cRIO in about five minutes. I almost always find lots of glitter and wire bits. I have seen cases where the reboots ceased for the remainder of the matches. I have also seen cases where nothing improved. Procedure link is below.

http://digital.ni.com/public.nsf/all...257673007935A1

Greg McKaskle

[Richard Wallace]

Originally Posted by RobotKnight2014

At the Utah regional right? I was wondering if you ever fixed that issue, glad to hear you got it figured out.

Our team is in Michigan -- the issue I mentioned occurred at the Southfield District in Week 1. The intermittent chassis short was caused by some wiring that had previously provided power to a custom circuit (LED string), which had been removed after it was damaged during a practice match.

What was the issue seen at Utah?

[Al Skierkiewicz]

Canon,
The issue you describe is usually attributed to one or more of the following problems in no particular order.
1. The cRio is bumping into robot frame or is attached to robot frame electrically.
2. Wire whisker is touching the opposite polarity on the power supply wiring at either the cRio end or the PD end.
3. Power wiring is not inserted into the connector properly, a tug on the wiring will show this problem.
4. Rare manufacturing defects have been observed on the main breaker. while the robot is thruned on and booted, trying lightly tapping the red reset button on the breaker. If the lights on the robot blink, replace the main breaker.
5. Improperly terminated battery wiring. Check everything from the battery to the PD. If it moves, it is intermittent.
6. An intermittent short exists in the branch wiring or you have a defective motor controller or motor that is showing a short in one direction. Try removing all breakers and reinserting one at a time to locate the offending branch.
7. If you are using multi motor transmissions, check that the motors are wired properly so that they are not running in opposite directions.
8. You have an intermittent power wiring to the DLink or you have not wired the power convertor to the dedicated +12 volt output on the PD.

When you have a shock intermittent, use a large screwdriver to tap the handle (or other insulated tool) on various parts of the robot until you find the sensitive area of the robot. You may find swarf in the cRio, PD or DSC or you may find improper wiring on the outputs of one of the cRio modules. If the condition only occurs when you are driving, the problem is in the drive train or the cRio to robot frame short.

[Canon reeves]

There has been a lot of mention of a frame short, could we test for this by testing the frame with a multimeter? we did that and it wasn't conducting anything, we checked the battery and all the connections to the pd board with it and got a consistent 12.5 volts. After the testing when the robot drove forward and shut off, we tried turning it back on, it took a few times but after it did turn back on we had no connection whatsoever, we tried rebooting, reset the radio, re-deployed code, exited the driver station then came back in. Under the diagnostic page on the driver station there was no light for the bridge, but there was a red light beside "robot". I've been trying to get it to shut off by shaking and dropping, and it still isn't rebooting like it is when I drive it. Is there anything else in the driver station we can use to diagnose the problem? Thank you guys so much, the team really appreciate's your help and GP!

[noceradave]

Check your event log from the match and see what happened:

http://wpilib.screenstepslive.com/s/...og-file-viewer

We had a similar problem once, it was due to binding in the drive train and when the driver moved the joystick forward and reverse rapidly enough, the current draw on drive motors caused a drop in voltage significant enough to cause the crio to reboot. The event log will show if voltage drops are causing this.

[Canon reeves]

Originally Posted by Al Skierkiewicz

Canon,
The issue you describe is usually attributed to one or more of the following problems in no particular order.
1. The cRio is bumping into robot frame or is attached to robot frame electrically.
2. Wire whisker is touching the opposite polarity on the power supply wiring at either the cRio end or the PD end.
3. Power wiring is not inserted into the connector properly, a tug on the wiring will show this problem.
4. Rare manufacturing defects have been observed on the main breaker. while the robot is thruned on and booted, trying lightly tapping the red reset button on the breaker. If the lights on the robot blink, replace the main breaker.

Yesterday we tested for all of these, we replaced all the connectors from the CRIO to the PD board, we tried shaking the CRIO to get it to reboot, we also tried the tapping on the reset, and pulling on the wires. I think what we will have to do next is test the PD board connections to the motor controllers and all of the breakers. We also put in two new vector motor controllers this week and our mentor also had us wire the fans to a 30 amp slot on the PD board.

[Canon reeves]

Originally Posted by noceradave

Check your event log from the match and see what happened:

http://wpilib.screenstepslive.com/s/...og-file-viewer

We had a similar problem once, it was due to binding in the drive train and when the driver moved the joystick forward and reverse rapidly enough, the current draw on drive motors caused a drop in voltage significant enough to cause the crio to reboot. The event log will show if voltage drops are causing this.

Will this still be accesible when we aren't connected to a field and still driving around? Thanks for the link, we will definitely use it!

[Canon reeves]

Originally Posted by TheRamAlakazaam

Do you use a smart dashboard..
Our robot would reboot after autonomous because of it.
Turns out only Java Users can use it. So my team decided to set it to false along with other teams and we are all driving "blind" basically.

I'm not sure if we are or not, we are using the standard clamshell for driving, we have the same dashboard as last year and it was fine last year. I will ask the programmer later if we are but I doubt it.

[geomapguy]

Originally Posted by Canon reeves

I'm not sure if we are or not, we are using the standard clamshell for driving, we have the same dashboard as last year and it was fine last year. I will ask the programmer later if we are but I doubt it.

Highly doubt you guys are using SmartDashboard since your team uses LabVIEW. I think I recall seeing the regular dashboard when playing with you guys. So i don't think what Raul said applies

[DjScribbles]

Originally Posted by Canon reeves

Will this still be accesible when we aren't connected to a field and still driving around? Thanks for the link, we will definitely use it!

The event log is created by the driver station application local to your PC, and stores the logs on your hard drive. If you've been using the same PC for a few years, it will take a long time to load each time (until you go to the logging folder and delete old logs, use the windows sort by date to do this as log file name patterns changed year to year)

I only really discovered this utility at our last event (Southfield week 1) where the awesome FTA used it to help us diagnose some on field problems, it's very very helpful as it shows a graph of battery voltage, cpu/ram usage, and any errors that were sent. After getting comfortable with it, I was able to squash a few more issues from the viewing the logs.