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

[Chris_Elston]

Originally Posted by raptaconehs

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.

When I was mentoring software, I always every year have to remind them about the mechanical limits of the robot.

For example. When at 100%, your output to your speed controller is +1 or 255 in the old IFI days. If both motors are at 100% and you have a PID loop running or sometimes just a P loop, your math might be positive and trying to command the speed controller over 1.0+ or over 255. Which it can't do. So I always suggest to my programmers to put an upper limit if they are using a P loop of about 80-90% the setpoint. This way you have 20-10% of the top end of the speed controller to make an adjustment to the robot.

The above method I described above is using a P loop with only a Gyro. We even use the same in FLL. A simple P loop to start with. The Joystick would change the "desired" Gyro degrees. The Desired speed is slower than the max of the robot.

I dunno if this helps or is your problem, but something to check with your math in your control code to make sure you aren't trying to compute a speed controller output if you don't have that range to output.

[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-

[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.

[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?