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=Yn5bbWSXzis&feature=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=nQDEWFfYeXs&feature=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]

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]

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]

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]

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.

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.

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]

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]

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?

[Ginto8]

My team has had issues with poorly calibrated speed controllers. If you unplug the speed controller's output, power off, press and hold the calibration button (the location varies with the controller type), then power on, go neutral, full one direction, full the other, neutral, and release the button, the speed controller will be recalibrated and should respond more as you expect.

For example: see page seven of the Talon user manual (http://www.crosstheroadelectronics.com/Talon_User_Manual_1_3.pdf).

[Ether]

my experience using the CIMs and similar low-cost motors is consistent with a 10% assumption for the stall torque as well

What was your test procedure for measuring the stall torque?

[wireties]

What was your test procedure for measuring the stall torque?


I enjoy your Socratic queries! We did some testing 10 years ago on the bigger CIMs (that used to come in the kits). We used a huge DC supply (bought at a TI auction) that provided the voltage/current data directly and pushed against a set of precision-ish metered spring-loaded bumpers (normally used to stop runaway granite stages running on linear motors). I'll look for the notes and data - no promises.

But are we reading more into this than necessary? The OEM tells us the variation of the free speed has 10% tolerance. The free speed number is the "right-most" point on both the torque-speed curve and the power curve. The torque-speed curve is generally very linear for a DC motor, I think we can agree on that. So at a minumum one can say the torque-speed curve can be off by 10% at one end-point. Even if the stall torque tolerance is better than 10% one can posit the entire curve is some significant percentage off - especially the second half of the curve (after the max power number and closer to the max eff number). So is the delta just the slope of the line or some parallel offset? Think about the possible sources of error. The resistance of the windings, the amount of iron in the stator alloy, the alignment of stator etc are all variable. Motors wound by the same machine using wire from the same reel and stators forged from the same lot of material are likely very similar - but we cannot count on this unless we match motors in an incoming QA effort. Is it not reasonable to assume the 10% applies to all points on both curves for a motor that costs $10 or so in large quantities from the OEM?

[tr6scott]

In the video, it appears the base is not loaded, just a drive base. When the bot is on on blocks, (or stilts if you are at TORC, still haven't figured that out) the motors see almost no load.

I would suggest doing the motor controller calibration, and weighting the bot to competition weight, and see if the issue is still present.

We just got our drive base running on Saturday, and a driver said the bot would not track straight, he was driving in "tank" mode. We switched to "Halo/Cheesy" mode where one stick drives both the left and right side at the same power, and the bot tracked straight sown the hall until we lost wifi.

It sounds like you are forcing the motor controllers to the same speed in code already, that is good.

But gathering encoder data on unloaded motors, is multiplying the error of the free speeds of the motor, but does not accurately test competition scenarios.

In FLL we would run all of our motors at unloaded 100% power and get the measure the free speeds of the motors. We would then pair motors that had the same unloaded top speeds for our drive lines. The FLL has a drive straight with encoders built into the 2 motor move block, but we found when we paid attention to these details the controller had less work to do. This resulted in less wobble in the nxt when driving straight. In FRC, we only do drive straight during autonomous, and use a gyro for compensation, not encoders.

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

In the 50% video, it seems to track to the left the whole time, in the 100% it looks like most of the error is generated during acceleration, and at the last 1/2 of the run it is driving straight, but just headed at the wall.

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

[Ether]

I enjoy your Socratic queries! We did some testing 10 years ago on the bigger CIMs (that used to come in the kits). We used a huge DC supply (bought at a TI auction) that provided the voltage/current data directly and pushed against a set of precision-ish metered spring-loaded bumpers (normally used to stop runaway granite stages running on linear motors). I'll look for the notes and data - no promises.

But are we reading more into this than necessary? The OEM tells us the variation of the free speed has 10% tolerance. The free speed number is the "right-most" point on both the torque-speed curve and the power curve. The torque-speed curve is generally very linear for a DC motor, I think we can agree on that. So at a minumum one can say the torque-speed curve can be off by 10% at one end-point. Even if the stall torque tolerance is better than 10% one can posit the entire curve is some significant percentage off - especially the second half of the curve (after the max power number and closer to the max eff number). So is the delta just the slope of the line or some parallel offset? Think about the possible sources of error. The resistance of the windings, the amount of iron in the stator alloy, the alignment of stator etc are all variable. Motors wound by the same machine using wire from the same reel and stators forged from the same lot of material are likely very similar - but we cannot count on this unless we match motors in an incoming QA effort. Is it not reasonable to assume the 10% applies to all points on both curves for a motor that costs $10 or so in large quantities from the OEM?

All valid points, as far as I can see*. I just haven't ever seen a manufacturer's spec for max power tolerance for these "modern day" CIMs.


* I do wonder if part of the tolerance on free speed might be due to non-linearity at that end of the curve.

[raptaconehs]

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.
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?
- Are the transmissions greased properly and equally? Does one have a lot more old yucky grease?
They are greased properly.
- Are the gears inside each transmission identical?
Yes.
- Can you spin the gearboxes by hand with approximately the same force without motors while on blocks?
Yes.
- 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.
- 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.

What encoders are you using?
We are using: US Digital E4P-250-250-N-S-D-D-B encoder (am-0174)
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.
Are the PWM cables in good shape and making good contact?
I've checked the cables, and they seem to be in good shape.
With the robot on blocks - are the Voltages on the outputs of the Talons very close to each other?
Yes.

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.

Is it a two motor drive base, or a 4 motor drive base?
It is a 4 motor drive base.
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-

[Al Skierkiewicz]

Guys,
I can't help but think we are not dealing with motor issues here. If the robot turns one direction at one throttle setting and different direction at full throttle something else is at work. Has anyone looked at how the robot drives in each direction for the same throttle values? If you have taken the encoders out of the drive software, then what is left? There has to be some difference, be it electrical loss or mechanical loss. Please search for my pictures of a damaged CIM here on CD. I have found over used motors (those used for extensive practice or demo and over heated) that had wires on the armature break off. This produces a significant change in operation but it follows at all throttle positions and does not vary with direction.

[Nate Laverdure]

Somebody should implement "dual (http://www.chiefdelphi.com/forums/showthread.php?t=65205) differential (http://groups.csail.mit.edu/drl/courses/cs54-2001s/dualdiff.html) drive (http://www.cs.rit.edu/~ats/plcr-2002-1/problems/2/drive.html)" in FRC.

[Racer26]

Things I'm noticing:

Those CIM motors all bear 217-2000 as their part number, meaning all four of them came from VexPro, meaning they're at most a little over a year old.

The batch numbers appear like there's 2 motors each from 2 different batches. No big deal as far as I would guess.

4343 DID notice on our 2nd AM14U (we bought a second one to try a different configuration), that the of the FR8ZZ-HEX bearings that came with it, at least 2 of them were defective and either out of round or missing a ball. Regardless of what was wrong, they did not spin true. They were causing binding issues and actually flexing the sideplates of the chassis as the gearbox was turned by hand before adding motors.

Perhaps your bearings are like ours and causing this issue?

[Racer26]

Somebody should implement "dual (http://www.chiefdelphi.com/forums/showthread.php?t=65205) differential (http://groups.csail.mit.edu/drl/courses/cs54-2001s/dualdiff.html) drive (http://www.cs.rit.edu/~ats/plcr-2002-1/problems/2/drive.html)" in FRC.

...Fancy. Seems heavy to implement in FRC-grade materials.

[Brandon Ha]

Could you give us some footage of the robot's electronics when running? Maybe it is some electrical error?