Announcement

Collapse

Technology Forum Has Moved!

The FIRST Tech Challenge Technology forum has moved to a new location! Please take a look at our forum blog for links and instructions on how to access the new forum.

https://firsttechchallenge.blogspot....orum-blog.html

Note that volunteers (except for FTA/WTA/CSA will still access their role specific forum through this site. The blog also outlines how to access the volunteer forums.
See more
See less

linear OpMode vs. iterative OpMode

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

  • linear OpMode vs. iterative OpMode

    What are the pros and cons of the linear OpMode vs. the iterative OpMode? What are the considerations for choosing one over the other?
    Is one of them simpler to code? Does one of them give better performance?
    Also, is there any special thing to note when programming a linear OpMode, or an iterative OpMode?

  • #2
    Linear OpMode works better for Autonomous, and regular OpMode work better for Teleop. These are just my opinions however, and there may be more to it.

    Comment


    • #3
      A few things to consider:
      Can you work with state machines effectively?
      Can you program in a loop, or do you program in imperative manner?
      Can you only see the problem in a linear manner?

      The debate of OpMode versus LinearOpMode is that of how you can solve the problem best in; it is not a debate of performance concerns at this point. Most people chose LinearOpMode as a means for Autonomous whereas OpMode is most commonly used for TeleOp. The boilerplate for OpMode is easiest to use to interpret the TeleOp program, as the state of the robot is constantly changing. The LinearOpMode is easiest to use for someone completely new to programming as it provides a similiar idiom to work with that is similar to public static void main(String[] args), and is often an easier way to write non-trivial OpModes.

      Comment


      • #4
        Originally posted by yifat View Post
        What are the pros and cons of the linear OpMode vs. the iterative OpMode? What are the considerations for choosing one over the other?
        Is one of them simpler to code? Does one of them give better performance?
        Also, is there any special thing to note when programming a linear OpMode, or an iterative OpMode?
        The fundemental operation of an iterative opMode() and a sequential linearOpMode are very similar.
        In this season's SDK, the way both methods access the robot hardware is identical.

        In linearOpMode, there is one additional telemetry.update() call that is required to let the app know when to send updated telemetry to the Driver Station, but once you remember that this needs to be deone each time around the loop, the code is almost identical.

        I always find that learning one system well, is better than learning two systems partially well, so were possible I try to stick with one approach.

        Last year that was the iterative opMode() class. But that meant adopting state machines to do most things in autonomous.

        This year we are sticking with linearOpMode() for all opmodes (auto and teleop) because you can do both equally well with linearOpMode.
        Simply check out the two samples in the SDK, to see how little difference there is between a opMode() vs linearOpMode() teleop routine.

        The beauty of this season's linearOpMode is that you can choose to do in-line linear programming, OR looping state-machine style programming equally well.
        You have the choice to use the best method for the task at hand, and are able to switch between the two styles without having to change your opmode class to do it.

        Phil.

        Comment


        • #5
          I haven't been following the linear opmode threads carefully as my team decided to continue to use iterative, but from the threads some of the details of linear seem a bit confusing. Is there a link giving the definitive what's required or not? Does it need to specify the differences between 2.2 and 2.35? I keep seeing references to needing or not needing to include things like throws exception, idle, update, opModeActive, etc. And also what is needed for a tight loop, what defines when something is tight enough to be a tight loop?

          Comment


          • #6
            Originally posted by 3805Mentor View Post
            I haven't been following the linear opmode threads carefully as my team decided to continue to use iterative, but from the threads some of the details of linear seem a bit confusing. Is there a link giving the definitive what's required or not? Does it need to specify the differences between 2.2 and 2.35? I keep seeing references to needing or not needing to include things like throws exception, idle, update, opModeActive, etc. And also what is needed for a tight loop, what defines when something is tight enough to be a tight loop?
            I think it's fair to say that the initial priority has been to create "follow these steps" type documentation to support the largest use group.

            I know it's not a "specification" but the Sample opmodes released with each SDK version do illustrate the latest "recommended" linear and iterative styles.
            They are updated to demonstrate the latest features and concepts.

            eg: You'll notice that the current samples do not include the "throws exception" behavior, and there are no explicit idle() calls any more.
            (note: this was in direct response to questions and issue in this forum, so it shows that the tech team does value such input)

            I agree that a "style" guide (or perhaps more explicitly... an "avoid this" guide) would certainly be useful.
            As with all things... the availability of resources to generate it is the key limitation.

            When creating many of the samples, I did try to employ a defined style (some of which was included in the readme and some of which was broken to be compatible with past docs).
            In lieu of a formal doc, I strongly recommend that you read the descriptions and comments that are found in the code samples.
            In most chases these will explain the reason why something is there (rather than just what's being done)

            Phil.

            Comment

            Working...
            X