Announcement

Collapse
No announcement yet.

Tuning PID to 90 degrees

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

  • #16
    Originally posted by FTC8564 View Post
    Also, is it wise to reset the encoders each time after running the PID or should I leave it out?
    Since drivePID is relative, it makes no difference whether to reset encoders or not. The PidController class doesn't care. However, the way Modern Robotics controller resets the encoder is to change the motor mode to "STOP_AND_RESET_ENCODER" and you have to change it back to whatever mode it was in. At least from last year (don't know if it's true with this year's SDK), changing mode takes time. So I wouldn't reset the encoders.

    Comment


    • #17
      The FTC SDK does indicate that the MR motor controller sets the mode to RUN_WITHOUT_ENCODER after a STOP_AND_RESET_ENCODER. So you need to set it back to what you want.

      Comment


      • #18
        Originally posted by FTC7253 View Post
        The FTC SDK does indicate that the MR motor controller sets the mode to RUN_WITHOUT_ENCODER after a STOP_AND_RESET_ENCODER. So you need to set it back to what you want.
        2.3.5 and 2.4 javadoc states they don't know what's going to happen, so as above you do want to set the runmode to what you want, but you should do it even if you want run without encoder.

        -
        The motor is to set the current encoder position to zero. In contrast to RUN_TO_POSITION, the motor is not rotated in order to achieve this; rather, the current rotational position of the motor is simply reinterpreted as the new zero value. However, as a side effect of placing a motor in this mode, power is removed from the motor, causing it to stop, though it is unspecified whether the motor enters brake or float mode. Further, it should be noted that setting a motor to STOP_AND_RESET_ENCODER may or may not be a transient state: motors connected to some motor controllers will remain in this mode until explicitly transitioned to a different one, while motors connected to other motor controllers will automatically transition to a different mode after the reset of the encoder is complete.

        Comment


        • #19
          The 2.3.5 SDK code for communicating with the MR motor controller sets the mode to RUN_WITHOUT_ENCODER after a STOP_AND_RESET_ENCODER.

          Comment


          • #20
            Would absolute turns be the same as I had before except that I don't need that many cases? Or how would I implement it?

            Comment


            • #21
              Originally posted by FTC8564 View Post
              Would absolute turns be the same as I had before except that I don't need that many cases? Or how would I implement it?
              Since you are using our PidControl module, you already has the support. There is a method called setAbsoluteSetPoint(true). That tells PidControl that all the targets are absolute targets, not relative targets. But then all your spinPID call must specify absolution angle (i.e. relative to the starting head, not current heading).
              And yes, your test for turning PID range will be using the code from before.

              Comment


              • #22
                BTW, if you are using absolute heading, you need to make sure the gyro heading is reset right before autonomous starts. You cannot reset it too early because the field people or your team members might have moved the robot before the match is started.

                Comment


                • #23
                  The last post is HUGELY important. We had very high success on our field and on the practice field at our last qualifier. But on the competition field, we were getting undesired turns.
                  The problem ended up being gyro drift. It was slow, but enough. When we were testing, we would Init and the fairly quickly Start. But in competition, the announcer talks for a while, the refs and FTAs help teams that are having problems, an all manner of other delays occur. Over this long time, the slow drift grew large enough to present problems. We didn't figure it out completely at the competition, and thought the competition fields were some kind of Bermuda Triangle.
                  But we were able to repeat the issue when we got back to our build site, and were able to solve it with a single line of code - zeroing the z integrator on the gyro. Boom - 10-40 pt auton becomes 70-100.

                  Comment


                  • #24
                    So I should zero my z integrator right when autonomous starts? And not during init? Does this take up time so it will affect the subsequent move or does it do the reset instantly?

                    Comment


                    • #25
                      Originally posted by FTC8564 View Post
                      So I should zero my z integrator right when autonomous starts? And not during init? Does this take up time so it will affect the subsequent move or does it do the reset instantly?
                      No zeroing the integrator is just resetting an internal variable. It's not calibration. It should take next to no time.

                      Comment


                      • #26
                        Do it right after start.

                        Comment


                        • #27
                          Originally posted by FTC7253 View Post
                          Do it right after start.
                          In particular, if you are using LinearOpMode, do it right after waitForStart(). If you are using OpMode, then do it in the start() method.

                          Comment

                          Working...
                          X