Announcement

Collapse
No announcement yet.

What can we put in the Start() method?

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

  • What can we put in the Start() method?

    I'm wondering if a device I/O cycle is being performed between the OpMode Start() and Loop() calls.

    In other words...

    If I do the following

    public void start() {
    leftDrive = hardwareMap.dcMotor.get("left_drive");
    leftDrive.setChannelMode(DcMotorController.RunMode .RESET_ENCODERS);
    }

    Can I reasonably expect the Motor controller to have been given that Encoder Reset command before the first Loop() cycle, or does it need to be done in the Loop() method?


    -----


    Or, will I ever really know without having to do a read-back every time?

    Speaking of which, the example NxtEncoderOp code shows reading back the encoder values to detect when the reset has been completed (both encoders == 0). This is fine if you can guarantee that the motors are stopped, but if the motor is driving a heavy arm which sags, then an Encoder reset is an approximate thing, because it may never readback exactly zero. So I'll ask a question AGAIN that I asked before....

    If we are using all USB hardware, can we assume that if we issue a mode change on one loop() cycle, then the mode change will be completed by the next cycle? yes/no/maybe?

    Note: At Worlds, Jonathan stated to me that a FULL I/O read write operation was performed on all USB devices between Loop() calls. Is this still the case?

  • #2
    Phil,

    That is a very essential question and the answer could change over time when the SDK will be upgraded.

    At the moment, I am planning to recommend my team to use the start() method just to initialize all State Transition Diagrams and data logger. The loop() method will then execute the STDs including the initialization steps. The main activity in stop() method is to close the data logger.

    Comment


    • #3
      In the future , I'd like to see an Op Mode that defines the sensor resources with listener event methods that perform the code to the perform the motor operations. i.e no loop method being called indefinitely. I'm sure there is still looping being done at some level but I just don't think the team developers should be exposed to that. For example, if an app developer needs to add a clickable button to a screen, I would not expect him to have to create a loop method to keep checking if the button is clicked.

      Comment


      • #4
        Originally posted by Philbot View Post
        I'm wondering if a device I/O cycle is being performed between the OpMode Start() and Loop() calls.

        In other words...

        If I do the following

        public void start() {
        leftDrive = hardwareMap.dcMotor.get("left_drive");
        leftDrive.setChannelMode(DcMotorController.RunMode .RESET_ENCODERS);
        }

        Can I reasonably expect the Motor controller to have been given that Encoder Reset command before the first Loop() cycle, or does it need to be done in the Loop() method?


        -----


        Or, will I ever really know without having to do a read-back every time?

        Speaking of which, the example NxtEncoderOp code shows reading back the encoder values to detect when the reset has been completed (both encoders == 0). This is fine if you can guarantee that the motors are stopped, but if the motor is driving a heavy arm which sags, then an Encoder reset is an approximate thing, because it may never readback exactly zero. So I'll ask a question AGAIN that I asked before....

        If we are using all USB hardware, can we assume that if we issue a mode change on one loop() cycle, then the mode change will be completed by the next cycle? yes/no/maybe?

        Note: At Worlds, Jonathan stated to me that a FULL I/O read write operation was performed on all USB devices between Loop() calls. Is this still the case?

        So what happens for teams that use the hitechnic gyro? That sensor requires about 3 seconds
        of initialization before it's ready to use.

        On the old system, we'd just do that work before calling waitForStart().

        How is it done now without eating into autonomous time?

        Comment


        • #5
          In the current version of the software you can assume all USB devices have been written to, and their latest values have been read back in. This happens between start and loop, and after each call to loop.

          We may optimize the loop in the future where slower USB devices aren't in prefect sync. The motor and servo controllers are very fast, and will probably always stay in sync.

          Comment


          • #6
            Jonathan,

            Can you explain why in the NxtEncoderOp example the encoders are reset in the start() method and then later in the loop method they are checked and reset again? It seems that in state_zero, they wouldn't need to be reset again, only the previous read values checked.

            Code:
            case STATE_ZERO:
                      if (motorRightRunMode != DcMotorController.RunMode.RESET_ENCODERS ||
                          motorLeftRunMode != DcMotorController.RunMode.RESET_ENCODERS) {
                        motorLeft.setChannelMode(DcMotorController.RunMode.RESET_ENCODERS);
                        motorRight.setChannelMode(DcMotorController.RunMode.RESET_ENCODERS);
                      } else {
                        state = State.STATE_ONE;
            It seems like when we remove the motorLeft.setChannelMode(DcMotorController.RunMode .RESET_ENCODERS) the encoders never get reset. It is like the reset in the start() method was not executed. In the SDK code, it seems like the writes are being queued up and the later ones might overwrite the previous ones. For the legacy controller, are the whole contents of the Tetrix motor controller register map being queued up for each write? It seems like if they are queued up like that then only the last one will get executed. There for the need for the loop to resend the commands.

            Can you explain more about how the writes to i2c are being buffered?

            Thanks for your help.

            Comment


            • #7
              Can you explain more about how the writes to i2c are being buffered?
              I'd also be very interested to know why some things were done in this code.

              After reviving most of the OpModes, they don't seem as well written or tested as the other code.
              I wonder if they were team-generated with little in the way of quality review.
              Once again, I'm hoping this is simply because these are early releases and not final sample code.

              In the code you are discussion, there seems to be a pretty solid strategy of:

              "We don't know when the Legacy reads or writes are being performed, so if the current state isn't what we want, just re-write it, whether it needs it or not. "

              For me, this does not instill any confidence that one write operation is sufficient.
              I can't imagine any actual buffering is going on, so it's just a foolproof way to ensure that the data gets written/read eventually.

              This is the primary reason I'm not even going to consider using legacy motor controllers going forward.

              I'm working through replicating our last-season auto code (scored in center goal in all three positions) with the new USB controllers, and it looks pretty readable.
              I can't even imagine doing it with legacy hardware.

              Phil.

              Comment


              • #8
                Originally posted by skatefriday View Post
                So what happens for teams that use the hitechnic gyro? That sensor requires about 3 seconds
                of initialization before it's ready to use.

                On the old system, we'd just do that work before calling waitForStart().

                How is it done now without eating into autonomous time?
                Jonathan or Tom, can you please answer this question?

                Thanks.

                Comment


                • #9
                  I imagine you could either take the readings over a shorter amount of time or save the calibration gotten from an initialization opmode to a file.

                  Comment

                  Working...
                  X