Questions about OpMode paradigm

[hexafraction]

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!

[Jerry McManus]

My understanding is "opmode" simply refers to the teleop program, which in the case of this new platform is an android app. Actually, two android apps, one on the driver side and one on the robot side.

Perhaps some time spent familiarizing yourself with the Android SDK and Android developers website might answer some of your questions, but in a nutshell android apps have intents, activities, and services. It's basically event driven, with activities getting events either from the system, from other intents, or from UI widgets. I'm guessing the FTC folks will want to keep the starter apps pretty simple, probably just one main activity handling the UI and maybe a service handling the wifi connection running in the background. The USB stuff is where the FTC SDK/API comes into play, handling commands to the robot hardware (and from the joysticks) and polling sensors, but we wont know what that looks like until they release it.

Java is multi-threaded, so no reason that I can see why anyone who wanted to couldn't run as many threads as they like, no different from tasks in RobotC. Java is also fully object oriented, so its entirely up to you how you want to handle data encapsulation. Hope this helps.

[hexafraction]

My understanding is "opmode" simply refers to the teleop program, which in the case of this new platform is an android app. Actually, two android apps, one on the driver side and one on the robot side.

Perhaps some time spent familiarizing yourself with the Android SDK and Android developers website might answer some of your questions, but in a nutshell android apps have intents, activities, and services. It's basically event driven, with activities getting events either from the system, from other intents, or from UI widgets. I'm guessing the FTC folks will want to keep the starter apps pretty simple, probably just one main activity handling the UI and maybe a service handling the wifi connection running in the background. The USB stuff is where the FTC SDK/API comes into play, handling commands to the robot hardware (and from the joysticks) and polling sensors, but we wont know what that looks like until they release it.

Java is multi-threaded, so no reason that I can see why anyone who wanted to couldn't run as many threads as they like, no different from tasks in RobotC. Java is also fully object oriented, so its entirely up to you how you want to handle data encapsulation. Hope this helps.

I am in fact familiar with Java and Android. My original fear was that the OpMode might be some forced event loop, as opposed to free flow control as in RobotC. My secondary concern is that, yes, threads are possible, but are the classes dealing with hardware themselves thread-safe? What kind of message will we have to know the round is stopping? Polling our joystick control? Seeing an exception "forced" into our thread with Thread#stop(Throwable)? The thread running OpMode being interrupt()ed?

My main reason for this is that I am writing a motion planner for autonomous, and so far I have very little idea as to how the SDK is going to look. My main source of confusion might have been the crawl/walk/run options. It is quite possible that crawl and maybe walk would have a pre-made event loop, while run has the more open program flow I am hoping for.

[Jerry McManus]

Ah, OK. Thanks for the link, that's an interesting project.

Android apps run in a single thread called "Main" (not to be confused with "Main Activity" which is the typical entry point for an app) this thread is also known as the "UI" thread. A brief google search quickly revealed that the Android UI Toolkit is not thread-safe and developers should take pains not to manipulate UI components from anywhere except the UI thread:

https://developer.android.com/guide/...d-threads.html

Obviously this is not as much of a concern for FTC robotics as the typical robot app should require very little user interaction.

AFAIK, there is no "forced event loop" on the part of FTC, they are simply providing an SDK for interacting with the USB hardware and they are also generously providing sample apps to get people started. Whether any of that is thread safe is something the FTC engineers will have to answer.

As far as when the round is stopping, my understanding is that the new "sport start" format requires teams to pay attention, wait for a sign from the referee's and/or for some sort of audible alarm, and stop their robots when they are told too do so.

About the "crawl/walk/run", it seems pretty straight forward:
"Crawl" - FTC is doing most of the programming for you, and holding your hand as you take baby steps and make small mods to their sample apps
"Walk" - Here is a nifty graphical interface for lots of drag n' drop programming goodness
"Run" - You got this! Fire up your favorite Java IDE, strap on our new SDK, and GO FOR IT!

Hope this helps.

[Jerry McManus]

Also, for those that have been wondering about the direct wifi stuff, I found this to be informative:

https://developer.android.com/traini...fi-direct.html

Not sure if FTC is providing some sort of "wrapper" for this as part of their SDK, or if teams will simply be expected to use the sample apps as a template. It does appear that there are plenty of options for determining exactly which device you are talking to. Should be interesting to see how FTC enforces a team connecting only to their hardware and not interfering, accidentally or otherwise, with other teams robots.

[hexafraction]

Ah, OK. Thanks for the link, that's an interesting project.

Android apps run in a single thread called "Main" (not to be confused with "Main Activity" which is the typical entry point for an app) this thread is also known as the "UI" thread. A brief google search quickly revealed that the Android UI Toolkit is not thread-safe and developers should take pains not to manipulate UI components from anywhere except the UI thread:

https://developer.android.com/guide/...d-threads.html

Obviously this is not as much of a concern for FTC robotics as the typical robot app should require very little user interaction.

AFAIK, there is no "forced event loop" on the part of FTC, they are simply providing an SDK for interacting with the USB hardware and they are also generously providing sample apps to get people started. Whether any of that is thread safe is something the FTC engineers will have to answer.

As far as when the round is stopping, my understanding is that the new "sport start" format requires teams to pay attention, wait for a sign from the referee's and/or for some sort of audible alarm, and stop their robots when they are told too do so.

About the "crawl/walk/run", it seems pretty straight forward:
"Crawl" - FTC is doing most of the programming for you, and holding your hand as you take baby steps and make small mods to their sample apps
"Walk" - Here is a nifty graphical interface for lots of drag n' drop programming goodness
"Run" - You got this! Fire up your favorite Java IDE, strap on our new SDK, and GO FOR IT!

Hope this helps.

OK, that definitely clears things up for me enough to move forward with my codebase. Hopefully more info (or hardware access) will be on its way soon.

[Cheer4FTC]

AFAIK, there is no "forced event loop" on the part of FTC, they are simply providing an SDK for interacting with the USB hardware and they are also generously providing sample apps to get people started.

Do you have any hands-on, working knowledge about what they will be providing, or are you merely speculating?

Because in this forum post, someone who has used the OpModes in the official FTC beta tests of the new platform indicates that there is essentially a "forced event loop," that OpModes are used for both teleop and autonomous, and that OpModes need to be implemented by filling in "start", "run", and "stop" methods that are "rapidly called" (though there are no details released regarding how frequently these methods are called).

If you truly know more information about these methods, how they are implemented, called and stopped, etc., then I would love to hear any details you can provide. If you're in the dark like the rest of us then I guess you're free to speculate, but we all might just be better off waiting until we get hard information from the official sources as speculation seems to be all over the map.

[Jerry McManus]

Do you have any hands-on, working knowledge about what they will be providing, or are you merely speculating?

Nope, no hands on with what FTC is providing, but plenty of experience with Android and Java. I feel that I've been pretty clear in my posts that my comments are educated guesses and nothing more.

Yep, I saw the thread you linked to and I don't believe it changes anything. A base class with a "run()" method is clearly not the same thing as the "forced event loop" that was referred to upthread. Teams are responsible for implementing those methods, not FTC. I will further "speculate" that teams will still need to provide their own timing, loops or otherwise, just as we did in RobotC. If the base class had some sort of an "update()" method that was repeatedly invoked from the "framework" (whatever that is) then that would be an entirely different beast.

I dunno, I suppose I could be missing something, but it all seems pretty clear to me: The teams are responsible for starting and stopping their own programs by extending the base class. The teams start the program, probably from a UI widget on the driver side app (yes, before you get snippy, that is just a guess), and what happens after "run()" is entirely up to the teams.

[Cheer4FTC]

A base class with a "run()" method is clearly not the same thing as the "forced event loop" that was referred to upthread. Teams are responsible for implementing those methods, not FTC. I will further "speculate" that teams will still need to provide their own timing, loops or otherwise, just as we did in RobotC. If the base class had some sort of an "update()" method that was repeatedly invoked from the "framework" (whatever that is) then that would be an entirely different beast.

Thanks for your reply.

I guess I'm having trouble understanding your thoughts on the difference between a run() method that is rapidly called from the FTC framework (which Robert Van Hoose says was how it was implemented in the beta testing) and what you say is an "update" method that is repeatedly called from the framework.

To me, Robert's description of the run() method is more like the contents of the "while (true)" loop that is in the FTC RobotC teleop template. It sounded to me as though Robert was saying that the framework called the run() method every XX ms and the run method would then read sensors or joystick settings and update motors, and that the timing of the XX ms was dictated by the framework and not by the run() method itself. I've asked a few questions on the forum seeking clarification on this timing question but haven't seen any reply from the FTC people-in-the-know. To me, this description sounds exactly like the "update" method you describe. Can you clarify how you think they are different?

Thanks in advance for sharing any further insights you may have.

(BTW, I'm the author of several FTC Android apps available on google play and coded in Java using Android Studio, so don't be shy about elaborating in more detail if you think that would be helpful)

[hexafraction]

To me, Robert's description of the run() method is more like the contents of the "while (true)" loop that is in the FTC RobotC teleop template. It sounded to me as though Robert was saying that the framework called the run() method every XX ms and the run method would then read sensors or joystick settings and update motors, and that the timing of the XX ms was dictated by the framework and not by the run() method itself. I've asked a few questions on the forum seeking clarification on this timing question but haven't seen any reply from the FTC people-in-the-know. To me, this description sounds exactly like the "update" method you describe. Can you clarify how you think they are different?

I'm also a bit confused by this statement. It wasn't clear if the loop was calling our implementation, or if the loop was to be inside our implementation. At any rate, at least for the "run" skill level (and hopefully for the "walk"), the ability to write our own style of event loop would be very helpful. There are some things that justify something more creative than or different from the basic event loop. In that case, my original questions about what can be done within and across loop iterations (original post of this thread) still hold.