Problem with old bot

Was fixing up an old bot and encountered a weird problem. All directions work but when going backward the robot just stops responding and requires a disable-reenable to start moving again. It’s most probably an electrical problem and all other movements work fine so I have no clue what it could be. Anyone have any ideas?

Check each wire between a speed controller and a drive motor. One of them is likely shorted to the frame, and there is probably another frame connection elsewhere. The big things to worry about are the cRIO case and the Axis camera.

Your drive motors aren’t the biggest BaneBots, are they? Those are notorious for developing internal shorts between the case and one of the terminals, apparently due to debris left over from manufacturing.

How old, please?

lol, sorry about that guys. Once again I had sent a freshman to do research, and I can almost guarantee you that they didn’t search before posting (with my account).
But basically, we stripped the good 'ole 2010 robot and basically left the 4 CIM motors, the 4 mecanum wheels, the PD board, the cRIO, and the DS. It’s all mounted on wood and the other parts (such as relays) are still mounted, just not connected to anything.
That being said, we can go forward, left, right, and spin properly, but once we go backward, the bot essentially stops working. I expected it to be motorsafety to be throwing it off, but alas, the freshman didn’t do enough asking or researching and they assumed it to be electrical, because 224’s programmers are never wrong XD. I’d also like to throw in that the joysticks and motorspeeds are programmatically correct, but i haven’t had them check motorsafety yet.
However, I dare not eliminate electrical as the problem YET. I will make note to them to make sure that the robot is properly grounded.
Are there any other suggestions?
Thanks

Yeah, neither are ours. :rolleyes:

I would go through the wires very carefully, looking for shorts and the like. However, since all the wheels work independently and the bot only crashes when they all drive backwards, I’d say it’s safe to blame code. I can’t think of any other reason that would cause the bot to act like that.

What does “properly grounded” mean to you? Absolutely nothing should be electrically connected to the frame of the robot, either accidentally or intentionally.

What speed controllers? if victors, are they calibrated right?

if jags, PWM, serial CAN, or 2CAN?

also, if known, what programming language?

King,
Jaguars (old Tan color) were notorious for failing in one direction that year. When you say that the robot stops functioning, are you saying that the Crio reboots or the robot simply will not go in reverse? Are you using dual motor transmissions? If so are you absolutely sure of the wiring to each motor? It is possible that one of the motors is wired backwards. When you reverse you suddenly add a short (both motors go into stall) drawing upwards of 200 amps. Although unlikely, it is possible for the motors to be able to drive in one direction but not at full speed. Of course if you add a defective Jag that is open in forward but functions normally in reverse, this result is possible. I suggest you remove the wiring to one motor on each side and see if the robot moves in both directions. Note which direction the wheels turn for a forward movement on the joysticks. Then swap motors on both sides and try again. Do the motors cause the same direction of movement as the first test? I have also seen debris in a transmission that allows movement in one direction but locks the transmission in the other direction. You should be able to simulate this without power, moving the robot by hand.

Did you test on the floor or on blocks (or both)?

You said you can spin. With the mecanum wheels that sounds like the wheels can spin backwards, but not when the joystick tells it to go backwards. I would think code, but there could be a joystick short

Check the C-rio, we just had a problem with our 2011 bot that sounds alot like yours, we think that it was a combination of inflicted damage and a slightly defective unit. Try swapping the rio out with a different one and see if that fixes it.

well, everything is mounted on wood and whatever isn’t used isn’t connected to the PD board
Furthermore, we put a multimeter to the frame and got a reading of 0.0

I’m starting to think that too, but motorsafety isn’t throwing any errors and everythings SEEMS to be fine in terms of code. all it is is creating a robotdrive, joystick, and driving via inputs from joystick

Victors
what do you mean by “calibrated right”
and we are using Java

we are using Victors and i THINK single transmissions
the cRIO doesn’t reboot upon failing
i’ll check everything else you’ve said, thanks!

Both

can’t be the joystick because we tried our xbox and an older joystick

its a relatively new cRIO (we bought it a while ago, but it was only for show on a testboard that we later stripped), but I’ll have the team replace it

Would that be a reading of 0.0 ohms = bad or 0.0 volts = good? A value without units is meaningless.

The lack of units has already been mentioned, but I have another question.
You put a multimeter to the frame and what? If both probes were on the frame, the resistance would be 0.0, or close to 0.0, as would the voltage (due to the fact that the resistance is 0). The proper way to test for electrical continuity problems is to , with the meter set to measure in kOhms, place one probe on the frame while the other one is placed on the cRIO chassis, the back of the axis camera, motor controller outputs, and the PD board inputs (Make sure the robot is off, or preferably, the battery is out of the robot. ). If the meter displays infinity (usually a 1 at the far left of the display) in all cases described above, but 0.0 when the probes make contact with each other, then the electrical system is likely not shorted to the frame.

My advice would be to spend more time debugging. Since the cRIO is modular, replacing the whole thing shouldn’t be necessary in most cases. Spend a bit more time debugging and you can spend less swapping components in and out and winding up with a pile of parts that “may” be bad.

I’d start with the SW or HW split. If you have diagnostic errors due to watchdog timeouts or other configuration issues, fix those first. If the SW is not producing any errors, trace the pwm values to see if the SW is setting them to zero.

From there, if the SW is setting the correct values, but the SW isn’t responding, you can isolate the speed controller, digital sidecar, and digital module.

Greg McKaskle

we did do a decent amount of software testing and a little of electrical.
We printed out voltages and wheel speed ratio (-1 to 1) values and then tested voltages on each victors. they all turned out to be pretty accurate
not sure what you mean by the “setting them to zero part”

I apologize, it was volts. I had no idea ohms would also play a factor
and as for how we did it, the way I was taught was by putting the positive on the frame and the negative on a ground port (the V- on a victor to be exact).
I will check the other things you’ve said once we get off of break

Sorry about that. It was 0.0 volts

King,
We should have mentioned that you must have a good power supply to the digital sidecar. Teams are often confused when they see a few lights on the sidecar and think it has power. There should be three LEDs indicating good power coming in, a solid 5 volts and six volts from internal supply/regulators. Finally, a solid LED next to the robot signal light connector indicates that the robot is enabled.

Al, If the DS power supply was intermittent (it obviously can’t be missing, since the Victors do operate) how would that generate the problem?

Another problem that you may be having is Victor failure - and yes, Victors do fail, however much I’d hate to admit it. Of course, as mentioned earlier, it could also be a programming problem. First, watch the Victor LEDs. One side should be turning green and the other should be turning red while going forwards (if this isn’t the case, then testing the lights will be ineffective), and while attempting to go backwards, you should see a color reversal - one side red, the other side green.

If that color reversal does not happen, then the problem falls into one of two cases. One - if the colors both turn to solid yellow, then you’ve most likely got a programming problem, because that means the backwards drive command isn’t getting to the Victors, although it is possible to have an electrical problem. Two - if the colors go out, either it has been calibrated incorrectly (pull up the Victor datasheet to see what I’m talking about) or the signal going to the Victor has been changed, either in programming or through a short.

If the color reversal does happen, then it’s possible the problem lies within the Victor itself. Turn off the robot and reverse the motor leads on each Victor (i.e. in each Victor-motor connection, swap the red and black motor leads on the Victor). This will electrically flip your controls, so that driving forward will move you backward, and vice versa. If you can’t move forward, then the problem - as absurd as it may seem - is most likely your Victor itself, because it confirms that your motors are capable of driving the robot backward, and that the Victor is receiving the signal, but not transferring it to the drive motors.

Also, I’d advise turning the robot off and checking with resistance to measure continuity. I’ve never been a fan of playing with a live robot, especially one with a short.

If the Digital Sidecar 12VDC power input is missing, the Victors can indeed still work. There’s enough leakage from the 37-pin connection to the cRIO to give the appearance of things functioning. But as soon as you tell enough of the PWM signals to go “reverse”, the average voltage drops and things can quit.

I’m out of practice. Based on the clues in the initial description, checking the DS power should have been my first suggestion. Measure the power input on the white Wago connector and verify that it’s getting battery voltage. Make sure that that BAT, 6V, and 5V LEDs are all fully lit.

The colors go out when going in full reverse so yeah. I’ll double check the programming whenever I have access to the computer but we have checked it a few times and I have no clue what else it could be. We even tried disabling motor safety(risky I know) and there was no change in what happened. I’ll double check for shorts and also the Digital Sidecar like Al said. If only it were convenient enough that things lighting up meant they were working lol.