Drive Train Curves Only While Backing Up

[GeeTwo]

I concur. What do the outputs of 3, 4, and so forth look like? Whichever one disagrees with the others should be reserved for standalone (one controller) functions, not the drive train.

[Ozuru]

Originally Posted by GeeTwo

I concur. What do the outputs of 3, 4, and so forth look like? Whichever one disagrees with the others should be reserved for standalone (one controller) functions, not the drive train.

I'm not sure I understand what you mean, sorry. Are you referring to the individual motors themselves or do you mean the PWM ports?

[Alan Anderson]

I've seen strange discrepancies in drive motor response when the motors are cross-wired between a pair of speed controllers. It's probably not what you're seeing, but go ahead and double-check that each motor is properly wired to its single associated Talon.

Also double-check that your Talons are all the same variety. I didn't think the SR and non-SR models had different responses, but I know there are definitely differences between old and new Victors, so it's worth looking at.

[Jared Russell]

Those measurements are from the PWM port, right?

Can you post the full source code of the IterativeRobot test you just made?

[BitTwiddler]

Originally Posted by Ozuru

Thanks for all of the replies so far everyone.

I'm not there testing but have someone else testing. I'm going to be recalibrating them (and consequently posting here with my findings) sometime around 3 PM EST today. Maybe I'm interpreting the oscilloscope wrong -- here are the images I received. Linking to rather than embedding the pictures because they're massive.

Oscilloscope Reading #1
Oscilloscope Reading #2

The readings are from the PWM signals with the ports swapped running the very basic code below I wrote to confirm it wasn't a programming issue.

.

I see the difference in pulse widths which would make one side travel faster than the other. I'm betting this would be solved by recalibrating the controllers to the input values.

[GeeTwo]

Originally Posted by Ozuru

I'm not sure I understand what you mean, sorry. Are you referring to the individual motors themselves or do you mean the PWM ports?

The PWM ports. I was interested in what the variation in pulse width is across the various ports. If you've got variation, each subsystem with multiple controllers should use "matched" ports.

[GeeTwo]

Originally Posted by BitTwiddler

I see the difference in pulse widths which would make one side travel faster than the other. I'm betting this would be solved by recalibrating the controllers to the input values.

These pulse widths are being determined by the 'RIO, not the controllers.

[E Dawg]

We had exactly the same problem earlier in the season and it turned out to be the joysticks, so make sure it's not those. You can do this by watching the joystick outputs on the Dashboard. If that is the problem, you can easily fix it by putting in a bigger deadband.

[Ozuru]

Originally Posted by Jared Russell

Those measurements are from the PWM port, right?

Can you post the full source code of the IterativeRobot test you just made?

Correct -- the measurements are from the PWM port.

package org.usfirst.frc.team2559.robot;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.Talon;

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the IterativeRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the manifest file in the resource
 * directory.
 */
public class Robot extends IterativeRobot {
    /**
     * This function is run when the robot is first started up and should be
     * used for any initialization code.
     */
	
	Talon talon0 = new Talon(3);
	Talon talon1 = new Talon(4);
		
    public void robotInit() {
    	

    }

    /**
     * This function is called periodically during autonomous
     */
    public void autonomousPeriodic() {
    	talon0.set(-0.2);
    	talon1.set(0.2);
    }

    public void teleopInit() {
    }
    /**
     * This function is called periodically during operator control
     */
    public void teleopPeriodic() {
    	
    }
    
    /**
     * This function is called periodically during test mode
     */
    public void testPeriodic() {
    
    }
    
}

At this point, due to the discrepancies in the PWM readings, I'm medium-high confident that the issue is being caused by the RoboRIO itself and not motor controllers. At the moment I'm testing trying not splitting the PWM cables and declaring each motor individually and just doing RobotDrive.tankDrive().

Are those readings normal? Has anyone ever had this issue of the PWM signals having about a 200ms delay hooked up to an oscilloscope? Is this expected and does calibrating the talons somehow take care of this?

[Jared Russell]

This is expected behavior. -0.2 is represented by a different PWM pulsewidth than 0.2.

If you set both Talons to 0.2 or -0.2 simultaneously, I'd bet you see nearly identical pulses.

[Ozuru]

Originally Posted by Jared Russell

This is expected behavior. -0.2 is represented by a different PWM pulsewidth than 0.2.

If you set both Talons to 0.2 or -0.2 simultaneously, I'd bet you see nearly identical pulses.

I just changed the testing code to this now and the issue persists. Shouldn't this have fixed it?

package org.usfirst.frc.team2559.robot;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Talon;

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the IterativeRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the manifest file in the resource
 * directory.
 */
public class Robot extends IterativeRobot {
    /**
     * This function is run when the robot is first started up and should be
     * used for any initialization code.
     */
	
	Talon talonleft0 = new Talon(3);
	Talon talonleft1 = new Talon(4);
	Talon talonright0 = new Talon(5);
	Talon talonright1 = new Talon(6);
	RobotDrive rDrive;
		
    public void robotInit() {
    	rDrive = new RobotDrive(talonleft0, talonleft1, talonright0, talonright1);

    }

    /**
     * This function is called periodically during autonomous
     */
    public void autonomousPeriodic() {
    	rDrive.tankDrive(-0.4, -0.4);
    }

    public void teleopInit() {
    }
    /**
     * This function is called periodically during operator control
     */
    public void teleopPeriodic() {
    	
    }
    
    /**
     * This function is called periodically during test mode
     */
    public void testPeriodic() {
    
    }
    
}

[Jared Russell]

Originally Posted by Ozuru

I just changed the testing code to this now and the issue persists. Shouldn't this have fixed it?

package org.usfirst.frc.team2559.robot;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Talon;

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the IterativeRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the manifest file in the resource
 * directory.
 */
public class Robot extends IterativeRobot {
    /**
     * This function is run when the robot is first started up and should be
     * used for any initialization code.
     */
	
	Talon talonleft0 = new Talon(3);
	Talon talonleft1 = new Talon(4);
	Talon talonright0 = new Talon(5);
	Talon talonright1 = new Talon(6);
	RobotDrive rDrive;
		
    public void robotInit() {
    	rDrive = new RobotDrive(talonleft0, talonleft1, talonright0, talonright1);

    }

    /**
     * This function is called periodically during autonomous
     */
    public void autonomousPeriodic() {
    	rDrive.tankDrive(-0.4, -0.4);
    }

    public void teleopInit() {
    }
    /**
     * This function is called periodically during operator control
     */
    public void teleopPeriodic() {
    	
    }
    
    /**
     * This function is called periodically during test mode
     */
    public void testPeriodic() {
    
    }
    
}

RobotDrive by default inverts the command to your right side drive motors (the authors assumed you'd wire red to + on both sides), so calling tankDrive(-.4, -.4) actually sends -.4 and +.4 to your Talons.

tankDrive(-.4, .4) or visa versa should result in identical pulsewidths.

[Ozuru]

Originally Posted by Jared Russell

RobotDrive by default inverts the command to your right side drive motors (the authors assumed you'd wire red to + on both sides), so calling tankDrive(-.4, -.4) actually sends -.4 and +.4 to your Talons.

tankDrive(-.4, .4) or visa versa should result in identical pulsewidths.

Does this mean then that when going forwards (or backwards) one talon should be red and the other should be green?

I'm trying to calibrate the talons at the moment but they're simply flashing red (which means failure, according to the document). I'm pressing and holding them while going full throttle forward, going to neutral, and then going full throttle backwards, and then back to neutral. After that, I put them back into neutral. Is that how you guys usually do it?

[Ozuru]

Originally Posted by Ozuru

Does this mean then that when going forwards (or backwards) one talon should be red and the other should be green?

I'm trying to calibrate the talons at the moment but they're simply flashing red (which means failure, according to the document). I'm pressing and holding them while going full throttle forward, going to neutral, and then going full throttle backwards, and then back to neutral. After that, I put them back into neutral. Is that how you guys usually do it?

Disregard the calibration question. I figured it out -- only calibrate an individual talon at a time. That was my issue.

[Jared Russell]

Originally Posted by Ozuru

Does this mean then that when going forwards (or backwards) one talon should be red and the other should be green?

It depends on how you have the motors wired.

Normally, if you wire red to + on both the left and right side, you would expect to see one speed controller flash red while the other flashes green when driving forward (since you will have needed to invert one side in code because it is in the opposite physical orientation).

If you switch the motor leads on one side instead, you would NOT want to invert the command in code, and both sides would blink the same color.

Since there are two ways to invert each motor, it is easy to get confused. For this reason, I HIGHLY recommend NEVER inverting motors electrically...always do red to +, and invert in the code as necessary. This way, if you need to swap in a spare motor or speed controller, you never need to guess which way to wire it up because they are all always the same.