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.
At the Utah regional right? I was wondering if you ever fixed that issue, glad to hear you got it figured out.
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/allkb/FA1B856FC4EB6F9D86257673007935A1
Greg McKaskle
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?
Canon,
The issue you describe is usually attributed to one or more of the following problems in no particular order.
- The cRio is bumping into robot frame or is attached to robot frame electrically.
- Wire whisker is touching the opposite polarity on the power supply wiring at either the cRio end or the PD end.
- Power wiring is not inserted into the connector properly, a tug on the wiring will show this problem.
- 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.
- Improperly terminated battery wiring. Check everything from the battery to the PD. If it moves, it is intermittent.
- 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.
- If you are using multi motor transmissions, check that the motors are wired properly so that they are not running in opposite directions.
- 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.
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!
Check your event log from the match and see what happened:
http://wpilib.screenstepslive.com/s/3120/m/8559/l/97119-driver-station-log-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.
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.
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!
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
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.
Are you using any of the DIO connectors? I have seen instances where the +5V wire from the PWM cable will short intermittently to ground. This is normally seen when the White and Black wires are used for a Limit switch. The RED wire is cut and left hanging instead of being cut back and taped. The end of the wire will come in contact with the Black wire causing the 5VDC in the Digital Sidecar to turn off.
Canon,
You can use a multimeter to check for continuity between the frame and each output terminal of every speed controller with the power off. You will likely find a short on one of them if this is related only to driving. It is normal for motors to have some resistance (2k-10k) to frame as the brush dust builds up inside. It is not normal to have a reading under 100 ohms. I am thinking you are going to find a shorted wire(s) in one of those outputs. There are two things that are known shutdown issues for the cRio. That is the cRio tied to the frame with another path somewhere, or a simple short on the output of a controller. If you are using Jags, the short should show up as a fault on the Jag that is affected even without motion I think.
So the output from the vector to the CIM motors? we are running 4 CIM motors as well. So we need to put the hot wire to the output and the ground on the multimeter to the frame and if we get a reading of 100 ohms we need to replace the motor controller? or is it the wire from the PD board to the Vector? Thank you so much for your help!
Canon,
You need to check each Victor output screw to robot frame. The fans on the Victors are legal to be wired to the input terminals of the Victor to which they are mounted. They do not need to go back to the PD. Since you can only put one wire into a WAGO terminal, and it must be #18 or larger, wiring the fans to the PD is not practical. It is possible for metalic debris to enter a Victor in such a fashion that it will show a short in only one direction. However, that usually shows up in a very spectacular fashion.
I tested the output screws on each side, on one side I got .3 resistance, on the other .4, is this ok? I am also getting a 12.5 volt reading on the input to the victors. I’m not sure how to test to the frame. I connected one part to the screw and the other to the frame and get zero everytime.
Canon,
You put one meter probe on each of the output screws and one on a metallic part of the frame with the power off. You should read something higher than 2000 ohms. If you are reading the same value (~zero ohms) as when you touch the two probes together, then you have something shorted to the frame.
Ok, thank you for sharing you wisdom with us! I am relatively new to FRC and wiring in general, so if these questions seem very basic please bear with me. Why do we want to have 2000+ ohms from the frame to the vector output? Why does the short happen when it isn’t running through the frame? You do mean the drivetrain frame correct? here is the link to the multimeter we have, https://pioneers.berkeley.edu/wiki/How_to_Use_a_Multimeter from what you have said we do need to set it to the ohmmeter setting correct? So when we discover the short, what would be the proper steps to fix the problem and ensure it doesn’t happen again?
There was a team at Utah who lost communication sporadically during teleop, the mentor who I saw talking to the FTA about it looked like your profile picture. I also thought there was a team called the average Joes there, must have been mistaken.