Twitchy Motors

[hwu24110]

So we have another problem with the roborio (the connection issue is fixed). I noticed that the motors twitch, regardless if it is a Talon SR or VIctor SP. We have tried another schools Talon SRs and PWMs, it still twitches, so I think it may be an issue with the wiring or the physical roborio. It is not a shortage since the electronics board is mounted on a wooden board and the only wires touching the metal frame are the motor wires and the battery cables, which I am fairly sure is not causing the issue.

[pribusin]

What programming language?

Is it possible you're addressing motors from more than one area in your program? It's a favorite mistake I find with my students. They forget that somewhere else in the program a motor is set to 0 and in another part they're trying to run it at some speed. Causes motor twitch.

[hwu24110]

I am using Java. There are only four lines of codes that tell the motors to do something.

LF.set(-stickL.getRawAxis(1));
LR.set(-stickL.getRawAxis(1));
RF.set(stickR.getRawAxis(1));
RR.set(stickR.getRawAxis(1));

I can determine these are the only lines of code that make the motors move by commenting them out. When I do that, the talons blink orange.

[Lireal]

It sounds like it is something wrong with the joystick. What joystick are you using? You should be able to recalibrate your joystick to fix it.

[nighterfighter]

Put the robot up on some blocks of wood, and change your teleop code to this:

LF.set(-1.0);
LR.set(-1.0);
RF.set(1.0);
RR.set(1.0);

That will rule out the joysticks being a problem. I'd also double check all your code, just to be sure.

[Dan Waxman]

Check the battery voltage. Sometimes with brownout protection the wheels will be a bit twitchy.

[Tom Line]

We've seen the same behavior from victor sp's in past years. Our best guess is that they can be sensitive to noise on the PWM wire. Are your PWM wires running along side power wires?

[evanperryg]

We've seen the same behavior from victor sp's in past years. Our best guess is that they can be sensitive to noise on the PWM wire. Are your PWM wires running along side power wires?

Interesting, with a digital line like PWM, noise shouldn't be a big deal unless it's really, REALLY bad. Hopefully OP comes back with a response soon cause I'm genuinely curious. The only thing that hasn't been mentioned is the faint possibility that both motor controllers are incorrectly calibrated, but it is still feasible.

[Mark McLeod]

Need more description of the symptoms.
For all we know the drive motors are wired into 30amp breakers, rather than 40a breakers.

[hwu24110]

I have tried setting each motor to a value of 0 and it still twitches.

I do not have the robot in front of me to confirm the breakers.

We've calibrated the victors and talons multiple times. I don't think we're calibrating it incorrectly.

[scca229]

I have tried setting each motor to a value of 0 and it still twitches.

I do not have the robot in front of me to confirm the breakers.

We've calibrated the victors and talons multiple times. I don't think we're calibrating it incorrectly.

Since you mention different types of motor controllers, are the correct motor controller types being initialized for each of them in the code?

[hwu24110]

Yes, I had made sure of that.

[Mark McLeod]

Perhaps photos of your wiring setup would help identify additional potential problems/solutions.

P.S.
I do have a rookie team describing motor controller twitching, too, but they always have the robot apart when I've been visiting so I haven't been able to diagnose it yet.

[nighterfighter]

You could also post all of your code, that will help us make sure something isn't inadvertently happening.

[Omer Huly]

so I think it may be an issue with the wiring or the physical roborio.

We had a twitching talon SR... we managed to solve this by connecting the talon to another PWM port.
Since we are getting a strange error in the driver station about PWM (something like PWM 0FRC in some WPIlib).

[hwu24110]

These are the images

http://i68.tinypic.com/4t0xmr.jpg

http://i63.tinypic.com/2j2w08h.jpg

http://i65.tinypic.com/3166dz9.jpg

http://i67.tinypic.com/30kdils.jpg

http://i63.tinypic.com/2hezqs1.jpg

Those are 40 Amp breakers

[nighterfighter]

The wiring looks correct to me (except for your lack of CAN). Does not having the roboRIO connected to the PDP cause any watchdog errors? Not sure...

Anyway, you could try 4 different PWM ports to see if maybe those ports are bad.

Also if you post your code we can rule out the code being an issue.

[Mark McLeod]

The wiring looks good to me too.

Take a look at the Driver Station Log File after these twitches occur.
To see if the Event List or the graphs show unusual behavior.

[nighterfighter]

The new radio is 12V, the old radio is 5V.

Edit: Weird, I got an email saying a new post said that the voltage should be changed. Ignore this post I guess

Edit2: Also, when youre testing, do you have the robot up on blocks, so the wheels arent touching the ground? Its possible that they are drawing too much current.

[hwu24110]

We do prop it on blocks when we test it.

I swapped the PWM ports to 4, 5, 6, and 7 and it still twitches.


package org.usfirst.frc.team988.robot;


import edu.wpi.first.wpilibj.SampleRobot;
import edu.wpi.first.wpilibj.Talon;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.Timer;
import edu.wpi.first.wpilibj.Victor;
import edu.wpi.first.wpilibj.smartdashboard.SendableChoos er;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboar d;

public class Robot extends SampleRobot {
Joystick stickL;
Joystick stickR;
final String defaultAuto = "Default";
final String customAuto = "My Auto";
SendableChooser chooser;
Talon LF;
Talon RF;
Talon LR;
Talon RR;

public Robot() {
stickL = new Joystick(0);
stickR = new Joystick(1);
LF = new Talon(4);
RF = new Talon(5);
LR = new Talon(6);
RR = new Talon(7);

}

public void robotInit() {
chooser = new SendableChooser();
chooser.addDefault("Default Auto", defaultAuto);
chooser.addObject("My Auto", customAuto);
SmartDashboard.putData("Auto modes", chooser);
}

public void autonomous() {

String autoSelected = (String) chooser.getSelected();
// String autoSelected = SmartDashboard.getString("Auto Selector", defaultAuto);
System.out.println("Auto selected: " + autoSelected);

switch(autoSelected) {
case customAuto:
break;
case defaultAuto:
default:
break;
}
}

public void operatorControl() {
LF.setSafetyEnabled(true);
LR.setSafetyEnabled(true);
RF.setSafetyEnabled(true);
RR.setSafetyEnabled(true);
while (isOperatorControl() && isEnabled()) {
LF.set(-stickL.getRawAxis(1));
LR.set(-stickL.getRawAxis(1));
RF.set(stickR.getRawAxis(1));
RR.set(stickR.getRawAxis(1));
Timer.delay(0.005); // wait for a motor update time
}
}

/**
* Runs during test mode
*/
public void test() {
}
}

[hwu24110]

I do not know if anything is out of the ordinary for the event logs since I don't know what to look for. Is there anything that would be a big sign something is wrong?

[JamesCH95]

Check main power connections and battery/battery voltage.

(didn't read the whole thread, this has been the cause of many a twitchy motor though...)

[nighterfighter]

The code looks correct also, only thing I can think of is instead of doing GetRawAxis(1), try getY(), but that shouldn't make a difference.

You said that you tried just setting their value to a constant? 0 or 1, and it still twitched? If it twitches with a value at 1, it could be a power issue, but if it twitches at 0, that sounds like a roboRIO issue.

Make sure there are no metal shavings in the PWM ports on the roboRIO.

Last thing I would try, hook up another Talon and put a new motor on it. Unplug the other Talons and comment them out. See if it twitches with just one Talon/motor.

[hwu24110]

I set it to a value of 0 and we've ran the vacuum over it a few times already.

[nighterfighter]

Hm. Do the motors twitch if the joysticks are unplugged?

Also I would try reimaging the roboRIO.

[Chris_Ely]

You have a really long wire run between the battery and the PDB. This will cause a significant voltage drop under load. You should keep your wire runs as short as possible. This may or may not be causing the twitchy motor issue, but it could cause problems for you in the future.

Can you post a driver station log of the battery voltage for when the twitching occurs?

[hwu24110]

The motors do twitch when the joysticks are unplugged.

We have tried reimaging the roborio multiple times already.

Where can I find the driver station logs?

[Chris_Ely]

Where can I find the driver station logs?
This article (https://wpilib.screenstepslive.com/s/4485/m/24192/l/144980-driver-station-log-file-viewer) explains how to view the logs. They are under the Diagnostics tab in the driver's station.
Just post a screenshot of one of the graphs.

[evanperryg]

You have a really long wire run between the battery and the PDB. This will cause a significant voltage drop under load. You should keep your wire runs as short as possible. This may or may not be causing the twitchy motor issue, but it could cause problems for you in the future.

Can you post a driver station log of the battery voltage for when the twitching occurs?

Line resistance on a 5ft line of 22AWG PWM signal wire is about 0.08 ohms, and considering OP's cables don't even look that long, line resistance is most likely not a factor here. OP, If those are custom made cables, I'd suggest you check your terminals for faulty crimps. It's easy to mess those up. Also, try adding in your CAN runs between the PCM, rRio and PDP. It's far-fetched, especially considering the rRIO has little more than a terminating resistor for the CAN line, but I wonder if this could be a factor. Also, your breaker power runs are ridiculously long, try cutting those down, a lot.

[philso]

Do you have a PWM Generator such as the AndyMark ThriftyThrottle? You can use something like that to totally eliminate the RoboRio and the software from the equation. People who fly model airplanes or helicopters often have something like this too.

http://www.andymark.com/Thrifty-Throttle-p/am-2936a.htm

[Chris_Ely]

Line resistance on a 5ft line of 22AWG PWM signal wire is about 0.08 ohms, and considering OP's cables don't even look that long, line resistance is most likely not a factor here. OP, If those are custom made cables, I'd suggest you check your terminals for faulty crimps. It's easy to mess those up. Also, try adding in your CAN runs between the PCM, rRio and PDP. It's far-fetched, especially considering the rRIO has little more than a terminating resistor for the CAN line, but I wonder if this could be a factor. Also, your breaker power runs are ridiculously long, try cutting those down, a lot.

I am not talking about the PWM cables, I am talking about the ~10ft of 6AWG power wire from the battery to the PDB - like you mentioned at the end of you post.

[ratdude747]

I am not talking about the PWM cables, I am talking about the ~10ft of 6AWG power wire from the battery to the PDB - like you mentioned at the end of you post.

Seconded. I wouldn't run long feed cables like that unless I had to. At least tie them up so they're not flapping in the breeze (at least in the one picture it looked to be catching a wheel :ahh: ).

[JB987]

Pretty sure his team left the power wires long knowing that this is just a test board and they will shorten them to fit the final configuration of their electronics...;) We'll take a look at it when his team visits us again this weekend.

[hwu24110]

http://i66.tinypic.com/ot12qc.png

[JamesCH95]

Voltage dropping that low in such a 'spikey' shape screams main power issue or battery issue.

[hwu24110]

http://i67.tinypic.com/4zvs6p.jpg

I swapped out the battery cables for shorter ones and switched out the battery. I still experience twitching.

[JamesCH95]

What terminals are you using for the 6awg connections?
Is there any wiggle in any of the 6awg connections?
Is there any wiggle in any of the PCM/robot controller hookups?
Have you run a load test on any of your batteries? (like a battery beak)

[hwu24110]

The terminals are labelled Burndy 6 Str Cu Blue Die 374 or 7.

I don't feel any wiggle from the 6 AWG connections

I don't feel any wiggle from the robot controller connections either

We don't have a battery beak.

[nighterfighter]

Personally, I don't think the batteries are the cause of the twitchy motors, mainly because they are twitching even when the code is set to give them a value of 0. That leads me to think there is either a short in the PWM wires, causing it to send a false signal to the Talon, or the roboRIO is malfunctioning.

That being said, having loose connections aren't good. And the voltage drop isn't "good", but 9 volts won't shutdown everything.

hwu24110: Could you take a video of the motors twitching, with the joysticks unplugged and the code having the motors set to 0? If you could also get the video of the Talons that would be helpful.

[hwu24110]

https://www.youtube.com/watch?v=nj-J5XceoW0&feature=youtu.be

I note that when one side moved, it would always move in that direction. The other side of the robot when it twitches moves in the other direction.

[nighterfighter]

Is your driver station showing any errors?

Is your PDP hooked up to the CAN? It seems like it isn't hooked up because the lights are flashing on it.

Do you have any non PWM speed controllers you can test? (So a Talon SRX, and test it over CAN)

[hwu24110]

THe only error that is showing up is that there isn't a controller connected

Today I hooked up the PDP to a PCM that is connected to the Roborio (The team wanted to test pneumatics). I can take photos of it tomorrow if you suspect there is something wrong with the wiring.

I have a few Jaguar Controllers but I have no experience with CAN wires.

[andrewb1999]

We have also been experiencing the same twitching motors problem lately. We do not think it is an issue with the electronics as it does not twitch when the robot is enabled in autonomous. We are going to check the joysticks tomorrow and see if that could be the issue for us.

[scca229]

After watching the video, I would swear that you are running into the same issue that our bot was last year that I posted in this thread:

http://www.chiefdelphi.com/forums/showthread.php?t=134694

Our issue is only when using PWM 0 (very bad) and 1 (not bad, but still present). Moving to 2 & 3, the issue cleared up. Our random fires were even in Disabled mode and sometimes lasting for 3 or 4 seconds at a time. Just for fun today, we tested the wiring this year using PWM 0 & 1 and the problem is still present with all new wiring/motors/controllers/code.

As a side, I'm assuming that your 4 motors are really 2 sets of 2 motors. Wouldn't you want to use a Y-cable on each pair so that they are getting the same signal at the same time and just calling them LEFT and RIGHT (or similar) in the code?

[hwu24110]

I've already tried swapping the ports 0, 1, 2, and 3 with 4, 5, 6, and 7.

As this was a test board, I didn't feel like scrounging around the PWM bin for Y cables. If you feel like that is the issue, I might try it out tomorrow.

[scca229]

I've already tried swapping the ports 0, 1, 2, and 3 with 4, 5, 6, and 7.

As this was a test board, I didn't feel like scrounging around the PWM bin for Y cables. If you feel like that is the issue, I might try it out tomorrow.

Forgot that was a test board when I mentioned the Y-cables.

Before swapping out for Y-cables, have you tried removing 3 of the existing ones and seeing if the issue is still occurring? Only have one connected at a time and see if you can narrow down the specific cable/port/controller combination that triggers the condition? The video only shows one side of the drive train twitching so I'm not sure if the other side is doing it as well like ours was.

[nighterfighter]

In addition to what Nate said:

This only occurs when the robot is enabled, correct?

Another thing you could try, although I imagine it will have no effect, is try switching languages to C++ and see if the problem still occurs. Just use the default example code and see if it twitches.

[hwu24110]

Both sides twitch. I removed all but one PWM for each talon and each talon individually twitches.

I set it to autonomous and found it didn't twitch. I set each motor value to 0 and found it still didn't twitch. To make sure I coded it right, I set one side to a value of 1 and it moved constantly at full speed while the other side didn't move at all.

It only twitches when enabled in TeloOp.

[hwu24110]

Huh. Well I switched C++ and slightly modified the code (someone should check if I entered the motor ports correctly) and the motors didn't twitch.

#include "WPILib.h"

/**
* This is a demo program showing the use of the RobotDrive class.
* The SampleRobot class is the base of a robot application that will automatically call your
* Autonomous and OperatorControl methods at the right time as controlled by the switches on
* the driver station or the field controls.
*
* WARNING: While it may look like a good choice to use for your code if you're inexperienced,
* don't. Unless you know what you are doing, complex code will be much more difficult under
* this system. Use IterativeRobot or Command-Based instead if you're new.
*/
class Robot: public SampleRobot
{
RobotDrive myRobot; // robot drive system
Joystick stick; // only joystick
SendableChooser *chooser;
const std::string autoNameDefault = "Default";
const std::string autoNameCustom = "My Auto";

public:
Robot() :
myRobot(4, 5, 6, 7), // these must be initialized in the same order
stick(0), // as they are declared above.
chooser()
{
//Note SmartDashboard is not initialized here, wait until RobotInit to make SmartDashboard calls
myRobot.SetExpiration(0.1);
}

void RobotInit()
{
chooser = new SendableChooser();
chooser->AddDefault(autoNameDefault, (void*)&autoNameDefault);
chooser->AddObject(autoNameCustom, (void*)&autoNameCustom);
SmartDashboard::PutData("Auto Modes", chooser);
}

/**
* This autonomous (along with the chooser code above) shows how to select between different autonomous modes
* using the dashboard. The sendable chooser code works with the Java SmartDashboard. If you prefer the LabVIEW
* Dashboard, remove all of the chooser code and uncomment the GetString line to get the auto name from the text box
* below the Gyro
*
* You can add additional auto modes by adding additional comparisons to the if-else structure below with additional strings.
* If using the SendableChooser make sure to add them to the chooser code above as well.
*/
void Autonomous()
{
std::string autoSelected = *((std::string*)chooser->GetSelected());
//std::string autoSelected = SmartDashboard::GetString("Auto Selector", autoNameDefault);
std::cout << "Auto selected: " << autoSelected << std::endl;

if(autoSelected == autoNameCustom){
//Custom Auto goes here
std::cout << "Running custom Autonomous" << std::endl;
myRobot.SetSafetyEnabled(false);
myRobot.Drive(-0.5, 1.0); // spin at half speed
Wait(2.0); // for 2 seconds
myRobot.Drive(0.0, 0.0); // stop robot
} else {
//Default Auto goes here
std::cout << "Running default Autonomous" << std::endl;
myRobot.SetSafetyEnabled(false);
myRobot.Drive(-0.5, 0.0); // drive forwards half speed
Wait(2.0); // for 2 seconds
myRobot.Drive(0.0, 0.0); // stop robot
}

}

/**
* Runs the motors with arcade steering.
*/
void OperatorControl()
{
myRobot.SetSafetyEnabled(true);
while (IsOperatorControl() && IsEnabled())
{
myRobot.ArcadeDrive(stick); // drive with arcade style (use right stick)
Wait(0.005); // wait for a motor update time
}
}

/**
* Runs during test mode
*/
void Test()
{
}
};

START_ROBOT_CLASS(Robot)

[nighterfighter]

That C++ code is correct, and if it didn't twitch then the problem seems to be with Java.

Do you have the latest updates and everything installed for Java/WPILib?

[philso]

Both sides twitch. I removed all but one PWM for each talon and each talon individually twitches.

I set it to autonomous and found it didn't twitch. I set each motor value to 0 and found it still didn't twitch. To make sure I coded it right, I set one side to a value of 1 and it moved constantly at full speed while the other side didn't move at all.

It only twitches when enabled in TeloOp.

It seems that your hardware is probably Okay. What you have posted above makes me think that it is the VALUES that you are sending to the motor controllers that may be the problem. Can you log the values sent to the motor controller or display them on your driver station?

Do you have any dead-band in your software so that the joysticks must move a significant amount before the system responds? I did not notice any mention of dead-band in this thread yet. In Auto-mode, dead-band is not an issue since the software should be ignoring your joysticks. Perhaps set your dead-band to some large value to see what effect it has.

[hwu24110]

I can't check the firmware version because the web dashboard is showing a white screen. (If I remember correctly, the version number is 3.0.0f0)

My eclipse plugins versions are now updated to 0.1.0.201602112135.

When I image the roborio I use the FRC_roboRIO_2016_v19.zip image.

The JRE is ARMv7 Linux - VFP, SOftFP ABI, Little Endian^2.

Since I updated the eclipse plugins, I now have this message in the driver station:

ERROR 1 PWM 7... Output not updated often enough. java.lang.Thread.run(Thread.java:745)
ERROR 1 PWM 6... Output not updated often enough. java.lang.Thread.run(Thread.java:745)
ERROR 1 PWM 5... Output not updated often enough. java.lang.Thread.run(Thread.java:745)
ERROR 1 PWM 4... Output not updated often enough. java.lang.Thread.run(Thread.java:745)

[hwu24110]

I do not have any dead band. Earlier I tested it by setting the values to 0 and it still twitched, so i don't think it's the controllers.

http://i63.tinypic.com/vhaqzc.png

I unplugged the controller so it wouldn't receive any input.

[philso]

You need some dead-band. It allows your system to ignore the noise that you will invariably have coming out of your joysticks. Do a search on this forum for how to properly implement the dead-band.

[hwu24110]

I've implemented a deadband, but it still twitches.

public void operatorControl() {
LF.setSafetyEnabled(true);
LR.setSafetyEnabled(true);
RF.setSafetyEnabled(true);
RR.setSafetyEnabled(true);
while (isOperatorControl() && isEnabled()) {
LF.set(-deadband(stickL.getRawAxis(1)));
LR.set(-deadband(stickL.getRawAxis(1)));
RF.set(deadband(stickR.getRawAxis(1)));
RR.set(deadband(stickR.getRawAxis(1)));
C.setClosedLoopControl(true);
if(controller.getRawButton(5)){
D.set(DoubleSolenoid.Value.kForward);
}
else if(controller.getRawButton(6)){
D.set(DoubleSolenoid.Value.kReverse);
}
Timer.delay(0.005); // wait for a motor update times
}
}

public double deadband(double JoystickValue) {
double deadbandreturn = 0;
if(Math.abs(JoystickValue)<.2){
return 0;
}
else {
deadbandreturn = JoystickValue;
}
return deadbandreturn;

[JamesCH95]

Have you tried switching out the joystick or game pad?

[hwu24110]

Yes, I've swapped between an xbox controller and two Logitech Extreme 3D Pro joysticks. I don't think it's the controller because I've also tried running it without controllers and it still twitches.

[nighterfighter]

In your Java code, you are addressing each Talon individually, and it is causing the motors to Twitch.

In the C++ code, the motors are NOT twitching, when you are calling the ArcadeDrive method.

Try addressing each talon in C++ and see if it twitches.

Try this code and see if it twitches:

#include "WPILib.h"

/**
* This is a demo program showing the use of the RobotDrive class.
* The SampleRobot class is the base of a robot application that will automatically call your
* Autonomous and OperatorControl methods at the right time as controlled by the switches on
* the driver station or the field controls.
*
* WARNING: While it may look like a good choice to use for your code if you're inexperienced,
* don't. Unless you know what you are doing, complex code will be much more difficult under
* this system. Use IterativeRobot or Command-Based instead if you're new.
*/
class Robot: public SampleRobot
{

Joystick stick; // left joystick
Joystick stick2; //right joystick
Talon left1;
Talon left2;
Talon right1;
Talon right2;

public:
Robot() :

stick(0),
stick2(1),
left1(4),
left2(5),
right1(6),
right2(7)

{

myRobot.SetExpiration(0.1);
}

void RobotInit()
{
}


void Autonomous()
{
left1.Set(0.0);
left2.Set(0.0);
right1.Set(0.0);
right2.Set(0.0);
}


void OperatorControl()
{
myRobot.SetSafetyEnabled(true);
while (IsOperatorControl() && IsEnabled())
{
left1.Set(stick.GetY());
left2.Set(stick2.GetY());
right1.Set(-stick2.GetY());
right2.Set(-stick2.GetY());

Wait(0.005);
}
}


void Test()
{
}
};

START_ROBOT_CLASS(Robot)

Test it in Autonomous mode (where it sets values of 0.0), TeleOp mode (where it reads the Y axis of each joystick) and Test mode (where it does nothing).

[hwu24110]

Neither time did it twitch.

I modified the code because you were using myrobot when it didn't exist.

#include "WPILib.h"

/**
* This is a demo program showing the use of the RobotDrive class.
* The SampleRobot class is the base of a robot application that will automatically call your
* Autonomous and OperatorControl methods at the right time as controlled by the switches on
* the driver station or the field controls.
*
* WARNING: While it may look like a good choice to use for your code if you're inexperienced,
* don't. Unless you know what you are doing, complex code will be much more difficult under
* this system. Use IterativeRobot or Command-Based instead if you're new.
*/
class Robot: public SampleRobot
{

Joystick stick; // left joystick
Joystick stick2; //right joystick
Talon left1;
Talon left2;
Talon right1;
Talon right2;

public:
Robot() :

stick(0),
stick2(1),
left1(4),
left2(5),
right1(6),
right2(7)

{

left1.SetExpiration(0.1);
left2.SetExpiration(0.1);
right1.SetExpiration(0.1);
right2.SetExpiration(0.1);
}

void RobotInit()
{
}


void Autonomous()
{
left1.Set(0.0);
left2.Set(0.0);
right1.Set(0.0);
right2.Set(0.0);
}


void OperatorControl()
{
left1.SetSafetyEnabled(true);
left2.SetSafetyEnabled(true);
right1.SetSafetyEnabled(true);
right2.SetSafetyEnabled(true);
while (IsOperatorControl() && IsEnabled())
{
left1.Set(stick.GetY());
left2.Set(stick2.GetY());
right1.Set(-stick2.GetY());
right2.Set(-stick2.GetY());

Wait(0.005);
}
}


void Test()
{
}
};

START_ROBOT_CLASS(Robot)

[hwu24110]

We found the solution. It was because we were missing motor.setExpiration(0.1)

public Robot() {
stickL = new Joystick(0);
stickR = new Joystick(1);
controller = new Joystick(2);
LF = new Talon(0);
RF = new Talon(3);
LR = new Talon(1);
RR = new Talon(4);
LF.setExpiration(0.1);
RF.setExpiration(0.1);
LR.setExpiration(0.1);
RR.setExpiration(0.1);

[jfox100]

http://i67.tinypic.com/4zvs6p.jpg

I swapped out the battery cables for shorter ones and switched out the battery. I still experience twitching.

You can sometimes get twitchy motors when you have a poor ground on a PWM cable. Try swapping out PWM cables. This would also explain some of the noise you show on the graph.

[nighterfighter]

First, sorry for leaving the myRobot object in there. I wrote the code at midnight, in Notepad.

Second, glad to hear you solved the problem. Kinda surprised it took all of us that long to figure it out, something as silly as a timeout.

Although I'm not sure why the motor would twitch with values of 0, even if the timeout was tripping like that.

[philso]

We found the solution. It was because we were missing motor.setExpiration(0.1)

public Robot() {
stickL = new Joystick(0);
stickR = new Joystick(1);
controller = new Joystick(2);
LF = new Talon(0);
RF = new Talon(3);
LR = new Talon(1);
RR = new Talon(4);
LF.setExpiration(0.1);
RF.setExpiration(0.1);
LR.setExpiration(0.1);
RR.setExpiration(0.1);

Just curious, what does "setExpiration" do? I am the electrical/systems guy so I rarely get to see the code even though I help troubleshoot it at the system level.

[Mark McLeod]

It's for the Safety and sets the maximum period or window within which a motor Set for that particular motor must be received to avoid automatic shutdown of the PWM output.

It's essentially to avoid a runaway robot if the code locks up, or gets blocked by a debugging session, after sending a full speed ahead command.

[G_rupp]

I do not have any dead band. Earlier I tested it by setting the values to 0 and it still twitched, so i don't think it's the controllers.

http://i63.tinypic.com/vhaqzc.png

I unplugged the controller so it wouldn't receive any input.

To help troubleshoot, the Log File viewer has different indicators for Events. In the 2 images of the Log File Viewer, there are a lot of yellow events displayed at the top of the window. Each of these is for an Event that occurred. If you float your mouse over any of the dots, it will show the message in the lower left window. If you click on the Event List, it will display all of the events that occurred. There may have been an error stating that the motor was not being updated in time.