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.

The official blog of the FIRST Tech Challenge - a STEM robotics programs for students grades 7-12.

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

Stop an OpMode in a loop.

  • Filter
  • Time
  • Show
Clear All
new posts

  • Stop an OpMode in a loop.

    My team and I are using the base OpMode to run our autonomous program. This is NOT LinearOpMode. So, I was wondering what the best way to check and make sure that the driver station has not requested a stop is inside of a while loop in my OpMode. I am using encoders, and made a method to run while the encoders are not at their specified position. But, how do I check within the while loop to make sure that the driver station has not requested an opmode stop?

  • #2
    If you are not writing a LinearOpMode, you should avoid writing code that loops until some external condition (encoders, sensors, time elapsed, etc.) is met. Each time loop() is called, you should update your outputs (motors, servos, telemetry, etc.) based on your inputs and then immediately return from loop(). If you want to do the equivalent of waiting for an external condition, you will need a variable to keep track of the state you are in between calls to loop() and then check each loop cycle whether the external condition has been met, and if so, transition to the next state. The LinearOpMode interface was created because this "state machine" approach is less intuitive if you are used to thinking in the linear style of "do this, wait, then do this". So you should either rewrite your OpMode so that it is never blocking loop() from returning because it is waiting for an external condition, or you should convert your OpMode to a LinearOpMode.
    Our team wrote state-based programs back in RobotC because we often had things we wanted to run every loop cycle, so we have always used OpMode instead of LinearOpMode. In order to write complex autonomous programs, we have created a library for building modular components (like driving forward, moving a servo, or waiting for time) that we can combine with linear or branching state machines or by running components "in parallel." We have found this to be a very powerful and flexible model, but it certainly has a steeper learning curve and requires you to be more familiar with thinking in a state-machine style. I think it would probably be easiest for you to make the (likely minimal) modifications needed to write your program as a LinearOpMode.


    • #3
      Thanks! My team and I were trying to steer clear of the LinearOpMode this year becuase of consistency problems we had with it last year. I moved everything over to using a state machine tonight, and it works like a charm! I believe I ended up with 6 state machines, 5 of which were nested in the main state machine, so it is a lot more complicated to say the least. However, everything works as expected with absolutely no issues, so we should be golden. Thanks for your input!