Quote:
Originally Posted by pfreivald
In my very limited industry experience, I've seen too much vapor-ware to trust 'functionality' that hasn't been proven...
You can substitute "very limited industry" with "decade-long FIRST" and make the same statement. Unfortunately, FIRST tries to vet too much unproven product. For a $6K price tag (at a very bare minimum), I expect products to work out of the box.
|
While this is true, you have to start somewhere. That somewhere, or sometime in this case, is now.
I'm not trying to start a fight or anything, but your statement represents something that a lot of engineers I work with do, and personally, I hate it.
We, as an engineering society, won't get anywhere using the same stuff as we always have. I'm an intern at NASA, and I hate to say I see this all too often. Some things are done the same way as they were done back in the 1960s, and there are much better, easier, and cheaper ways of doing the same thing.
It might work for a while, but I'd say replace it once support for that product is up. And sadly, it rarely happens. When that product fails, and there are no replacements, then quick engineering fixes must go into place to mitigate the problem.
In this rant, and in all my posts here, I never did say to use CAN. I said it gives a lot more functionality than PWM does. I recommended that teams start to look into it.
We tried to use CAN for a few days, and I can personally say that it sucked. It didn't work as intended. It wouldn't work for competition. It had random drop outs. One motor wouldn't work for some reason. A lot of issues. But hey... guess what, it was working. We didn't use it for competition. We used PWM for competition because we couldn't afford to lose a match because the CAN network went down. Now though, we're rebuilding the control system for our 2010 swerve drive robot, and we're going to implement CAN again. This will be a demo robot, and a loss of functionality won't cost us a match here.
CAN, or Controller Area Network, is not something new. It has been used in vehicles for over a decade. Every vehicle produced since 1996 (in the US anyway) has been required to include an OBD-II port. Part of the OBD-II's specification is CAN, along with a few other protocols, but as of 2008, the CAN protocol is required. Also, much of the vehicles equipment talks with CAN. With my car (2006 Mazda3), the stereo talks with the ECU to get the trip computer information over CAN. CAN is tried and trusted in the industry. So don't put the blame on CAN. (Source:
http://en.wikipedia.org/wiki/On-board_diagnostics)
The issues that arrise are with the Jaguars and the cRIO images and our own software. There has been a steady release of updates, resolving most of the issues with CAN. Our team is taking the initiative to try to iron out some of the remaining bugs.
Out of the 40 or so Victor 884s we've had, we've probably blown 10 of them.
Now out of the 10 or so Jaguars we have, we've burnt out just 2 of them.
That's nearly the same failure rate. The difference though is that we know that most the Victors failed due to user error, whether it be metal shavings or pushing the robot too fast while off. The Jaguars failed because of a manufacturing defect (Gray).
Also to note about the Window motors & Jaguars...
Removing the locking pins seem to help most people.
http://wiki.team1640.com/index.php?t...r_Locking_Pins
http://www.chiefdelphi.com/forums/sh...ad.php?t=83973
As part of our 2010 robot, we have the Window motors for steering, and we're planning on trying to use the CAN network for better control using the voltage mode. I'll report if I have any problems later this summer if we have any. I will be removing the locking pins. The only difference I can see between the Jaguars and Victors is the frequency at which power is sent to the motors. The Victors 'refresh' the power slower than the Jaguars. This can change the way the thermal cutout works. Remember that window motors are designed to run at either -100%, 0%, or 100%, not anything in between. We're using these motors outside of their intended purpose.