threads

[Inventer bots]

How do I thread a method?

[FTC4160]

This question makes me strongly recommend you stay away from threads.

1) You don't "thread a method", though you can create a thread from a method
2) Before using threads, you should have a VERY GOOD REASON for doing so

In fact, I'm not even going to tell you how to make a thread until you demonstrate you have a good reason to use one.

[skatefriday]

Google is your friend if you want to learn about Java threads.

There's an old joke in the software world, "Some people, when confronted with a problem, think “I know, I'll use threads.” Now they have two problems."

However if you describe what you are trying to achieve from a functional perspective, there are lots of people on the list who can help you with that.

[Inventer bots]

This question makes me strongly recommend you stay away from threads.

1) You don't "thread a method", though you can create a thread from a method
2) Before using threads, you should have a VERY GOOD REASON for doing so

In fact, I'm not even going to tell you how to make a thread until you demonstrate you have a good reason to use one.

Google is your friend if you want to learn about Java threads.

There's an old joke in the software world, "Some people, when confronted with a problem, think “I know, I'll use threads.” Now they have two problems."

However if you describe what you are trying to achieve from a functional perspective, there are lots of people on the list who can help you with that.

Our robot has a catapult and it is slow, so I wont to thread the code for the catapult allowing us to be able to launch a ball and drive while the catapult is being reset. It needs to be in a thread so we can launch two balls in autonomous and when the second ball has been launched, the robot can drive while the catapult is being puled down.

I know how to do it in C, but not Java.

[Ollie]

You don't need a thread for that. A set of Finite State Machines can work completely in parallel.

[skatefriday]

What Ollie says is true. And I think it's easiest to conceptualize if you use the iterative opmode style and think of the underlying SDK as a scheduler and loop() as your timeslice where you get to do some work. Throw out the notion that the SDK itself is an event-based system. That's completely misleading. It's a scheduler, and you get to do some work every time you get a bit of time through the call to loop(). If you then structure your software something like...

void loop() {
    doCatapultWork();
    doDriveWork();
}

...then those two work items will, for all intents and purposes, appear to be happening in parallel.

[FTC4160]

For this specific use case, I wouldn't even bother doing what skatefriday suggested. We also have a catapult which cycles, and it is entirely asynchronous because we are using RUN_TO_POSITION mode on a motor. If we want to cycle it, we set the target to the appropriate level - after that, we don't have to do anything, and can execute our other code (such as movement).

[skatefriday]

For this specific use case, I wouldn't even bother doing what skatefriday suggested. We also have a catapult which cycles, and it is entirely asynchronous because we are using RUN_TO_TARGET mode on a motor. If we want to cycle it, we set the target to the appropriate level - after that, we don't have to do anything, and can execute our other code (such as movement).

This works also.

[Inventer bots]

I need to have the catapult in a thread, so we can use it in autonomous. Heirs our code

void StartCatapultCycle() throws InterruptedException {
        catapultIdle = false;
        catapult.setMode(DcMotor.RunMode.RUN_WITHOUT_ENCODER);
        catapult.setPower(1.0);
        while (catapultCalibrate .isPressed()){} // do nothing!!
        // sleep(1000);
    }
    void EndCatapultCycle() throws InterruptedException {
        if (!catapultIdle) {
            catapult.setPower(0.0);
            loadBall(); // load the ball onto the catapult arm
            catapultIdle = true;
        }
    }
    void loadBall() throws InterruptedException {
        ballPusher.setPosition(0.0);
        sleep(500); 
        ballPusher.setPosition(1.0);
    }

In autonomous when we call "startCatapultCycle()" the robot will can not do anything until the catapult arm has pressed "catapultCalibrate" (that takes three seconds more time than we have). In teleop, when we launch a ball, and we are driving (I don't know why...) the robot will not respond when "loadBall" is running.

[skatefriday]

What does "catapultCalibrate.isPressed()" mean in the context of autonomous?

[skatefriday]

Oh, I presume that is tracking a limit switch? Is that backwards though which is what threw me off to begin with. Note, this is half the problem of posting snippets of code.

[Inventer bots]

What does "catapultCalibrate.isPressed()" mean in the context of autonomous?

"catapultCalibrate" is not a very good name, but it is a button that is mounted under the catapult. When the catapult is down, it is pressed.

[msonnier]

Google is your friend. There are many easily found sources with tutorials and simple examples of using threads in java. Oracle has one posted at http://docs.oracle.com/javase/tutori...l/concurrency/ that is pretty straightforward. Look at the Runnable interface...

While I agree with the point that usually using threads causes more problems than it solves, most of the issues around threads relate to problems where different threads have to interact with each other -- for example issues with accessing shared variables or memory. In some robotics cases, where you are dealing with totally separate subsystems, there are no dependencies between the different threads so most of the complex timing issues don't exist. Take a look at the section on Synchronization in the referenced link which covers many of the common pitfalls on threaded code. Generally you can avoid most of the pitfalls by having your separately threaded code not use ANY shared/global variables. Further, you will want to make sure no other code is manipulating the same physical resources as the threaded code (i.e. control the catapult reload motor from nowhere else).

Looking at your code, I do however see one MAJOR problem with the code you propose threading -- you should NEVER have an empty while loop {} in any of your code, but especially in multi-threaded code. That empty while loop will hog 100% of the CPU while executing and not "share" resources with other tasks. You need to put a sleep() or idle() or similar inside the loop to make sure other threads and tasks "get a fair share".

Further, whether you put that code inside a thread or not, your while loops (pretty much throughout your code) need to check the robot status (e.g. opModeIsActive() ) so that your thread/action will stop promptly when someone hits stop on the driver station or there is some anomalous event that causes a stop. THIS IS A SAFETY ISSUE!

I do agree with other posters you should consider all other avenues before resorting to threads -- but if you are going to try it hopefully this info is helpful... Good luck.