Driving Straight Error

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

[Ether]

Originally Posted by wireties

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]

Originally Posted by Ether

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]

Originally Posted by wireties

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]

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-

[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 differential drive" 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]

Originally Posted by Nate Laverdure

Somebody should implement "dual differential drive" 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?