[HELP] Motors Becoming Sentient


#1

After running our motors, all four of them start rotating one “tick” in a random direction every few seconds (as long as the robot is still on, obviously). What could be causing this?

We’re using Spark motor controllers and the Vex Pro motors that come with the KOP.

We recalibrated the motor controllers 17 times already (and each time our robot seems to drive faster afterwards…).


#2

Are these motors controlled by your joystick axis? If so, they may be outputting some small value when you aren’t touching them. You will want to add a deadband in this case when reading those values so they don’t control your motors when you don’t mean to.


#3

Oh no, the controller has a HUGE deadzone (though I believe it is actually due to the arcadeDrive function, not the controller itself).


#4

How do you know this other than moving the joysticks? Are you outputting the raw axis values to your dashboard to see if this is the case? Even then, they joystick still could be settling at a non-zero value despite a high deadzone.


#5

Is your speed controller firmware up-to-date?


#6

?


#7

It’s possible he is referring to the SPARK MAX controller…

http://www.revrobotics.com/sparkmax-software/#spark-max-firmware-updates

There have been updates to fix control issues similar to those described by the OP.


#8

It’s not the joystick. When I set an arcadeDrive function in autonomousPeriodic() to drive at 0.0 speed, the motors tick. When I comment out that function, the motors no longer tick.


#9

No. http://www.revrobotics.com/rev-11-1200/

Is there a firmware update for that, too?


#10

When you say ‘tick’, do you mean that they go on and off repeatedly? If so, you may be commanding the arcade drive somewhere else and the robot can be alternating between the two commands. Can you post your code so that we can better diagnose your issues?


#11

The best way to advise you would be to post your code so we can see if anything redundant is happening.

That said - assuming your test mode is otherwise empty of other code, does the same thing happen in testPeriodic when you call arcadeDrive(0,0)? What about when you individually set each motor (or group of motors) directly?


#12
@Override
  public void autonomousPeriodic() {
    switch (m_autoSelected) {
      case kCustomAuto:
        // Put custom auto code here
        break;
      case kDefaultAuto:
      default:
        robotDrive.arcadeDrive(0.0, 0.0);
        break;
    }
  }

If I remove one line of code and the behavior of the robot changes, that line of code is clearly the issue.


#13

Where else are you using arcadeDrive() in your code other than autonomousPeriodic()?


#14

teleopPeriodic(). But that is not even running. It has to be something in arcadeDrive that’s causing the problem. Right?


#15

Off topic…
I read this thread as “Mentors Becoming Sentient”.
While I’m happy to see people helping people, I was hoping for a good laugh on a Friday.


#16

I’d look for a duplicate command commanding the motors to zero somewhere else in your code.


#17

So if you control the robot using arcadeDrive() in teleopPeriodic() and then suddenly disable it, the robot will remember the last command it recieved and will try to read the last command given. With this year’s sandstorm period, you have manual control in autonomousPeriodic(), so yes it may be that the robot is trying to read both the joystick and the autonomous code (can’t really tell without seeing your teleop code and not really sure how WPI does the back end for autonomous this year). If you really wanted to disable the robot motors, you can set arcadeDrive(0,0) in disabledInit(), otherwise, you can try to remove that line in autoPeriodic() and try moving the robot with joysticks to see what happens.


#18

Plug the problem sparks into PWM ports that aren’t being used anywhere in your code, then operate anything else normally. If the motors still twitch, it’s an electrical noise issue. If the motors don’t twitch, it’s a problem in your code somewhere.


#19

This tends to happen when the motors are receiving a very small value from somewhere in the code. This may be caused elsewhere in your code from auto. Another thing to check would be to make sure your firmware on your controllers is up to date.


#20

Ah, fair enough.

Not that I have ever seen sadly…

Is the light on the spark max changing when you see the pulse? If no, I’d say there’s something wacky inside the motor controller.

If so, as others have suggested, maybe try a simple, brand new robot project that just always sets the motors to zero. If that doesn’t show any issues, the issue is probably somewhere in your code.

However, if the issue persist, I’d be looking to wiring. I wonder if there’s a chance if you have long wires running parllel to each other, if there’s sufficient cross-talk that you could induce a valid motor control signal? seems improbable though…