Driving Straight Error

[raptaconehs]

Hey guys. So we have had this problem with driving straight for a little while, but it appears to be getting worse and worse. Our bot is the kit of parts chassis, which is wired with encoders, as well as a gyro. When ever we attempt to go straight the bot veers to one side, and doesn't veer to the same side all the time.

When we run the robot at half of the max speed, the bot drifts towards the left. Here is video of the robot doing this.
https://www.youtube.com/watch?v=Yn5b...ature=youtu.be

When we run the robot at full speed, the bot starts to veer to the right. Here is video of the robot going at full speed.
https://www.youtube.com/watch?v=nQDE...ature=youtu.be

In both videos, we have used code to eliminate getting the x-axis values on the joystick and to solely move forward. We were wondering if any teams had this problem, and if anyone knows how to possibly correct this. Any help is appreciated.

[EricH]

Does it behave this way when the encoders and/or the gyro are removed from the system, by code or other means? Mechanically, it should track pretty straight even without the sensors--at least, it should only go one way.

Are your speed controllers calibrated? It sounds like on one side, you're getting more power at half throttle, but the other gets more power at full--but I suspect that isn't the whole story.

Are there signs of wear, or debris, in one or both gearboxes? That might be jamming you up a little bit.

[raptaconehs]

The bot behaves this way regardless of the sensors on the bot. Currently we aren't doing much with the sensors. We are trying to use the sensors to allow for us to drive straight. The speed controllers that are in use are the Talons and were just calibrated. We don't think there is anything wrong with the gearboxes as they seem to sound fine when we are running them, I will see if we can get anyone to look into that in our next meeting, but could the gearboxes be the reason for this shift in direction of drift after a certain point?

[EricH]

Originally Posted by raptaconehs

We don't think there is anything wrong with the gearboxes as they seem to sound fine when we are running them, I will see if we can get anyone to look into that in our next meeting, but could the gearboxes be the reason for this shift in direction of drift after a certain point?

I doubt it, but if you got something in there that was jostling just right, maybe.


I wonder... Check your speed controller output values in code. I'm thinking that maybe one of the motors might be getting an abnormally low value at full throttle, which would cause a draggy motor on that side. That would put the remaining motor working hard to overcome both the motor and the system...


Or maybe your joysticks need calibration.

[raptaconehs]

Originally Posted by EricH

I doubt it, but if you got something in there that was jostling just right, maybe.


I wonder... Check your speed controller output values in code. I'm thinking that maybe one of the motors might be getting an abnormally low value at full throttle, which would cause a draggy motor on that side. That would put the remaining motor working hard to overcome both the motor and the system...


Or maybe your joysticks need calibration.

The problem is we have had this issue on the competition bot from last year as well as this year's practice bot during the fall. It could be a motor, do you have any ideas on how we could quickly check if there is a draggy motor? And we use a X-Box controller to drive. Does it need to be calibrated? If so how?

[orangemoore]

What if you write a simple autonomous program that has the robot drive straight forward. If it drives straight it is likely a controller problem, but if its pulling its likely the robot itself.

[Greg McKaskle]

Since you have encoders, can you plot them over time? I'd be curious how much difference there is under different conditions. In particular, how much difference is there when the robot is up on blocks? Does the half joystick and full joystick bias persist or does the behavior change?

Looking at the videos, in the half-speed one, the robot's acceleration is minor and the robot stays level. In the full-speed one, the robot accelerates hard. The weight rocks the robot on its back wheels, and that seems to be when it veers right. It doesn't look like a constant arc.

So another test would be to ramp the motor values more slowly. See if that sheds some light.

Greg McKaskle

[raptaconehs]

Originally Posted by EricH

I doubt it, but if you got something in there that was jostling just right, maybe.


I wonder... Check your speed controller output values in code. I'm thinking that maybe one of the motors might be getting an abnormally low value at full throttle, which would cause a draggy motor on that side. That would put the remaining motor working hard to overcome both the motor and the system...


Or maybe your joysticks need calibration.

Originally Posted by orangemoore

What if you write a simple autonomous program that has the robot drive straight forward. If it drives straight it is likely a controller problem, but if its pulling its likely the robot itself.

Just double checked, and in the videos posted, we were using a program that drove the motors at a set speed. This speed is read from the SmartDashboard.

Originally Posted by Greg McKaskle

Since you have encoders, can you plot them over time? I'd be curious how much difference there is under different conditions. In particular, how much difference is there when the robot is up on blocks? Does the half joystick and full joystick bias persist or does the behavior change?

Looking at the videos, in the half-speed one, the robot's acceleration is minor and the robot stays level. In the full-speed one, the robot accelerates hard. The weight rocks the robot on its back wheels, and that seems to be when it veers right. It doesn't look like a constant arc.

So another test would be to ramp the motor values more slowly. See if that sheds some light.

Greg McKaskle

We also did some more tests with the robot on the block. Using the same program, we ran the robot for ten seconds. After ten seconds, here are the encoder values:

Speed:  .5    Left encoder:  7282     Right Encoder:  7591
Speed:  .6    Left encoder: 11546     Right Encoder: 11435
Speed:  .7    Left encoder: 16531     Right Encoder: 17083
Speed:  .8    Left encoder: 20538     Right Encoder: 21263
Speed:  .9    Left encoder: 25814     Right Encoder: 26199
Speed: 1.0    Left encoder: 32812     Right Encoder: 33366

[wireties]

FYI, the motors can be +/- 10% off the published power curves. Simply sending the same values to the Talon/Victor/Jaguars will rarely make the robot drive perfectly straight. If you have encoders, feed them to the PID controller class to implement a velocity servo. The wheels will reach the same velocity eventually but might drive a little crooked while accelerating because one side accelerates faster than the other. You can compensate with 'P' constants.

Some teams add accelerometers and gyros feedback and help to drive straight and execute precise turns.

HTH

[Ether]

Originally Posted by wireties

FYI, the motors can be +/- 10% off the published power curves.

Does that +/- 10% apply to the power curve? Or is that the tolerance for the free speed?

[Tem1514 Mentor]

Something else to consider is that the motors spin in different directions to cause motion either forward or backwards.

The CIM motors are very close in speed when run full CW and full CCW but there is always difference which account for you encoder numbers.

Try running the robot at full speed in a circle and record results.

[aldaeron]

If I read your post correctly - the signal for the Talons is being set via the smart dashboard instead of the controller, therefore you can rule out the controller.

I would unhook the gyro and comment out any code that refers to it.

As a general rule for troubleshooting: you want to start from a known good state and add things back in until you find the problem. In your case this means getting two motors working such that the robot drives straight and then add Talons and motors back in until you get 4 motors driving straight.

Some troubleshooting step I would look into:
- Are the transmissions greased properly and equally? Does one have a lot more old yucky grease?
- Are the gears inside each transmission identical? We have had different gearings in "identical" transmissions before. Same goes for any belts idlers or chain sprockets. We had a bot where the left and right chain sprockets attached to the gearbox were different tooth counts so it always moved left.
- Can you spin the gearboxes by hand with approximately the same force without motors while on blocks?
- When on blocks and set to coast - if you go from 100% power to 0% power do the wheels stop at about the same time?
- Are all the motors and controllers the same vintage (i.e. is one motor re-used from 2013)?

What encoders are you using?

Did you calibrate the Talons on blocks on the actual robot or calibrate them on a different electronics setup and then add them to the chassis?

Are the PWM cables in good shape and making good contact?

Have you tried other PWM ports on the Digital Sidecar? I have seen a few CD posts where the PWM ports weren't working properly (though this is rare).

With the robot on blocks - are the Voltages on the outputs of the Talons very close to each other?

If you still still see errors start switching components (Talons and Motors) one at a time and take careful notes of what was changed and whether the robot went straight, right or left. Theoretically when you swap the underperforming Motor or Talon from left to right it will drift the other way. This is easier to do with a single motor on each side. If you have motors A,B,C,D and Talons 1,2,3,4 try something like:

Talon 1 with Motor A on the left and Talon 2 with Motor B on the right, then
Talon 1 with Motor B on the left and Talon 2 with Motor A on the right,
etc.
until you find out which Talon or Motor is not playing nicely.

We have had a few hiccups using Talons for the first time this year but eventually sorted them out.

Drive up and visit us in Denver Tuesday if you're still having trouble. We still owe you for setting up such a great off-season event.

-matto-

[raptaconehs]

Originally Posted by aldaeron

If I read your post correctly - the signal for the Talons is being set via the smart dashboard instead of the controller, therefore you can rule out the controller.

That was my thoughts exactly.

Originally Posted by aldaeron

I would unhook the gyro and comment out any code that refers to it.

In the videos, we commented out the gyro code, but the gyro was still attached. Would that affect the driving?

Originally Posted by aldaeron

- Are the transmissions greased properly and equally? Does one have a lot more old yucky grease?

They are greased properly.

Originally Posted by aldaeron

- Are the gears inside each transmission identical?

Yes.

Originally Posted by aldaeron

- Can you spin the gearboxes by hand with approximately the same force without motors while on blocks?

Yes.

Originally Posted by aldaeron

- When on blocks and set to coast - if you go from 100% power to 0% power do the wheels stop at about the same time?

In the videos, the Talons were set on break mode, but when set on coast, the wheels do stop at about the same time.

Originally Posted by aldaeron

- Are all the motors and controllers the same vintage (i.e. is one motor re-used from 2013)?

Unfortunately, we didn't document when we got the motors, so I'm not sure if they are the same vintage. However, the labels on the CIMs are different. There's a picture of it attached.

Originally Posted by aldaeron

What encoders are you using?

We are using: US Digital E4P-250-250-N-S-D-D-B encoder (am-0174)

Originally Posted by aldaeron

Did you calibrate the Talons on blocks on the actual robot or calibrate them on a different electronics setup and then add them to the chassis?

We calibrated the Talons on the actual robot.

Originally Posted by aldaeron

Are the PWM cables in good shape and making good contact?

I've checked the cables, and they seem to be in good shape.

Originally Posted by aldaeron

With the robot on blocks - are the Voltages on the outputs of the Talons very close to each other?

Yes.

Originally Posted by Al Skierkiewicz

Rapta,
We don't really have enough info to pinpoint the exact cause. There are some variables that bite all teams in working on a straight auto mode. the fact that your robot turns one direction in full throttle and the other direction at less that full throttle seems to indicate an issue with the sensors. If you are using the common optical encoders on the transmissions, check that you have the encoder wheels matched and in a range for the speed that you expect. If the encoded output is very low in repitition rate, a random single error in count will grow over the distance the robot travels. If the count is too high, when you are at or near full throttle, the count may actually drop out. There is a maximum and minimum specification on these encoders. If both sides are identical and you believe the count (tach) is accurate, then the robot can only drift if there is slippage in the drive system downstream from the sensor. You should be able to get into some form of debug to watch the counts returned by the individual sensors to see if you software is actually trying to correct for the difference. Some transmissions that have a pickoff for a rotary encoder have slippage in the pickoff shaft.

The code related to the encoders was also commented out, so I don't think it would be the issue.

Originally Posted by tr6scott

Is it a two motor drive base, or a 4 motor drive base?

It is a 4 motor drive base.

Originally Posted by tr6scott

EDIT: Also make sure you have the correct motor controller in the begin.vi too.

We use Java to program the robot, and the talons are initiated via this code:

    Talon flTalon;
    Talon frTalon;
    Talon blTalon;
    Talon brTalon;
    
    /**
     * Create a new instance of the Drive class.
     */
    public Drive_Simple() {
        flTalon = new Talon(RobotMap.DRIVE_MODULE, RobotMap.FL_WHEEL);
        frTalon = new Talon(RobotMap.DRIVE_MODULE, RobotMap.FR_WHEEL);
        blTalon = new Talon(RobotMap.DRIVE_MODULE, RobotMap.BL_WHEEL);
        brTalon = new Talon(RobotMap.DRIVE_MODULE, RobotMap.BR_WHEEL);
        
        System.out.println("Module: "+ RobotMap.DRIVE_MODULE +" used for drive.");
        System.out.println("FL wheel at: "+ RobotMap.FL_WHEEL +" FR wheel at: "+ RobotMap.FR_WHEEL);
        System.out.println("BL wheel at: "+ RobotMap.BL_WHEEL +" BR wheel at: "+ RobotMap.BR_WHEEL);
        
        robotDrive = new RobotDrive(flTalon, blTalon, frTalon, brTalon);
(etc...)

Edit: Forgot to mention that we have tried using a PID that uses the gyro. Well, the P part of the PID acronym. Anyways, using the PID, the robot drives mostly straight. The P value isn't exact yet, though.

[aldaeron]

In the videos, we commented out the gyro code, but the gyro was still attached. Would that affect the driving?

There is no significant reason to electrically unhook it if you are sure all of the code is commented out. I have found that I thought all code related to a sensor was removed and there was some hidden code 3 levels deep. Unplugging the sensor makes sure the cRio is not using the sensor (and helps find hidden code relating to said sensor)

Unfortunately, we didn't document when we got the motors, so I'm not sure if they are the same vintage. However, the labels on the CIMs are different. There's a picture of it attached.

We typically write the year of purchase on the rear of the CIM case in sharpie. We have seen that after a full season some motors don't have the same power response to a given voltage as brand new motors.

Did you try swapping out PWM ports?

Did you read the drive voltages put out by the Talons?

Did you try driving with just 2 motors at a time (I realize this is time consuming to swap them in and out)?

Another (crazy) thought

Is your left-right weight distribution equal? Are your wheels making equal contact with the carpet? Are the wheels of approximately the same Coefficient of Friction (i.e. same material, same wear)? What I am getting at here is that for an identical power transmitted from each gearbox to the left and right side wheels - is there something causing a different force to be applied at the left and right sides? From the video this does not appear to be the case.

I am not surprised that a tuned (or almost tuned) PID fixes the problem. The PID will drive the error to 0 if tuned correctly by correcting the PWM signals. However, I don't think you want to be at the competition and have your driver press forward on the controller and get a non-forward motion.

-matto-

[wireties]

Originally Posted by Ether

Does that +/- 10% apply to the power curve? Or is that the tolerance for the free speed?

Good question - I have never seen a power-torque-speed curve with error bars along the entire curve. Your reference to the free speed tolerance comes from the web site. And my experience using the CIMs and similar low-cost motors is consistent with a 10% assumption for the stall torque as well. Do you think otherwise? Also, have you seen much difference rotating CW versus CCW?