Hi,
We currently have a simple drive train running, a single motor connected to a black jag on each side, and we ran into a problem that we’re having difficulty diagnosing. The robot ran fine when up on blocks. We put it on the floor and only one side ran. We swapped the PWM cables on the digital sidecar and the other side ran but the side that originally ran stopped running. It’s as if pin 1 is outputting a signal, but not pin 2. We swapped out the DS and for a short time (first few seconds) both sides ran fine. Then the same thing happened. I just realized we haven’t changed out the ribbon cable, which I will do first thing when we get to the shop. All the lights on both DS’s were strong, and the robot signal light was as expected.
Other ideas?
I am a new electronics mentor, but I don’t have an electronics background. I do have a virtual mentor who has been EXTREMELY helpful but she is not always available right when we have a problem, so I’m putting this out to CD. I need to understand the general process to go through when diagnosing electronics issues on the robot. I’m an engineer by training, but have not practiced engineering for 20 years. I can follow technical advice, but I’ve never used an oscilloscope. Thinking I probably need to figure that out.
Can someone give me a general run down on how they approach electronics troubleshooting?
Also, how do I check whether a ribbon cable is good, beyond swapping it out and seeing that a different one behaves as expected?
I can’t give you much technical advice, but I can explain how our team, at least, troubleshoots electronics problems.
Our general rule of thumb:
We always swap out one part at a time, until we can locate the source of the problem, if that doesnt work, then it must be the code.
For your problem specifically, I would suggest a) put it back up on blocks to see if it runs on them consistently, and b) try swapping out the PWM cable that goes to the “bad” side with a completely different PWM. Since the DS must be working correctly, according to your post, then the problem may be that the signal isn’t getting carried from there to the JAguar.
It seems to me that the problem must be a PWM cable issue since you indicated that you swapped the PWM cable and the side that wasn’t originally working started to work. I would suggest trying a different PWM cable completely on a different port on the DS. In addition, from reading on CD, I’ve noticed that many teams have experienced issues with the ribbon cable that connects the DS to the cRio. Maybe instead of using the ribbon cable, you can try using the beige bulky cable (sorry im not sure what its called but it looks like a VGA cable with the screws at the end and more pins). Also, maybe you might want to check out if its the jaguar itself.
When our team troubleshoots electronics, we try to ensure that its not a programming error first (if possible), that way we dont have to change the electronics around to find out that we unnecessarily had to remove/change pieces and waste time. Make sure your team is downloading the correct code into the robot and there are no build errors. If that doesn’t work, then I agree with dmitch above ^. Swap one part at a time to try and isolate the problem. Start with cables and connectors first before proceeding to entirely new pieces.
Hope I helped a little. Keep us updated with your efforts and any new problems, I’m glad to try and provide some assistance.
How are you controlling the robot during the tests? If you are using a driver station are you sure that is working correctly? Try this, change your code to have the joysticks on the drive station control two things. For example, when the right side of the drive train moves forward have the code output a PWM signal and turn on a spike or some other device that you can use to verify that the code is really getting commands. You can use this to verify that the code is really getting the right input and is executing the way you expect.
Once you verify that your driver station input is working, change the code to output multiple PWM signals, so that you can check for a bad digital sidecar. For example, lets say that the right side motor is connected to PWM 1 and the left side to PWM 2, have the code also output the right side to PWM 3, and the Left side to PWM 4. You can then swap PWM cables to more locations. If one PWM output works, but it pair does not you may have a bad DS or bad cable. If they are all bad you might have a software or driver station problem.
One area to check is the PWM cable and how it plugs into the motor controller. This connection can be flaky. To insure that you know for sure that a PWM signal is coming from the DS, plug a hobby servo into the questionable PWM port. You will need to add a jumper to the two pind next to that port to power a servo. If the servo responds but the controller does not, you know that the problem is not in the DS, code, or other wiring from the CRIO.
Again, make one change at a time, but trust nothing. Work back from the simplest configuration you can and test every component separately. Hobby servos are a great teat device for this type of PWM debugging.
al,
PWM cables do go bad and that is what you symptoms suggest. However, it is also possible for a DSC to power up (or appear to power up) with just the ribbon connected. Check that all three LEDs on the DSC are “on” bright. This will only occur if you supply power to the DSC as required.
Thanks for the posts. I did read them yesterday at the shop when troubleshooting this problem.
The problem was a bad ribbon cable. We swapped it out with a DB37 cable and that resolved the initial problem.
I was unclear when I initially posted about switching the two sides. We switched position at the DS, which would indicate a problem upstream of the PWM cables.
So the new cable resolved the initial problem, then we had a new problem to consider.
Once we got both sides running, we noticed a difference in speed between the two sides. Originally I thought that it was due to motor or gear box differences but decided to switch the PWM cables again (at the DS), to see if that effected anything. And I was a bit surprised to see that it did!
Originally side A was running faster than side B. When we unplugged side A from pin 1 on the DS and side B from pin 2, and plugged side A into pin 2 and B into pin 1, then side B ran faster than side A. It’s as if Pin 1 is outputting a greater signal than Pin 2. What would cause this??? Again, all lights on the DS are bright, including the light for the robot indicator light.
We are just using the default code for C++ on this bot. The programmers are using a different test bed right now.
In either case, when driving the bot it was easy enough to compensate for the difference, but we’ll be adding encoders next and will have to implement some feedback to get it to drive straight during autonomous.
AGain, thanks very much for taking time to respond. I appreciate it.
What programming language are you using? How are you defining/opening/initializing the two motor outputs? You need to make sure the software matches the hardware. For example, if you tell the code you’re using a Victor or a Talon but connect to a Jaguar, your motor will be slower than if you correctly specified a Jaguar in the program.
Ann,
Motors do have a speed bias although with the CIM motors this has been pretty small. The bias gives motors a little higher speed in one direction than the other. Since you are running the motors in different directions on each side, you are likely experiencing this bias. Many teams figure out the bias difference and then compensate in software by modifying the value sent to each speed controller.
Since you’re seeing the “fast” motor change from one side of the robot to the other when you swap PWM connections, I don’t see how it could be motor bias.
How does your program send values to the drive motors? If you’re using tank-style control, is one of your joysticks perhaps giving less range than the other? If you’re using arcade-style control, is there a slight offset from zero in the steering axis?
