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


            • #7
              FTC12676, do you send bytes directly to the rev hub to remap axis? If you do, then that remapping will stay constant until you remap them back. So, it is not necessary to remap them again at the beginning of TeleOp.

              Comment


              • #8
                So we tried making static variables to hold specific values between auton and teleop but result is inconsistent. Some time static values hold sometime we get null pointer exception. As far as IMU it may hold values but I kind of do not want to trust FtC SDK as there is no clear documentation of what does SDK do when auton stops and teleop starts. Also as Phil mentioned before motor direction does not carry forward. With all this we decided to clean init for teleop again just to avoid surprises.

                Comment


                • #9
                  Late Reply...

                  The App is a single program that has an opmode derived class instantiated for each opmode.
                  If you want to share data between them you need to manage if and when that data is initialized.

                  In the case of surprising null pointed exceptions, you would need to ensure that you deal with null pointers by detecting them and initializing them. By this I don't mean exception handling, instead I mean checking for null pointers and making sure they are initialized.

                  For example, in our code we only wanted the IMU to be initialized in Auto. This assumes that Auto is always run first, and then Telop. But during testing, you sometimes skip Auto and start with Teleop, so your code needs to be able to handle an unexpected null IMU in teleop.

                  So in this case we just have a check on the hardware class to see if the IMU object is null. If it is, we initialize it, otherwise we leave it alone. So whatever runs first after starting the app will do the init.

                  Comment

                  Working...
                  X