Issue with Talons

[KrazyCarl92]

http://www.chiefdelphi.com/forums/sh...hlight=chassis

This picture shows the electronics on the practice bot. Granted the wiring job is rather disorganized, but we do not use a ribbon cable on the DSC, we use a different type of cable as shown because we find they have far less issues than ribbon cables. It's still possible that this cable could be the source of issues, but not the kinds most teams with ribbon cable issues encounter.

[404'd]

Originally Posted by KrazyCarl92

http://www.chiefdelphi.com/forums/sh...hlight=chassis

This picture shows the electronics on the practice bot. Granted the wiring job is rather disorganized, but we do not use a ribbon cable on the DSC, we use a different type of cable as shown because we find they have far less issues than ribbon cables. It's still possible that this cable could be the source of issues, but not the kinds most teams with ribbon cable issues encounter.

We used a (old KOP?) round type db37 cable like the one in your picture, for our first control board, and have seen some glitching problems. I switched to a shorter 1 ft one (not sure where from) for our test drivetrain and haven't noticed the same glitching problems.

Could be related to new cable or not, just my observations.

[Mike Copioli]

Both Al and Alan Andersons suggestions are good. The most likely problem is an intermittent PWM signal either at the software or hardware level.

Another possibility is an excessive periodic loop time. The time out on the Talon is 100 ms. That means if the Talon does not detect a rising OR falling edge after 100 mS, the output will be disabled.

If you have access to an oscilloscope you may us it to verify your loop time by toggling a digital I/O every periodic loop. Make sure you call this in the same area you set the throttle value.

As Alan stated the jump and jitter can be caused by an interrupted PWM signal.

Check for poor PWM cabling and DSC performance issues.

[Ether]

Originally Posted by Mike Copioli

If you have access to an oscilloscope you may us it to verify your loop time by toggling a digital I/O every periodic loop. Make sure you call this in the same area you set the throttle value.

This is an excellent suggestion.

If your team doesn't have a scope and can't afford one, there's a fairly simple and inexpensive way I have used to create a piece of test equipment that will do things like this, using the RS232 or parallel port of an old laptop. If there's enough interest I will post a paper about it. PM me.

[RyanN]

Originally Posted by Ether

This is an excellent suggestion.

If your team doesn't have a scope and can't afford one, there's a fairly simple and inexpensive way I have used to create a piece of test equipment that will do things like this, using the RS232 or parallel port of an old laptop. If there's enough interest I will post a paper about it. PM me.

As scary as it sounds, you can also use a computer's line-in port and Audacity to take in a waveform. You'll want to use a voltage divider to limit the voltage going into your PC as to not fry your sound card, but it's doable and works pretty well in my experience.

http://www.ledametrix.com/oscope/index.html

[Ether]

Originally Posted by RyanN

As scary as it sounds, you can also use a computer's line-in port and Audacity to take in a waveform.

True. I've been meaning to try that sometime. I use Audacity all the time for ripping my old collection of cassette tapes.

You'll want to use a voltage divider to limit the voltage going into your PC as to not fry your sound card, but it's doable and works pretty well in my experience.
http://www.ledametrix.com/oscope/index.html

What's the input impedance of a typical sound card, do you know? It looks like he's got the voltage divider bass-ackwards. He said he wanted to divide his 5-volt input down to 1 or 2 volts.

Food for thought:
If all you are trying to do is measure the timing (not observe the waveform) of a digital signal then you don't need the sound card's ADC. All you want is to capture and timestamp the edges. The parallel port works great for this. You can poll the data pins of a parallel port at 680KHz or so... way beyond the frequency of the audio card.

[KrazyCarl92]

So here's an update with what we tried tonight:

At first we started driving the robot around and did not observe the problem. Then, within 10 minutes the issue started back up again with the same symptoms as before. The robot twitches to the right before driving forward or reverse when it is command to go at high speeds.

To describe the trouble shooting and results we got, I will use the terms "DSC A" and "Cable A" to describe the equipment we started with, and "DSC B" and "Cable B" to describe the components we tried switching out with.

First we switched the cable from Cable A to Cable B since this was the easiest switch. The problem got worse. Now when enabled, the robot just ignored our commands and abruptly twitched turning to the right continuously.

We then tried the original components and got back to square one. Next we tried DSC B with Cable A and the problem seemed to be remedied, but we were unconvinced because we now thought that the problem could be with the cables since it seemed to be significantly worse with Cable B as compared to Cable A when both were paired with DSC A.

When we tried DSC B and Cable B together, we got the same exact symptoms as DSC A and Cable A; the robot does a single twitch to the right before driving forward when commanded to only go forward.

So we went back to DSC B and Cable A since this got us the best results. And after about 15 minutes of driving that way, we have yet to reproduce the problem. I'm hesitant to say that the problem is fixed because the logic is very odd and we haven't tested extensively yet, but the symptoms of the issue have yet to be observed in this configuration.

Can anyone else follow this or make any sense about what these results could mean? Maybe both DSC A and Cable B are bad, but I would expect more sensible results in that case...