Questions about OpMode paradigm

[Jerry McManus]

OK, I guess I was wrong about the "run()" method, it appears it is repeatedly invoked. Apologies for the confusion. I guess well have to wait and see if it is just a convenience method for less experienced teams or if its implementation will be enforced by FTC for some reason.

[hexafraction]

OK, I guess I was wrong about the "run()" method, it appears it is repeatedly invoked. Apologies for the confusion. I guess well have to wait and see if it is just a convenience method for less experienced teams or if its implementation will be enforced by FTC for some reason.

I'd love to have some official statement on this, either through the forum or in a Tech Talk video. Otherwise I am (we are) currently in the dark.

[NoahAndrews]

I'm also eagerly waiting for more information on exactly how this will work.

[Robert Van Hoose]

As I have understood from posts in the forum so far, there is a so-called OpMode that we need to extend, that we don't have much information about yet. Could someone actually knowing applicable details tell me:

• [1]Is our OpMode handler the implementation of the body of an event loop? Or is it a handler called once, inside which control can remain as long as we want?
  [2]How often will the OpMode handler we write be called by the FTC runtime?
  [3]How long can the OpMode handler we write take to execute? Will the robot be shut down/program be killed if the handler takes too long to complete?
  [4]Will we be able to stop the program if program flow remains in the handler (before it returns control to the FTC runtime, that is)
  [5]What kind of data storage can we persist across loop iterations, if our handler is the body of the event loop?
  [6]Can we run multiple threads (calculations only, no hardware access) that are not running in lockstep with the OpMode loop?
  [7]Is there anything keeping us from making accesses to hardware directly from other threads? (Assuming we use proper synchronization)

Thanks!

You're asking all the right questions. I unfortunately didn't take timings during our beta test to determine how quickly our OpMode code was invoked, but it would likely change anyway since we were using a beta version of the FTC SDK. I'll again preface my comments by saying I'm not speaking for FIRST and my opinions are my own...

1- The run() method is called from an event loop. I did verify that motor settings, etc. that are changed in the run() method had no effect until the run() method was completed. Writing a procedural-type method where we set power/waited, set a different power/waited, resulted in the robot sitting still until all the sleep()-ing was complete and then moving at the power set last.
2-Didn't time it. My perception was that it runs very quickly.
3-We slept for several seconds (10-15 total) during our abortive attempts at a procedural autonomous mode and that didn't cause the framework to terminate our mode. But like any event-driven program, you'll want to avoid blocking the event loop in order to maintain a responsive robot.
4-Not sure what you're asking... You'd be able to terminate/restart the OpMode from the driver control station at will. Or if you want the Autonomous mode to stop itself you would just define an "All Stop" state and go into that state.
5-Your OpMode program stays alive while it's active, so you should be able store data in class variables that will persist between run() invocations. I didn't test what happens if there is an orientation change on the robot controller. Typically an orientation change causes your Activity to reload, so you have to manually persist data to handle that.
6-I saw nothing that would prevent worker threads.
7-I'm waiting for hardware to come out so I can answer this question myself...

I know this is not 100% helpful since it's unofficial and you can't really hang your hat on it, but I feel pretty confident in what I'm telling you. The takeaway is that autonomous will need to be event-driven rather than sequential logic. I'm sure some teams are going to struggle a bit before they figure this out. I personally plan to help the community as much as I am able by sharing what we learn. I realize that many teams do not have experience software developers to lean on for help.

In thinking about how to write event-driven autonomous, I am coming around to the opinion that another level of abstraction might be necessary for some teams. I come from a C# background where I'm accustomed to writing functional programs and one of the things I'm curious to try is to see if Java8 lambdas can be made to work within this framework (there are some postings about retrofitting lambdas into Java7, so I have hope). I think lambdas would potentially provide a slick way to write event-driven state machines to handle autonomous programs. Assuming I can get access to some hardware over the summer, I plan to work on something and if it pans out I will share it with the community.

[hexafraction]

1- The run() method is called from an event loop. I did verify that motor settings, etc. that are changed in the run() method had no effect until the run() method was completed. Writing a procedural-type method where we set power/waited, set a different power/waited, resulted in the robot sitting still until all the sleep()-ing was complete and then moving at the power set last.
2-Didn't time it. My perception was that it runs very quickly.
3-We slept for several seconds (10-15 total) during our abortive attempts at a procedural autonomous mode and that didn't cause the framework to terminate our mode. But like any event-driven program, you'll want to avoid blocking the event loop in order to maintain a responsive robot.
4-Not sure what you're asking... You'd be able to terminate/restart the OpMode from the driver control station at will. Or if you want the Autonomous mode to stop itself you would just define an "All Stop" state and go into that state.
5-Your OpMode program stays alive while it's active, so you should be able store data in class variables that will persist between run() invocations. I didn't test what happens if there is an orientation change on the robot controller. Typically an orientation change causes your Activity to reload, so you have to manually persist data to handle that.
6-I saw nothing that would prevent worker threads.
7-I'm waiting for hardware to come out so I can answer this question myself...

I know this is not 100% helpful since it's unofficial and you can't really hang your hat on it, but I feel pretty confident in what I'm telling you. The takeaway is that autonomous will need to be event-driven rather than sequential logic. I'm sure some teams are going to struggle a bit before they figure this out. I personally plan to help the community as much as I am able by sharing what we learn. I realize that many teams do not have experience software developers to lean on for help.

In thinking about how to write event-driven autonomous, I am coming around to the opinion that another level of abstraction might be necessary for some teams. I come from a C# background where I'm accustomed to writing functional programs and one of the things I'm curious to try is to see if Java8 lambdas can be made to work within this framework (there are some postings about retrofitting lambdas into Java7, so I have hope). I think lambdas would potentially provide a slick way to write event-driven state machines to handle autonomous programs. Assuming I can get access to some hardware over the summer, I plan to work on something and if it pans out I will share it with the community.

I do think Retrolambda works with Android, and at any rate anonymous-class implementations of interfaces work kind of in that regard. My big issue with the loop is that it's quite constraining compared to the multi-task control we had on RobotC, especially given that the loop timing might not be as fast as hoped for. Hopefully the final SDK release for the season will allow some way to override this.

[Jerry McManus]

I didn't want to get into a silly argument over code we have not seen yet, and we greatly appreciate Robert's observations, but it really does sound to me like all FTC is doing is starting a thread and implementing the "runnable" interface, which, you guessed it, has a "run()" method that is called once. Like I said before, it is PROBABLY up to the teams what they want to do with that.

http://developer.android.com/referen.../Runnable.html

Yes, this is JUST A GUESS, but I would bet dollars to dimes that all their sample app is doing is just showing one example of how to implement a while loop in an android app and is not in any way "enforcing" an event loop on anybody.

OK, I'll shut up now.

[hexafraction]

I didn't want to get into a silly argument over code we have not seen yet, and we greatly appreciate Robert's observations, but it really does sound to me like all FTC is doing is starting a thread and implementing the "runnable" interface, which, you guessed it, has a "run()" method that is called once. Like I said before, it is PROBABLY up to the teams what they want to do with that.

http://developer.android.com/referen.../Runnable.html

Yes, this is JUST A GUESS, but I would bet dollars to dimes that all their sample app is doing is just showing one example of how to implement a while loop in an android app and is not in any way "enforcing" an event loop on anybody.

OK, I'll shut up now.

Can you show me where we can see this sample app's code for ourselves?

[Tom Eng]

As I have understood from posts in the forum so far, there is a so-called OpMode that we need to extend, that we don't have much information about yet. Could someone actually knowing applicable details tell me:

• Is our OpMode handler the implementation of the body of an event loop? Or is it a handler called once, inside which control can remain as long as we want?
• How often will the OpMode handler we write be called by the FTC runtime?
• How long can the OpMode handler we write take to execute? Will the robot be shut down/program be killed if the handler takes too long to complete?
• Will we be able to stop the program if program flow remains in the handler (before it returns control to the FTC runtime, that is)
• What kind of data storage can we persist across loop iterations, if our handler is the body of the event loop?
• Can we run multiple threads (calculations only, no hardware access) that are not running in lockstep with the OpMode loop?
• Is there anything keeping us from making accesses to hardware directly from other threads? (Assuming we use proper synchronization)

Thanks!

Hi hexafraction,

Thanks for your post. I'll do my best to try and help answer your questions.

1. In the framework that is provided with the SDK, op modes have three methods are run when an op mode is executed.
   
   1. The start() method gets called when the op mode is first enabled. You can place your initialization code here. The start() method is similar to the setup() method in an Arduino program. Note that this method is eventually going to be renamed to setup() to match the name of the method used in an Arduino program.
   2. The run() method gets called repeatedly in a loop while the op mode is running. I believe the run() method gets called every 30 mseconds. You put the heart of your code in this method. As someone mentioned in this thread, this run() method is similar to the an infinite while loop in the RobotC program templates or the loop() method that gets called repeatedly in an Arduino program. Note that this method is eventually going to be renamed to loop() (like the name of the method in an Arduino program).
   3. The stop() method gets called when the op mode is disabled. You can put cleanup code here.
2. As I mentioned above, I believe the run() method gets called repeatedly every 30 msec.
3. I don't know how fast it takes to run through the run() method, but it's typically very fast, depending on what you do within the method. I don't think the program will shut down if you remain in the run() method too long, but as Robert Van Hoose said, you probably want to avoid blocking the event loop if you want to keep your robot responsive. Instead of blocking within the loop, you can create non blocking code that uses elapsed time and/or state variables to process a set of instructions in a linear fashion. There are some public varibles/methods that are available with the OpMode class that let you access the elapsed time within the run() method.
4. Regarding the persistent data across the run() iterations, when you define your op mode class, you can create member variables to store data that are visible to the start(), run() and stop() methods of the class. You can use these member variables to store data between iterations.
5. Yes, you can run other independent threads within your op mode. there are some restrictions. As someone pointed out earlier, Android does not let you access UI elements outside of the UI thread, but this should not really be an issue for most Op Modes. Also, you cannot write to the hardware modules (Legacy Module, Motor Controller, Servo Controller, etc.) in your own thread - you need to do this from the start(), run() or stop() methods. Although it is not recommended, I believe you can read from these hardware modules outside of the start(), run() and stop() methods. Note that in our pilot test events, there were some teams that wanted to create their own threads that would run in the background and poll the hardware devices to populate a state machine that represented the devices on their robot. I spoke with the lead developer at QualComm and he said that this is not recommended that you do this. You don't really gain anything by having the separate thread that constantly reads the devices for state info. It is more efficient if you simply access the state info in your run() method by calling the appropriate method for the device that you are interested in.
6. As I mentioned previously, you can only write to the hardware modules in the start(), run() or stop() methods. Also, although it is not recommended that you do so, you can read from the hardware modules outside of the start(), run() and stop() methods.

I hope this helps.

Sincerely,

Tom

[hexafraction]

Hi hexafraction,

Thanks for your post. I'll do my best to try and help answer your questions.

1. In the framework that is provided with the SDK, op modes have three methods are run when an op mode is executed.
   
   1. The start() method gets called when the op mode is first enabled. You can place your initialization code here. The start() method is similar to the setup() method in an Arduino program. Note that this method is eventually going to be renamed to setup() to match the name of the method used in an Arduino program.
   2. The run() method gets called repeatedly in a loop while the op mode is running. I believe the run() method gets called every 30 mseconds. You put the heart of your code in this method. As someone mentioned in this thread, this run() method is similar to the an infinite while loop in the RobotC program templates or the loop() method that gets called repeatedly in an Arduino program. Note that this method is eventually going to be renamed to loop() (like the name of the method in an Arduino program).
   3. The stop() method gets called when the op mode is disabled. You can put cleanup code here.
2. As I mentioned above, I believe the run() method gets called repeatedly every 30 msec.
3. I don't know how fast it takes to run through the run() method, but it's typically very fast, depending on what you do within the method. I don't think the program will shut down if you remain in the run() method too long, but as Robert Van Hoose said, you probably want to avoid blocking the event loop if you want to keep your robot responsive. Instead of blocking within the loop, you can create non blocking code that uses elapsed time and/or state variables to process a set of instructions in a linear fashion. There are some public varibles/methods that are available with the OpMode class that let you access the elapsed time within the run() method.
4. Regarding the persistent data across the run() iterations, when you define your op mode class, you can create member variables to store data that are visible to the start(), run() and stop() methods of the class. You can use these member variables to store data between iterations.
5. Yes, you can run other independent threads within your op mode. there are some restrictions. As someone pointed out earlier, Android does not let you access UI elements outside of the UI thread, but this should not really be an issue for most Op Modes. Also, you cannot write to the hardware modules (Legacy Module, Motor Controller, Servo Controller, etc.) in your own thread - you need to do this from the start(), run() or stop() methods. Although it is not recommended, I believe you can read from these hardware modules outside of the start(), run() and stop() methods. Note that in our pilot test events, there were some teams that wanted to create their own threads that would run in the background and poll the hardware devices to populate a state machine that represented the devices on their robot. I spoke with the lead developer at QualComm and he said that this is not recommended that you do this. You don't really gain anything by having the separate thread that constantly reads the devices for state info. It is more efficient if you simply access the state info in your run() method by calling the appropriate method for the device that you are interested in.
6. As I mentioned previously, you can only write to the hardware modules in the start(), run() or stop() methods. Also, although it is not recommended that you do so, you can read from the hardware modules outside of the start(), run() and stop() methods.

I hope this helps.

Sincerely,

Tom

Thanks! I have some follow-up questions:

• Say my run() method needs to do some processing that is big enough that it won't fit within 30 msec, but isn't heavy enough to warrant sending to another thread. Will the program incur issues if I am in that method for, say, 100msec?
• Are all standard methods of synchronization in Java (e.g. locks, intrinsic locking with synchronized blocks, java.util.concurrent classes) usable? Is the thread restriction for hardware writes that any ONE thread can write to it, or only the OpMode run() thread can?
• I see that we are implementing our own OpMode; is the base "implementation" an interface, abstract class, or something else?
• Is the statement that all writes to physical hardware will actually occur only once run() returns true? Does this also hold for the setup method?
• Will there be a possibility of an alternative setup where instead of us running code in run(), and the framework "committing" it to the hardware after run() returns, we write our own loop and/or non-looped program as we would like, and manually call a commitWrites() method to "commit" the new motor/servo positions to hardware?
• Unrelatedly, for advanced sensors that require calibration and/or configuration data to be sent to them before they can return meaningful data, can we write to the advanced sensor module pins?

[Cheer4FTC]

Hi Tom,

Thanks for the detailed response.

Is it possible for a team to poll hardware more frequently than 30ms? For example, if a team wanted to drive forward and poll a touch sensor every 10ms until it is pushed and then stop the drive motors, can this be done on the new platform? Or move an arm and poll the motor's encoder every 10ms until it reaches a set value and then stop? Or read a gyro sensor and update its integrated bearing?

And can an AsyncTask be used to perform background operations (e.g., monitoring sensors, or performing image processing functions on the camera input), or is such a thing not supported by the framework, or is there a different recommended way to do something like this? As hexafraction states, there may be some things that take a bunch of processing and that may be difficult or cumbersome to break down into 30ms chunks of processing time.

I'm worried that the new framework was based solely on the simple RobotC template that uses only the single main task with the simple repeated event loop. Many of our teams have gone far beyond this single-event-loop framework. Being forced to return to it would feel like a big step backward. Maybe there could be a "crawl, walk, run, sprint" set of options, where "sprint" would open things up even more than the "run" option you described?

Thanks in advance for any additional information you can provide. Is there any documentation that could be released before June? Was there any documentation given to the teams that attended the beta-testing, and if so, could that be released so that the rest of us would have the same information?