Software Environment

[Cheer4FTC]

Quick questions about the software environment and how it compares to RobotC.

Our teams frequently use the multi-tasking options in RobotC. For example, we might have a task that runs the arm, kicking off every 5-10ms, and another task that runs another function of the robot, kicking off with a different timer, etc. Will this functionality still exist?

What will the time resolution of tasks and programming be? For example, one team has a task that gets kicked off, starts a motor, and then polls an encoder every 5ms until the motor reaches a specific encoder setting. Will this type of operation be possible and if so, what kind of timer support will there be?

[maths222]

Quick questions about the software environment and how it compares to RobotC.

Our teams frequently use the multi-tasking options in RobotC. For example, we might have a task that runs the arm, kicking off every 5-10ms, and another task that runs another function of the robot, kicking off with a different timer, etc. Will this functionality still exist?

What will the time resolution of tasks and programming be? For example, one team has a task that gets kicked off, starts a motor, and then polls an encoder every 5ms until the motor reaches a specific encoder setting. Will this type of operation be possible and if so, what kind of timer support will there be?

Java supports multi-threading, so you can probably create extra threads to handle these sorts of things. That said, often the same thing can be done with and without threads/tasks, and in general, the single-thread version is significantly less error-prone and easier to work with in the long run. There are exceptions though, and I tend to use threads for things that need to happen in the background regardless of what else is going on (like polling a gyro to update heading)

[NoahAndrews]

maths222 has a GREAT point about avoiding multi-threading. That being said, if you have any concerns about "will we be able to do X in Java", put them to rest. Java is a FAR more capable programming language than RobotC, with FAR better IDEs (Android Studio, IntelliJ IDEA).

[ehochstein]

maths222 has a GREAT point about avoiding multi-threading. That being said, if you have any concerns about "will we be able to do X in Java", put them to rest. Java is a FAR more capable programming language than RobotC, with FAR better IDEs (Android Studio, IntelliJ IDEA).

This is one of the reasons I am so excited that we're switching over to Java. This will also make it easier to switch my FRC team over to java.

[Cheer4FTC]

That said, often the same thing can be done with and without threads/tasks, and in general, the single-thread version is significantly less error-prone and easier to work with in the long run.

To each his own... I have found the opposite. Our teams will often have things in the background (like the gyro polling you mention, or signaling lights to the drivers) that are kicked off at different rates. We also often have semi-autonomous features in the teleop (e.g., push a button and then wait while the arm automatically moves to a fixed position, along with a servo that swings at the same time to keep something at the top of the arm level) which are tricky to do in a single thread with other standard "push a button, change a motor" functions at the same time. Finally, I worked with a rookie middle school team this season where I split the kids up into 4 groups of 2 with each group responsible for building a function of the robot and then programming that function. This was simple to do with four separate tasks in four separate files (e.g., taskGoalGrabber, taskBallGetter, taskArm, etc), while I think it would have been much trickier to do in a single thread.

Yep, I know that Java supports multi-threading. But I'm not sure how the "stop after 2 minutes of teleop" functionality is going to be implemented and I want to make sure that there's an easy, FTC approved way of starting and killing multiple threads. I fear FTC saying something like "you can only have 1 thread, and we'll kick off your inner loop every 100ms for you" which would complicate a lot of things from background tasks to rapid sensor or encoder polling when necessary.

[hexafraction]

Yep, I know that Java supports multi-threading. But I'm not sure how the "stop after 2 minutes of teleop" functionality is going to be implemented and I want to make sure that there's an easy, FTC approved way of starting and killing multiple threads. I fear FTC saying something like "you can only have 1 thread, and we'll kick off your inner loop every 100ms for you" which would complicate a lot of things from background tasks to rapid sensor or encoder polling when necessary.

From what I understand with how Java is designed, that's not extremely likely. You should be able to use threads as you wish, as the API for threads lives in a code language package (java.lang). I would be extremely surprised if java.lang.Thread#stop is unavailable, and even then there are far more widely used Java idioms for controlling threads (e.g. volatile booleans, interruptions, java.util.concurrent synchronizers).

[FTC5501]

From what I am understanding in the initial release is that there will not be any code written to kill the robot after the 2 minutes. Somewhere I read that it would be like a sporting event where when the clock runs out the players must stop driving their robots and if they continue to drive them their will be penalties incurred. I'm not sure how this would work with a "Rogue" robot. I guess this is probably a good point for a new thread as well.

[Robert Van Hoose]

I was allowed to participate in a beta test of the new technology. Essentially the way this works is that you have a base class called "OpMode" to extend. It has a start(), run() and stop() method. After start() completes, the FTC framework will rapidly call your run() method. I saw nothing that would prohibit starting threads, however there was no explicit word on whether the objects that model the motor controllers, etc. are thread-safe or not. In the time allotted for the test we mostly experimented with teleop, so I didn't get a chance to work on autonomous modes as much as I might like.

The chief challenge I anticipate for teams is that you are going to need to code in such a way that you don't block the run() method for a long time, i.e. if you set motor power and then do a Thread.sleep(), nothing happens until you complete the sleep and exit the run() method. My team typically writes a state machine in ROBOTC anyway, so this isn't a big deal for us. But if you're in the habit of writing straight procedural autonomous code then it's going to be an adjustment.

[Cheer4FTC]

I was allowed to participate in a beta test of the new technology. Essentially the way this works is that you have a base class called "OpMode" to extend. It has a start(), run() and stop() method. After start() completes, the FTC framework will rapidly call your run() method. I saw nothing that would prohibit starting threads, however there was no explicit word on whether the objects that model the motor controllers, etc. are thread-safe or not. In the time allotted for the test we mostly experimented with teleop, so I didn't get a chance to work on autonomous modes as much as I might like.

The chief challenge I anticipate for teams is that you are going to need to code in such a way that you don't block the run() method for a long time, i.e. if you set motor power and then do a Thread.sleep(), nothing happens until you complete the sleep and exit the run() method. My team typically writes a state machine in ROBOTC anyway, so this isn't a big deal for us. But if you're in the habit of writing straight procedural autonomous code then it's going to be an adjustment.

Thanks for the response, Robert. It's nice to hear from somebody who's actually used the system and actually has some experience with it. There seem to be a lot of folks on the forum who "speculate with certainty."

Can you elaborate on how "rapidly" the run() method is called? Our teams do some polling every 5-10 ms this year to get precise motor rotations on arms, etc.

Does the start, run, stop model apply to autonomous too?

The single run method is exactly what worries me. If I want to change an alert to the drivers every 500ms, poll certain encoders every 10ms to change key motor powers, poll the controllers every 50ms or so to change manual settings, do some camera image processing or gyro polling at different rates, it sure is nice to not have to put all those different things into a single method running in a single thread. Fingers crossed that starting threads will be allowed and that the objects supporting motors and sensors will support this.

[Philbot]

Even using LabVIEW, we took advantage of multi-threading (multiple "While" loops in the same VI are multi-threaded automatically in LabVIEW).

As with others,we found that monitoring encoders, and different teleop buttons at different rates was essential for good performance.

It's impossible to write just about any app without it these days. It would be hugely crippling to require single threading.....
Most experienced programmers will just find a way to create their own schedulers.

Phil.

[hexafraction]

The single run method is exactly what worries me. If I want to change an alert to the drivers every 500ms, poll certain encoders every 10ms to change key motor powers, poll the controllers every 50ms or so to change manual settings, do some camera image processing or gyro polling at different rates, it sure is nice to not have to put all those different things into a single method running in a single thread. Fingers crossed that starting threads will be allowed and that the objects supporting motors and sensors will support this.

I am also concerned about this, and the intentions of this aren't clear to me. Is it for the purpose of making this "make sense" for weaker teams? Or is there an actual scheduling requirement that requires that motor commands be buffered and parceled into a single set of messages every 5-10 msec? Is it just that the motor control is not thread safe? In that case, if we synchronize it will we be able to forgo use of the run method as a single event loop? Will we be able to spawn appropriately-synchronized threads that communicate with the thread calling the run() method through shared state? So far as I see a possibility might be to calculate desired motor operations and read buffered sensor positions in a separate thread as needed, and only have the run thread update sensor buffered values and write to motors.

[Robert Van Hoose]

Thanks for the response, Robert. It's nice to hear from somebody who's actually used the system and actually has some experience with it. There seem to be a lot of folks on the forum who "speculate with certainty."

Can you elaborate on how "rapidly" the run() method is called? Our teams do some polling every 5-10 ms this year to get precise motor rotations on arms, etc.

Does the start, run, stop model apply to autonomous too?

The single run method is exactly what worries me. If I want to change an alert to the drivers every 500ms, poll certain encoders every 10ms to change key motor powers, poll the controllers every 50ms or so to change manual settings, do some camera image processing or gyro polling at different rates, it sure is nice to not have to put all those different things into a single method running in a single thread. Fingers crossed that starting threads will be allowed and that the objects supporting motors and sensors will support this.

I can't say with certainty how often the method was called, sorry. I will be very surprised if they put any restriction on multi-threading, so I wouldn't lose sleep over that. The OpMode pattern holds true for both Autonomous and Teleop. The idea is that you will start the appropriate opmode at the beginning of each game segment.