Announcement

Collapse
No announcement yet.

Hardware initialization from autonomous to teleop

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

  • Hardware initialization from autonomous to teleop

    Does hardware initialization esp IMU remains in effect after autonomous opmode finishes and teleop opmdoe is selected? Let us assume we set IMU or robot frame of refrance to align with field frame of reference using vuforia during autonomous and when we start teleop and do not initialize IMU in teleop will IMU frame of refrance same as field?

  • #2
    The answer is yes, no, maybe...

    With Android Studio, all the opmodes exist in the one app, and they share a common execution.... I'm not quite sure how it works with Blocks or OnBotJava.

    Anyway, with AS, some initializations persist across different opmodes. For, example, if you Attach to a motor in Auto and set the "direction" of the motor to "REVERSE", when you enter Teleop, that "direction" will still be set. This caused several teams issues where they set the Left motor to REVERSE in Auto, but then set the Right motor to REVERSE in teleop.
    When they just ran Teleop, everything was OK, but if they Run Auto first, and then Teleop, both motors ended up reversed.

    Note: This is why I always recommend setting the direction of ALL motors in each opmode.

    But in other instances, SDK code has been put in place to guarentee that certain properties are always set in a default mode prior to any opmode. (Typically for safety reasons)

    So, to answer your question, I would not Assume that devices always get reset at the start of each opmode.
    If you want to ensure a certain setup, you should do it in every opmode (A custom robot hardware class helps with this).

    However, in your case it seems that you may want data to persist over opmode runs. So I'd recommend just doing some tests to see if it's possible.
    You may need to create and share a static class/variable between all your opmodes that enable you to reset and calibrate the gyro once, and then not repeat that reset operation again.
    But it should be possible.

    Comment


    • #3
      Originally posted by FTC12676 View Post
      Does hardware initialization esp IMU remains in effect after autonomous opmode finishes and teleop opmdoe is selected? Let us assume we set IMU or robot frame of refrance to align with field frame of reference using vuforia during autonomous and when we start teleop and do not initialize IMU in teleop will IMU frame of refrance same as field?
      If you want to use Vuforia to set the angle the IMU starts at relative to the field, you could also save the angle the IMU ends at relative to the field at the end of autonomous in a file on the phone and then read that file in the TeleOp program.

      Comment


      • #4
        Thanks Philbot, Nova for suggestions. I have follow up question - we have Rev hub mounted vertically so during initialization we change axis in IMU. Now if we do this in autonomous do we need to re-do same in teleop ?

        Comment


        • #5
          To Phil re: post #2 above....

          Phil could you elaborate on "create and share a static class/variable" to not have to initialize the imu when we switch to TeleOp? Most of the time the imu calibration persists between opmodes if we don't powercycle the rev hub. sometimes (but not always) we get "warning, problem with IMU" with is only remedied by initializing the imu, which resets the absolute heading.

          How do we set the gyro orientation without executing the bosch imu initialization command? We want to reset the imu once and use that orientation during teleop.

          thanks
          Russ Miller
          FTC team 9808

          Comment


          • #6
            The (minor) problem with doing imu init only in the auton and then not in tele is if you want to run tele without having run auton (testing, etc).
            You can create a static variable that stores the heading at the end of auton. This can then be read in tele. Go ahead and init the imu in tele, and then have a getMyHeading type method that offsets the imu heading with the value of the static endOfAutonHdg value. If you didn't run auton within the current powercycle, endOfAutonHdg would be its default (likely 0).

            Comment

            Working...
            X