Quote:
Originally Posted by gblake
Techhelpbb and other folks - My EE degree is a bit dusty; but recently there seem to be a lot of uncertainty about possible problems (and solutions) in this thread and very few clear, specific questions/answers in the last 10-15 posts.
I think the entire conversation would be improved by a clear, clean, concise list of simple observable symptoms linked to proven root causes. There have been a lot of "maybe"s, "sometimes", "somebody told me"s, and possible test method posts (techhelpBB - I have to say some of those have been way into the weeds...); but there have lately been few "Here is the checklist you follow to fix problem X", or "Here is the checklist you follow to separate problem X from problem Y".
Who can cut through the fog, drain the swamp, and help that majority of students & mentors who aren't EEs, and who don't have the time (right now) to immerse themselves in the aracane minutia?
Maybe someone could start a new thread to discuss the physics of the COTS circuitry and possible home-brew test methods, and this one could stick to proven results?
Blake
|
Fair enough, I'll summarize our situation...can't speak for the others.
The criteria for the problem we have:
1. We are not using the 2CAN, we are using all black Jaguars with one as the RS232 bridge. For what it's worth we are programming in JAVA.
2. We are using them in one of 2 modes as it relates to the wheels, which most exhibit the problem most often (we do occasionally have some issues with the arm that are similar...but our arm is highly geared down).
A. In one mode, we have >no< encoders. We drive completely off vbus and we see a problem occasionally where the Jaguars just time out. A quick reset and they generally return...and that's being general....when they don't we have to reboot.
B. In the other mode we drive drive 2 Jaguars both with a PID velocity setpoint and we have a circuit to isolate the encoders using an optocoupler and TTL logic. This circuit is the subject of another topic on this very forum:
http://www.chiefdelphi.com/forums/sh...t=89282&page=4
The circuit shown is the work of the other engineer...functionally it is equivalent to what we made. With the only obvious difference being that our circuit has a pull up on each encoder channel (for testing the circuit without either the Jaguar or the encoders mostly to check for wiring problems to either). Also our circuit uses the extra inverters to provide test points for an oscilloscope...consider it proof of concept.
Even with this circuit our robot will drive straight as an arrow, spin, dance and do everything it is supposed to...for only so long. Then we'll suddenly develop the very same CAN errors (every few minutes). In fairness I'll say we see the problem more often when we use the encoders...but...we do see the problem without them. I personally think we can attribute some of that to the simple fact that if the Jaguar malfunctions on the CAN bus whatever caused that could also cause it to loose track of the encoder. The other reference is a different matter.
3. It has been noted by myself and other mentors that the circuit in 2B above becomes necessary because of various sources of electrical noise. The wiring of the Jaguars is prone to a specific source of noise called a ground loop, especially when the grounds are connected as in a more simplistic encoder split (see other topic for more detail). This circuit eliminates this source of noise from the encoders as it isolates them from each other and even the encoder by using light. It also lets you put some test equipment on there to see what's going on...minus the software. We found that invaluable because we have a bunch of bad encoders from years past and it's hard...with so many possible issues...to find them all. With this circuit (as we made it) we can see on an oscilloscope when the encoders are not working properly and we can do that test while the wheels spin at any test RPM. I can assure you by test myself that the encoders are working properly.
4. The circuit in 2B does not do anything about any electrical noise issues on the CAN bus, it has nothing to do with it. Other mentors and myself have noted that placing a capacitance across the various sensor power supply terminals on the Jaguar (the only place we can legally get to the internally regulated power sources) improves the issues with the CAN bus errors moderately (not completely).
5. It has been suggested earlier in this topic that we were either overloading the Jaguars or they were browning out. We have no evidence of overloading the Jaguars in that we have not blown or tripped any current limiting devices (fuse/breakers). The robot doesn't seem to overly drain any properly operating battery we put on it. The Jaguars themselves, via BDC-COM do not indicate any major overloads. This leaves us with the possibility of a brown out condition. A brown out condition we would need to test for on a robot moving at high gear around a playing field and that does not appear on any test we've been able to reproduce while stationary.
6. I then proceeded to attempt to figure out how to test for this condition, in the most practical, least expensive, most definitive manner. I did so in detail as it would seem that we are not the only one to experience this problem. Furthermore, even if we didn't have this specific problem...we all should know by now that a low battery condition can cause issues on the robot and sometimes people don't notice it because batteries are often best tested under load.
7. If you use the Jaguars as you would the Victor 884 (no CAN, just PWM cables from the digital side car) you'd side step the issues. To put it as simply as possible, the way the Jaguar responds to PWM unless you really do overload the Jaguar, it'll mostly ignore major sources of non-repeating noise that might otherwise trip up the CAN bus. In this mode, you can still use the encoders on the cRIO if you want it, however, in this mode we've sort of given up on the CAN bus.
7. To date...the only options I've considered beyond those discussed are to put capacitors across the CIM motors to try to snub some of the noise from the brushes. Put capacitors on the Jaguar's sensor power supply wires to try and add additional filtering to the Jaguar's internal power supply. Removing the ground wires from the CAN cables has been suggested in the other topic.
8. Other people in this topic have reported an issue from boot up, which until recently we never experienced. In their failure mode they turn on the robot and basically fail to initialize the Jaguars on the CAN bus. It has been suggested that this is a timing issue and can be addressed in software. We have seen this issue a total of once.
Conclusion:
What I am looking for, like you, is a way to standardize the process and eliminate these painful problems from the system. They are *too technical* and expensive and effectively form a barrier to getting this working properly for anyone that doesn't have the knowledge/skills/time to make it work. Given the state of my physical health right now....I more than anyone...do not want to be making anything or wasting money looking for phantom problems.
The tangent above was merely my way of looking for an economical test for making sure that the power quality on the robot is not causing adverse problems. If we can determine that the power quality is the problem...then we can at least define a reasonable process to find the problems. Right now...I'm looking for something I can't test...because I'd have to chase the robot with test equipment in high gear.
It's possible there's simply something wrong with the CAN communications, but honestly, when other mentors have had to troubleshoot that issue, they've had to confront the manufacture of other circuits because otherwise they'd need to buy something for a logic analyzer to test it.