I wanted to take a poll to see how many people have broken a part or all of their controls from the new system. If you decide to post can you please tell what broke and how you think it broke? Also i am going to leave jags out of the poll because it has it own thread. Please post if multiple parts have failed.
We’ve broken a Jaguar, an accelerometer, and a couple of the cold cathode lights that we put on our driver station(it got shoved into a truck and they got crushed)
As far as I know, We’ve only messed up one of our analog breakouts. It was wired wrong and released a bit of smoke but it still works…
The ETH2 port on the DS is loose and inoperative. Not sure, but methinks a student got a bit enthusiastic with unplugging a cable.
we didn’t break anything… yet…
I did bounce a battery across the room, and digital sidecars don’t take too well to be dropped off of the top of the robot sitting on blocks…
This happen to both of our DS’s. We were extremely meticulous about unplugging and plugging things in carefully and avoiding ESD. After the second one, we were wondering if we’re the only ones.
I accidently put the positive in the negative on the analog breakout. Smoke, fire, and a fried breakout.
Time to give the reason we posted this poll.
Since we opened the box on the control system back in December we have had nothing but different hardware problems with it. let me explain.
First of all we are programming with C++ and installed the system on a backing of plywood in a practice robot base with a shooter mechanism mounted to it. This robot has always been kept in a classroom away from metal working tools- no shards or such other than what is generated by the machine itself. The cRIO is electrically isolated from the frame. We are using only Victor 884s for speed controllers.
Now for the fun-
Our first problem came when we tried to install programming and set up the system. At that time we discovered that one of the ethernet ports on the driver station was working intermittently. Since you need to chain the download through the station this completely screwed up our installation and only after reimaging and such with a new driver station (purchased) did we get it running right. (hence the earlier posts here expressing much dismay)
Weeks went by and code was being developed. Camera tracking, various sensors, drives- all seemed to be working. Then disaster #2. The 12V bridge modem port on the distribution board simply stopped working. Likewise the diodes of the 5V camera power worked when you touched the board although the connection read a continual 5V when metered. Obviously there was some contact issue inside the board. So we could get anything done we attempted to run the bridge off the nearby 12V source only to find that when the robot was in heavy use and voltage dropped the modem would reset itself and the robot would run away wild (and it pinned Kristian on top of a desk before we could disable it).
At about the same time as the 12V port went dead the cRIo started flashing a status light message and an error came up when we tried to reimage, reset the IPs or do any coding. Fortunately our friends at team 103 bailed us out with their second system and we could continue work. We are working with NI now to rectify that whole situation.
To add insult to injury right after we set up the new system and started to get some code in the second driver station failed on us. This time the OTHER ethernet port simply stopped working.
So now we sit with incomplete code a week from ship date and thoroughly disgusted with the system, FIRST, robotics and life in general.
Before everyone starts diagnosing that we did this or that wrong let me say that we followed every manual we could find from WPI, FIRST and NI to the letter and we have hundreds of pages of website info read, assessed, filed and followed. We have been painfully careful about static discharge from our hands and clothing. The driver station is grounded per FIRST specs.
The practice robot hasn’t driven more than 50 feet or so and has spent most of its time on blocks while being programmed. We aren’t banging into walls with it.
So at this point is is a possibility that team 25 will have a non-functional robot at the NJ regional in 3 weeks. It will look nice…
In closing- to theorize what may be happening. When we code and work on programming we are running the robot for extended periods of time. I am beginning to believe that simple extended time use is destroying the system components and that is what somehow corrupted our cRIO. I am not to sure how we program a bot without running it and testing but I am just a robot coach and maybe I am missing something.
So if anyone sees something we obviously overlooked clue us in. We have a major money investment in a 3 event season riding on whether these parts will actually perform as promised.
Thanks
WC 
so far so good. nothing broken or inoperable
Thank you for posting this poll.
As of now the only thing we have broken is 1 Analog breakout by wiring the PD with reversed polarity (luckily everything else is polarity protected). It is also lucky for the student I never found out who it was :ahh:
However, our system has very little runtime under its belt to this point.
I will be watching this thread closely to see what kind of failures teams are experiencing. The DS in particular appears to be plagued with a variety of problems. It is very worrying to see a respected, thorough team such as 25 posting comments such as the one Wayne has posted here.
So far nothing has broke on us (then again we have not fully tested everything).
Hopefully everything holds up.
Nothing is broken yet knock on wood, but i have noticed that teams are having problems with the DS. There was an update a while back that made it mandatory to ground the DS. I recommend that all teams do this soon. Also, always remember to touch the robot or some large piece of metal before touching electrical components.
We had a Spike fail; the cause was pretty obvious: the 12V and ground were wired into M+ and M-, and my clue that something was wrong was when the circuit breaker tripped about 15 times and the wires got really hot.
We also have had a lot of pins bending; one bent completely flat after we put the relay module back in – it didn’t respond, so we took it out and discovered this. It was incredibly nerve racking to have to unbend this pin YESTERDAY – no time to get a new CRIO from NI if it was irreparable. It was probably the scariest thing I’ve had to do :ahh: but it works now. Just be very careful when inserting modules and only remove them when you must…
I also had to unbend pins on the digital sidecar, but I suspect these got bent when someone dropped a battery onto a jaguar… yeah, that left a nice dent.
One of our team members wired two Jaguars backwards (Like, power in the motor side and motor on the power side), one of them survived though.
~DtD
Only thing that dosn’t work 100% is we cant get a battery readout voltage anymore.
Our Jaguar spewed smoke just yesterday.
This afternoon one of our programmers uploaded an updated program for the robot. It uses tank drive and we needed to add a couple of victors to control our collection system. The code loaded fine, but when we restarted the robot the Driver Station displayed the following:
Team: 2333
System: Watchdog
Mode: Teleoperated
Battery: 00.00 v
DS Rev: 2009-02-10a3
And everything quit working.
Do you have any suggestions? Our Robot is dead!
Our team also has had difficulty with the DS ethernet ports failing. We also have implemented the grounding modification and constructed per the rules. Ports appear to fail when we are tethered. Generally our robot is on wood blocks under this condition and we do have conveyors moving, so we are thinking ESD is the problem. Both ports on our original DS failed, and then 1 more on another DS. I think there may be inadequate Transient Voltage Suppression on the Ethernet inputs in the DS. If this is the case it is unclear whether the transient is between the Ethernet Differential Pair wires or between the ground level of the DS and CRio. I am betting on the later. For whatever reason, the cRio side seems to be more robust. FIRST so far has been great in working with us on replacements, but we are concerned as we head to competition we will have no choice but to operate tethered which appears to be the worst situation. Advice to all teams is to have a defined procedure on how to hook up tethered and make sure all follow it. We are located in the dry winter Northeast so it would be interesting to note if teams in more humid locations are suffering similar failures.
One compliant I have with the control system so far is the Digital Sidecar male 0.1" header pins.
Our male pins are starting to get bent and destroyed just from wiring up the electronics in only 6 weeks. At this rate I will have a backup driver station because I know the driver station pins will eventually break.
In future years, I hope FIRST switches to female connectors for the DSC similar to the VEX controller.
Female header pins, http://www.vexrobotics.com/vex-robotics-microcontroller.shtml
Male header pins, http://first.wpi.edu/Images/CMS/First/digital_sidecar_rdax_600x357.jpg
Oh darn, there’s no option for “everything”