Open four motors: Victor Problem

We have found a problem with the open four motors for the victor motor controllers. Whenever we use that vi, our motors will not run correctly. If we instantiated them as jaguars, they do. (by not working correctly, the sometimes stay at the last speed they were at and the safety config doesn’t kick in). Sometimes randomly it will give off a -44061 error code. I removed all unnecessary code, including all the camera stuff and even the periodic tasks and vision vi (from robot main). I still have this issue. We also tried new batteries and checked all of the connections. What are we doing wrong?

You say you checked “all the connections”, but you don’t say which those are.

For example, is your Digital Sidecar being powered from an output protected by a 20A breaker on the Power Distribution Board?

The power connection to the sidecar is connected with a 20 amp breaker. The pwm cables are in the correct ports with the signal inside. They are hooked up to the victors with the black cable oriented inwards. The victors do receive power and signal, but when the motors stick, the victors lose connection ( the ones that aren’t sticking start blinking).

Can you explain what ‘motors stick’ means?

Under what conditions do the motors “stick”? Can you reproduce it reliably? Does the system recover and work properly again, even if only temporarily?

When you say “stick”, what do you mean?

Here’s a stab in the dark: if you tell the robot to spin clockwise, does it break? If so, which motors “stick” and which ones lose signal? How about if you tell it to spin counterclockwise?

The motors “stick” at what seem to be random points, whether the robot is driving or standing still. We could reproduce it every test, but not by doing something. They just happened (but sometimes it did seem like moving the joystick caused it, but that was just because you can see it best in those situations).

Sorry! Stick is a term we like to use. Stick means the motor freezes at an output when it isn’t supposed to. Our victors would be either showing disconnected or driving the motors when the joystick was at a neutral state.

We are using the mecanum code, and all we do is pass the joystick axis values into the x, y, and rotation. Not sure what you mean by changing the spin?

You can reproduce it, but not by doing something? I don’t follow that at all. It sounds like it’s occurring at random, and there isn’t anything you can do to make it happen.

Sorry! Stick is a term we like to use. Stick means the motor freezes at an output when it isn’t supposed to.

A motor sticking/freezing seems like a mechanical issue. When it happens, can you turn the motor by hand (after disconnecting power, of course)?

Our victors would be either showing disconnected or driving the motors when the joystick was at a neutral state.

Wait, what? Can you verify that the joystick was indeed commanding neutral but the cRIO was telling the motors to move? Look at the Dashboard display to see what the joystick is being read as, and what the motor output PWM values are being set to. But I’m lost – I thought the problem was the motors freezing when they were supposed to be moving, not the other way around.

We are using the mecanum code, and all we do is pass the joystick axis values into the x, y, and rotation. Not sure what you mean by changing the spin?

Spin is the same thing as rotate. Command the robot to rotate to the left and see if the problem occurs more or less often. Then command it to rotate to the right.

Thanks for all the help, but we figured out the problem. For some reason, whenever a value grater than ~.25 was passed to the mecanum block (which, while being positive, is actually backwards), the robot would drop communication. We are simply placing a limit on the value being passed and that solves all the problems.

Unless you understand why this is happening you did not figure out the problem.

You put a band-aid on the problem.

You keep using ambiguous language, and it’s keeping me from helping you as much as I would like.

When you say “drop communication”, do you mean the Driver Station would lose contact with the robot and the “Communication” indicator would change from green to red? Or do you mean the Victors would start blinking to indicate no PWM signal?

If it’s just the Victors that are affected, then the symptom points to a specific cause: your Digital Sidecar is not receiving 12 volt power correctly.

Alan just trying to add my 2 cents that might help.

They said they are using the ‘mecanum code’. Does that code require the gyro to be installed and could that be causing the system to try and move without command input?

No gyro is required. That’s an optional input for field-centric control.

Their symptoms point to a power/wiring problem.
It’s hard to tell without teaching them to properly read the staus lights and messages.

Nope.

and could that be causing the system to try and move without command input?

Nope. Connecting the Gyro Angle input to the Mecanum drive block just permits a coordinate rotation on the X and Y joystick inputs, so “forward” will change based on the robot heading. Commanding no motion will still be no motion.

Drive motors will pull the most current on your robot.

I see you as having two problems.

  1. Resistance through the main power input to the PD Board

  2. Bridge converter is not plugged into the boosted 12V output.

  3. Driving the drive motors at 25% output shouldn’t drop the battery voltage enough to cause the 12V-to-5V converter to drop out. However, it doesn’t take much. Looking at AndyMark, the converter has a voltage input range from 10-30VDC. Having your battery voltage drop below 10V to cause the Dlink’s voltage supply to droop below 5V means you either have a loose connection, bad breaker, or a bad battery. This is assuming you’re using a charged battery.

  4. If you’re ever dropping connection because the Dlink resets, then you don’t have the 12V-to-5V converter plugged into the boosted 12V output.

Follow the steps on ScreenStepsLive.