Announcement

Collapse
No announcement yet.

Turning Code

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • CoachZM
    started a topic Turning Code

    Turning Code

    We are utilizing the IMU on the Expansion Hub to turn. We have our speeds turned down pretty low so it can go back and forth to find the correct position without shooting past it. However, at tournaments we see some of these teams turning very quickly and very accurately. Because of this we are wondering if we are missing something with our code and how to turn. Any suggestions or tips on how you guys are turning?

  • jkenney
    replied
    In fact, the robot does reach its target heading, even using pure proportionate control, as we do. It wouldn't, if there were continuous instantaneous updating of speeds (i.e., no delay between successive gyro readings and no rotational inertia to overcome in changing rotation speed). But there is a delay between successive new gyro readings, and it takes some time to slow the rotational speed down after a new reading because of rotational inertia. With a sufficiently high proportionate constant, the target is reached quickly. Setting the proportionate constant too high results in some undesired oscillation. We just experimented to find a happy medium, that gets to our tolerance range (usually we require +/-2 degrees) quickly.

    Leave a comment:


  • 11343_Mentor
    replied
    We are using REV. If you are reaching the heading of your product, then you are not using the PID concept in a true fashion. It should not work. We have found that we need to add a power value of .04 to move the motors. Using empirical values as an example, let's say you are going to turn 90 degrees. We use a factor of .01, so the initial proportional power is .9, but at 3 degrees left to turn the motor applied power is 3*.01 = .03, below the base threshold, so the turn stops 3 degrees before completing the turn. Using a formula of ((turn angle difference X.01) +.04) = applied power works effectively

    Leave a comment:


  • 4634 Programmer
    replied
    Originally posted by 11343_Mentor View Post
    We are using RUN_USING_ENCODER. It will not consistently reach your desired heading without adding a slight amount of power.
    Are you using MR or REV? Either way, upping the I coefficient should help with that, but I can't understand why you're having problems with the default tuning - even if I is very small, it will eventually ramp up enough to reach the target.

    Leave a comment:


  • 11343_Mentor
    replied
    We are using RUN_USING_ENCODER. It will not consistently reach your desired heading without adding a slight amount of power.

    Leave a comment:


  • 4634 Programmer
    replied
    Originally posted by 11343_Mentor View Post
    To add to the discussion, keep in mind that you must also add a slight amount of power to the product of your error*factor multiplication, otherwise you will not reach the IMU heading on turns. You can determine the optimal value by trial and error. Too much added power and you will get overshoot, too little and it either won't reach your desired heading or it will be too slow to reach the heading. Also remember the Rev IMU uses +180 and -180 for left and right respectively.
    Incorrect, at least when using RUN_USING_ENCODER mode. The PID velocity control will always be able to move no matter how low the power value.

    Leave a comment:


  • 11343_Mentor
    replied
    To add to the discussion, keep in mind that you must also add a slight amount of power to the product of your error*factor multiplication, otherwise you will not reach the IMU heading on turns. You can determine the optimal value by trial and error. Too much added power and you will get overshoot, too little and it either won't reach your desired heading or it will be too slow to reach the heading. Also remember the Rev IMU uses +180 and -180 for left and right respectively.

    Leave a comment:


  • 4634 Programmer
    replied
    Originally posted by Cheer4FTC View Post
    4634 Programmer Thanks much!
    No problem

    Also by the way, in case you're interested, the way I implemented the extra glyph detection was by using a combination of beam break sensors and current monitoring (which is a hidden feature of the Expansion Hub). This summer I created the REV Extensions 2 library which allows access to this feature and many others.

    Leave a comment:


  • Cheer4FTC
    replied
    4634 Programmer Thanks much!

    Leave a comment:


  • 4634 Programmer
    replied
    Originally posted by Cheer4FTC View Post
    what mode of motor operation were you using for the drive motors?
    I was using RUN_USING_ENCODER

    Originally posted by Cheer4FTC View Post
    And then you just set the motor power to some value proportional to the gyro heading error?
    Yep

    Originally posted by Cheer4FTC View Post
    Are you also using the gyro during your driving/strafing to keep the alignment? Is there any code you can share for this?
    Yes, and sure. Here's my function for gyro-assisted strafing:

    Code:
    public double gyroStrafe(double pow, double target, double Kp)
    {
        double err = getHeading() - target;
        MotorPowers motorPowers = HolonomicStandard.calcStrafePows(pow);
        motorPowers.add(err*Kp, -err*Kp);
        driveTrain.setMotorPowers(motorPowers);
        return err;
    }

    Leave a comment:


  • Cheer4FTC
    replied
    4634 Programmer can you elaborate on what you mean by a "P-controller feeding into the Expansion Hub's PID velocity control"? Specifically what mode of motor operation were you using for the drive motors (USING_ENCODERS or RUN_TO_POSITION)? And then you just set the motor power to some value proportional to the gyro heading error? Are you also using the gyro during your driving/strafing to keep the alignment? Is there any code you can share for this? Thanks much for any additional detail you can provide.

    Leave a comment:


  • 4634 Programmer
    replied
    Last year I had our auto doing beautiful 180 turns very fast with nothing more than a P-controller feeding into the Expansion Hub's PID velocity control. Here's a link to a video (we're in blue2, also please ignore the jewel arm failure lol)

    Leave a comment:


  • zain
    replied
    This depends on a lot of factors, and I have always tried to keep my students within the bounds of the math they know and not let them download cookbook code examples. So, when they are using the IMU for fast turns to heading, what the do is something along the lines of:

    Turn_mix = K1*heading_error_vs_desired - K2*angular_velocity.

    This produces a PD servo that is both easy to understand and generally really stable. K1 is how hard the robot yaws per degree of heading error. And this can be made large to the point of overshoot and oscillation. But, K2 slows things back down such that the robot doesn

    Leave a comment:


  • DanOelkeFTA
    replied
    You can do something in your code where as you get closer to the target you decrease the power to motors - this is a proportional control. (That is the P in PID.) I've found that this is often good enough.

    They may also not be using the IMU. Instead you can use the RUN_TO_POSITION and just set the left wheel to go forward so far and the right to go backward. With a little math or experimentation you can calculate how much distance is how many degrees of turning.

    Leave a comment:

Working...
X