Chief Delphi
Page 1 of 2 1 2 >
Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Java (http://www.chiefdelphi.com/forums/forumdisplay.php?f=184)
-   -   Command Based Programming (Threads?) (http://www.chiefdelphi.com/forums/showthread.php?t=133549)

nathanzentner08 26-01-2015 21:11
Command Based Programming (Threads?)
 
I was under the assumption that when you used the a Command Group and added parallel that it would handle them as separate threads. I was testing this out with my group and when I put a Timer.delay in the execute method of one command, it held up all execution. Is this multi-threaded based? Are there other ways to run things within threads within the WPILibJ?

Arhowk 26-01-2015 22:18
Re: Command Based Programming (Threads?)
 
If you're using Timer.delay than you're fundamentally missing the purpose of the command based structure... essentially you should be split into three different parts (the code before the wait, the wait itself, and the code after the wait) and they should all be non-interruptive commands.

Ben Wolsieffer 26-01-2015 22:25
Re: Command Based Programming (Threads?)
 
Command-based programming is just an extension of iterative that makes it easier to schedule and trigger actions. It gives you most of the benefits of multithreading without the added complexity of worrying about deadlocks and race conditions.

All commands run in the same thread, so they can't ever block. When commands are run, they are added to a queue which the scheduler executes iteratively.

Ether 26-01-2015 22:25
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by Arhowk (Post 1434432)
they should all be non-interruptive commands.
What does "non-interruptive" mean?

TFleig78 26-01-2015 22:29
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by Ether (Post 1434439)
What does "non-interruptive" mean?
He probably meant interruptible.
From the wpilib website:

When a command is scheduled, the Scheduler checks to make sure that no other commands are using the same subsystems that the new command requires. If one or more of the subsystems is currently in use, and the current command is interruptible, it will be interrupted and the new command will be scheduled. If the current command is not interruptible, the new command will fail to be scheduled.

Ether 26-01-2015 22:43
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by Ether (Post 1434439)
What does "non-interruptive" mean?
Quote:
Originally Posted by TFleig78 (Post 1434440)
He probably meant interruptible.
You probably meant non-interruptible?

Quote:
Originally Posted by TFleig78 (Post 1434440)
If the current command is not interruptible, the new command will fail to be scheduled.
So if all the commands should be "non-interruptive", and non-interruptive means non-interruptible, then all new commands will fail to be scheduled if any command is presently running?

TFleig78 26-01-2015 22:59
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by Ether (Post 1434443)
You probably meant non-interruptible?



So if all the commands should be "non-interruptive", and non-interruptive means non-interruptible, then all new commands will fail to be scheduled if any command is presently running?
Yes, I meant non-interruptible.

And yes, the currently running command would have to end before any other command that requires the same subsystem could be scheduled. This is only true if you set the command's interruptible property to false.

gixxy 26-01-2015 23:03
Re: Command Based Programming (Threads?)
 
The way commands are run in the Command Based Structure are via a queue. The execute method of each scheduled command is executed in sequence (I assume in the order added to the queue). This means that each command's execute method shouldn't contain anything that will sleep the thread (delays) or otherwise tie the thread up for long periods of time (intensive camera calculations). Such actions will lead to decreased robot responsiveness.

There are many other ways to implement non-blocking timers, if you describe what it is you mean I can help point you in the right direction.

I believe by "non-interruptive" Arhowk meant non-blocking. As far as interrupts on a command, they are only used when a new command is added to the queue that uses the SAME subsystem as another queued command. So, if the first is not interruptible, the second command will not run, if it is, the first command will be interrupted and the second will take over. Command Interrupts do not refer to commands using different subsystems in any way.

Ether 26-01-2015 23:20
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by gixxy (Post 1434452)
I believe by "non-interruptive" Arhowk meant non-blocking.
@Arhowk: is that what you meant?

Arhowk 27-01-2015 06:44
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by Ether (Post 1434458)
@Arhowk: is that what you meant?
yes... :( by non-interruptive, I meant code that does not engage the use of the java stall commands (Timer.delay, Object.wait, Thread.sleep)

notmattlythgoe 27-01-2015 08:43
Re: Command Based Programming (Threads?)
 
The way the Command Based Structure is designed is to keep a list of all currently running commands. Every ~20ms each of these commands will be executed one at a time. Each of the commands should be designed to execute very quickly so it does not delay the execution of the other commands that are being executed. This means, if you delay the execution by some means this will cause the other commands after it in the list to wait on the delayed command.

nathanzentner08 27-01-2015 09:18
Re: Command Based Programming (Threads?)
 
Our thought was to have an image processing Command, that would have taken a bit more time and processing power, that ran in a parallel Command Group, but since it isn't really parallel, then the main thread would be stuck in the Image Processing command until it returned.

This non-threaded functionality could affect our driving (Essentially Everything) because if the thread is working on image processing then it is not available to change speed on our motors. (This is just a simple example.)

Im coaching the team and talking about parallel processing and trying to show an example based on the API that is given. The more I work with it, the more I find it isn't really there.

It's alright that it is not in there, but the documentation says:

"... instead of waiting for the child to finish, a CommandGroup will have it run at the same time as the subsequent Commands. ..."

notmattlythgoe 27-01-2015 09:25
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by nathanzentner08 (Post 1434580)
Our thought was to have an image processing Command, that would have taken a bit more time and processing power, that ran in a parallel Command Group, but since it isn't really parallel, then the main thread would be stuck in the Image Processing command until it returned.

This non-threaded functionality could affect our driving (Essentially Everything) because if the thread is working on image processing then it is not available to change speed on our motors. (This is just a simple example.)

Im coaching the team and talking about parallel processing and trying to show an example based on the API that is given. The more I work with it, the more I find it isn't really there.

It's alright that it is not in there, but the documentation says:

"... instead of waiting for the child to finish, a CommandGroup will have it run at the same time as the subsequent Commands. ..."
It will run it similar to how commands for different subsystems would run at the "same time". If you execute method takes a long time to execute it will slow everything else down.

Last night we created a separate thread that will run our vision processing so it doesn't slow down the processing of commands. I can assist you with this if you'd like.

Ether 27-01-2015 09:50
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by notmattlythgoe (Post 1434582)
If you execute method takes a long time to execute it will slow everything else down.
Within the command-based architecture, what is the recommended way to implement a delay (for example, in a firing sequence).

notmattlythgoe 27-01-2015 09:58
Re: Command Based Programming (Threads?)
 
Quote:
Originally Posted by Ether (Post 1434594)
Within the command-based architecture, what is the recommended way to implement a delay (for example, in a firing sequence).
I would suggest using a WaitCommand in a CommandGroup. Below is an example that will fire, then wait 1 second before firing again and then finishing the CommandGroup.

Code:
public FiringCommandGroup extends CommandGroup {

    public FiringCommandGroup() {
          addSequential(new FireCommand());
          addSeqiential(new waitCommand(1));
          addSequential(new FireCommand());
    }
}
Another way to do it would be to check the time passed in the execute method of a command to see if the period of time you want to wait has passed.

Commands also have a timeSinceInitialixed() method that will return the time in seconds since the command was initialized(aka started). This could be used to check to see if a command has been running for a certain period of time.


All times are GMT -5. The time now is 12:55.
Page 1 of 2 1 2 >
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi