Issue with Talons
 

Hi all, I was hoping to get some help with a strange problem with some Talons.

Tonight we decided to do driver tryouts with a simple robot consisting of a drive train with two CIMs to each side, all controlled over Talons. Normally it drives fine, but occasionally while driving straight the side going forward (the lights on the Talons are green) reverses for a very quick moment, going backwards. The lights on the Talons turn red when this happens. We are using simple Arcade Drive code, and I've checked the values being sent to the Talons in the code, and they are not reversing at all there. This happens when driving straight forward and backwards at full power (so all 4 Talons have had the issue), but not when purely turning.

We think there is an issue somewhere between (and not including) the crio and the Talons themselves, since it happens to all 4. Additionally, once when powering the robot on one side of the robot moved at a high speed for a very short amount of time, which leads us to rule out code issues.

Tomorrow we plan on replacing the Digital Module, the Digital Side Car, and the cable connecting the two one at a time to see if any of them are causing the issue. Is there anything else we should be doing or checking for that anyone can think of? I tried to give all relevant info but if anything else is needed I can provide it. Thanks!

EDIT: Also, going to try swapping victors for the Talons.

Re: Issue with Talons
 

I'd like to add that my team has experienced the same problems... No idea how to fix them.

Re: Issue with Talons
 

Here's what we have already tried and some additional info:
We tried turning the robot off and back on. Sometimes this fixed it, other times it didn't, and the problem would intermittently come back after varying amounts of time.
All 3 lights on the digital side car are on.
The observed effect is that the robot is commanded to move forward (and only forward) and it starts out doing so, then pulses a turn to the left, then continues on its way forward.
This happens only when the talon is commanded to go in the green direction. It does not occur in the red direction (or we have yet to observe it).
All 4 of the talons are in coast mode.

Re: Issue with Talons
 

A brief twitch in reverse can be a sign that the robot is getting disabled for a moment. If the PWM signal is interrupted for just the right amount of time, it is possible for the speed controller to misinterpret the interruption as a valid command. Look at the Diagnostics tab of the Driver Station and see if there are any helpful error messages.

Re: Issue with Talons
 

Have you tried calibrating the Talons?

Re: Issue with Talons
 

Make sure you do these one at a time. This way if the issue gets resolved after swapping one thing, you can trace the problem to a specific item.

Re: Issue with Talons
 

I would interpret the LED change as a sign that the PWM signal did in fact change state. However, I would like to see Mike C weigh in on this.

Re: Issue with Talons
 

Yeah, we have calibrated them.

Re: Issue with Talons
 

After printing out the voltage values being sent to the talons to the console, we found nothing that suggests the PWM is changing direction. This leads us to believe it is something other than the code and likely down stream from the cRio causing the PWM signal to flip the other way for an instant.

Re: Issue with Talons
 

Last year we had something similar happen to us.
Observing the PWM output from the Digital Sidecar with an oscilloscope revealed that the PWM signal was dropping out occasionally. Replacing the DSC fixed the problem.
My $.02.

Re: Issue with Talons
 

Our digital sidecar this year had a problem with DIO Channel 7 not working, I wonder if there was a problem with the production of the sidecars this year that is causing some of these problems.

Re: Issue with Talons
 

We have had a host of problems with the DSC, and had to replace three of them last season. I would definitely look at testing with a new DSC.

Re: Issue with Talons
 

Also take a look at the ribbon cable from the cRIO to the DSC, especially if you are using one that required repair from last year. Dodgy connections on the ribbon cable can cause strange behaviors.

Re: Issue with Talons
 

I don't have any issues with either the design or reliability of the DSC. It's just that it's such a swarf magnet. You really have to be careful working around them.

Re: Issue with Talons
 

We too seem to be having an issue like this.

The problem is noted as a drive train twitch. We're using the default drive code (tank) without any modifications.

The issue is experienced with the Talons; however, we're only using the PWM interface with the Talons. All other motor drivers are connected using the CAN bus.

No one is near the controls when this occurs. It is just a brief twitch. I'm a bit worried reading this because we haven't had a good chance to run the robot much yet.

I looked at the schematic for the Digital Sidecar, and I'm not seeing how it can be an intermittent problem with the DSC.

Link for the schematic can be found here.

The PWM signals originate directly from the NI 9403, so the DS isn't actually supplying the PWM signals. There are three 'chips' that touch the PWM signal.

1. A 10K pullup resistor used for a disconnected DSC. Resistors don't intermittently fail. However, a cold solder joint might cause an intermittent connection; however, this would only affect the system IF AND ONLY IF the 32-pin cable becomes disconnected.
2. A disable chip. There is a chip, in line, with the PWM signals. This relies on a signal defined as OUTPUT_EN. If this signal toggles while sending a NEUTRAL PWM signal to the speed controllers, this could cause the speed controllers to 'twitch.' However, the OUTPUT_EN line should remain HIGH while the robot is ENABLED.
3. A current limiting resistor. It's placed between the disable chip and the actual output. Again, resistors don't intermittently fail, and the only issue I can imagine is a bad soldering job.

Just going on a wild hunch... How many of you experiencing this issue are using the home-made DSC cable that connects your DSC to the NI 9403? It's possible that there is an intermittent or high resistance (bad connection) pin that is causing this issue. Looking at the pinout, OUTPUT_EN is DIO_21 on the NI 9403. First, try a different (real) cable. I don't see much failing in the DSC, so I'm pointing my finger at the cables right now.

Re: Issue with Talons
 

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.

Re: Issue with Talons
 

When we put our practice chassis together we had a "twitch" in our system too. We were not sending any commands to the DSC but the Talons signal light would blink and the motors would move for a brief moment. We switched to a different DSC and the problem went away. Opening up the DSC revealed that one of the chips had let out it's magic smoke. It was one that had been used in the past not a new unit, so it is hard to say when or why it occurred.

Re: Issue with Talons
 

Our team have noticed random glitches from the drivetrain over the past few years, while no input was being sent, the drive motors would move just enough to make an audible noise, but not move the wheels.
We use Jaguars connected via PWM.

**edit**
Forgot to add, we are also using the round cable from the kop 2 years ago.

Re: Issue with Talons
 

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.

Re: Issue with Talons
 

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.

Re: Issue with Talons
 

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.

Re: Issue with Talons
 

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

Re: Issue with Talons
 

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

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.

Re: Issue with Talons
 

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...

Re: Issue with Talons
 

At times like this, guesswork and shotgun replacment of parts only takes you so far. Now it's time to take a more analytical approach utilizing test equipment that can reveal the true source of the problem.
I would set those items aside for now and put them up on the bench for serious troubleshooting after ship date.

Re: Issue with Talons
 

Carl,
Is the twitching taking place when the robot is enabled or when you start to drive? Are you able to drive several minutes on one battery without the problem reoccurring?

Re: Issue with Talons
 

To take Al's point further; Have you ruled out a power supply issue to the DSC?

If you are getting mixed results through swaptronics it is time to perform a more focused assessment of the problem.

I would take a serious look at how the problem is reproduced, isolate the components instead of focusing on the system as a whole. Take a single motor controller and pair it with a DSC, PD and Cable on a bench off of the robot. Make every attempt to reproduce the issue. Paying very close attention to the steps being followed and what action cause the erroneous behavior.

Once you are able to deterministic-ally reproduce the problem, then and only then will you be able to take the necessary steps to solving it.

Having said that, if the problem is intermittent finding how to reproduce it can be very difficult. But it is still important to attempt to due so and avoid creation of causal relationships that may not have anything to do with the actual problem.

Break the problem down to it's basic elements. From a hardware standpoint:

What needs to happen for me to make a motor move?

- Motor controller and DSC must have proper power.
- Motor controller must receive a constant, uninterrupted(<100ms) PWM signal
- Digital module on cRIO must be able to provide and uninterrupted non intermittent signal to the DSC.

You must also be able to rule out specific components such as the motor controller itself. The easiest way to do this is provide the PWM signal to the Talon using a secondary form of communication such as a VEX controller or a simple PWM generator or an RC hobby controller. Once you have ruled out the MC, you need to move on to the other components such as the DSC.

Testing the DSC is a little more difficult and requires you to know a little about how it works. But there is a simple test that you can do. If the problem is the DSC it is possible that it is only with one or two channels, try switching the PWM signal to a different channel. Remember that there is a separate driver IC for PWM channels 9 and 10 than there is for 1-8 http://www.usfirst.org/uploadedFiles...matic%20v7.pdf. Sometimes this IC fails or has intermittent issues that could be the cause of your problem.

All of these tests requisite that you are able to reproduce the problem. If you cannot reproduce the problem then you have no way to validate your corrective measures.

Now there is always the possibility that your problem is software. Try loading the default code and performing a simple PWM assignment from a joystick to a PWM channel. Try reproducing the issue on every channel. Compare these results against the actions taken to reproduce the problem.

Following a methodical and step by step approach is the only way you are going to be able to pinpoint the problem and say with any reasonable degree of certainty that you have fixed it.

Try the code
 

I've had this same issue before but it was with the Jaguars. I ended up programming in the holonomic instead of arcade which seemed to solve it. It seems you may be having a similar issue best of luck and hope things go well.

Re: Issue with Talons
 

Do you have two single acting solenoids available? Attach one to a solenoid breakout and the other to a relay. Turn them both on all the time. If both actuate when the talons reverse, the issue is that everything is getting disabled. If only the relay one is actuating, it points to a problem with the enable signal in the digital module or digital sidecar. If nether actuate, it's something specific to PWM signals.