Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Java (http://www.chiefdelphi.com/forums/forumdisplay.php?f=184)
-   -   Command based code secan (http://www.chiefdelphi.com/forums/showthread.php?t=140211)

cpapplefamily 11-12-2015 14:47
Command based code secan
 
This is my first year helping a team with some robot code. We are focusing on the command base robot model. We would like to do some acceleration control and other timed loops. I'm familiar with Vex and have done similar control using while loop and using a wait instruction at the end to use as the time calculation. With the FRC system do i or can i use a loop and wait code or use the FRC periodic cycle? I may not be using the right term to describe what I'm looking for but I hope you understand and can direct me.

Thanks

notmattlythgoe 11-12-2015 14:54
Re: Command based code secan
 
Quote:
Originally Posted by cpapplefamily (Post 1511505)
This is my first year helping a team with some robot code. We are focusing on the command base robot model. We would like to do some acceleration control and other timed loops. I'm familiar with Vex and have done similar control using while loop and using a wait instruction at the end to use as the time calculation. With the FRC system do i or can i use a loop and wait code or use the FRC periodic cycle? I may not be using the right term to describe what I'm looking for but I hope you understand and can direct me.

Thanks
If you are using the command based structure then using long running loops and wait commands can be very detrimental. What you want to do is us the execute methods of your commands to the time. You can treat the execute method like it is the body of a loop.

cpapplefamily 11-12-2015 15:31
Re: Command based code secan
 
Quote:
Originally Posted by notmattlythgoe (Post 1511507)
If you are using the command based structure then using long running loops and wait commands can be very detrimental. What you want to do is us the execute methods of your commands to the time. You can treat the execute method like it is the body of a loop.
I understand enough that long loops would be bad in this environment. Do I use waits and loops in the execute method? Then use the isFinished() command or a condition of the loop to end the code. What happens the loop was running still when the execute method is called again and again. Or do I record the time since last execute to calculate my time sensitive code? most of the documentation I read is is the execute and isFinished is called "ABOUT" 50 times / sec or every 20ms.

This is not what I'm aiming for but simply put every 1 sec i want to add 10 to double myCounter

Code:

double myCounter = 0;

while(true){

  myCounter = myCounter + 10;
  wait(1000); //Wait 1 sec

}

notmattlythgoe 11-12-2015 15:35
Re: Command based code secan
 
Quote:
Originally Posted by cpapplefamily (Post 1511521)
I understand enough that long loops would be bad in this environment. Do I use waits and loops in the execute method? Then use the isFinished() command or a condition of the loop to end the code. What happens the loop was running still when the execute method is called again and again. Or do I record the time since last execute to calculate my time sensitive code? most of the documentation I read is is the execute and isFinished is called "ABOUT" 50 times / sec or every 20ms.

This is not what I'm aiming for but simply put every 1 sec i want to add 10 to double myCounter

Code:

double myCounter = 0;

while(true){

  myCounter = myCounter + 10;
  wait(1000); //Wait 1 sec

}
You would not want to put any loops or waits in the execute method and instead check the time there to see if you should add 10 to the counter.

cpapplefamily 11-12-2015 15:37
Re: Command based code secan
 
pseudo code

Code:
public class myCounterCommand extends CommandBase {

double myCounter;

  protected void initialize() {
      myCounter = 0;
  }
....
....
....

  protected void execute() {
      myCounter = myCounter + 10;
     
      wait(1000);
    }
or do I

Code:

...
...
  protected void execute() {
      while(true){
        myCounter = myCounter + 10;
     
        wait(1000);
      }
    }
here since the first called execute is not done will sequential calls be skipped?

here what happens the 49 times this execute is called when the wait is not done?


or do I

Code:

double lastScan,thisScan:
...
...
  protected void execute() {
   
      thisScan = *some clock value;

      if(thisScan < lastScan + 1000){

        myCounter = myCounter + 10;
        lastScan = thisScan;

      }

    }
Seems then we can only safely calculate with time values Greater than 20ms and could be of by +19ms

notmattlythgoe 11-12-2015 15:42
Re: Command based code secan
 
Quote:
Originally Posted by cpapplefamily (Post 1511525)
pseudo code

Code:
public class myCounterCommand extends CommandBase {

double myCounter;

  protected void initialize() {
      myCounter = 0;
  }
....
....
....

  protected void execute() {
      myCounter = myCounter + 10;
     
      wait(1000);
    }
or do I

Code:

...
...
  protected void execute() {
      while(true){
        myCounter = myCounter + 10;
     
        wait(1000);
      }
    }
here since the first called execute is not done will sequential calls be skipped?

here what happens the 49 times this execute is called when the wait is not done?
This will actually cause your entire robot to lock up for 1 second. A general rule of thumb when using the Command Based structure is to never use a wait().

Instead use a Date field to store the time and increment your count when the time has exceeded a second.

GeeTwo 11-12-2015 15:58
Re: Command based code secan
 
This one is closer:
Quote:
Originally Posted by cpapplefamily (Post 1511525)

or do I

Code:

double lastScan,thisScan:
...
...
  protected void execute() {
   
      thisScan = *some clock value;

      if(thisScan < lastScan + 1000){

        myCounter = myCounter + 10;
        lastScan = thisScan;

      }

    }
Seems then we can only safely calculate with time values Greater than 20ms and could be of by +19ms
but the comparison in the if statement should be ">" or ">=", not "<".

cpapplefamily 12-12-2015 01:04
Re: Command based code secan
 
< -- > Yep was quick pseudo code. I didn't put to much though into it. Are there timing charts that show how the different methods in a command react?

So the same is true with wait() and a while(true) loop that may never end that other commands would never be scheduled or executed?

notmattlythgoe 12-12-2015 09:46
Re: Command based code secan
 
Quote:
Originally Posted by cpapplefamily (Post 1511665)
< -- > Yep was quick pseudo code. I didn't put to much though into it. Are there timing charts that show how the different methods in a command react?

So the same is true with wait() and a while(true) loop that may never end that other commands would never be scheduled or executed?
That is correct. The Schedule that controls the commands in sequence not parallel. So if one command is stuck in the execute method then the other commands will never execute.

GeeTwo 12-12-2015 10:12
Re: Command based code secan
 
Quote:
Originally Posted by cpapplefamily (Post 1511665)
< -- > Yep was quick pseudo code. I didn't put to much though into it. Are there timing charts that show how the different methods in a command react?

So the same is true with wait() and a while(true) loop that may never end that other commands would never be scheduled or executed?
I am not familiar with any timing charts.

On the second question, the execute() command will be called repeatedly, so you should structure it to do its work in less time (preferably much less time) than the call periodicity. In particular, you should avoid system calls with indeterminate duration, such as object instantiation, and other activities which may trigger garbage collection. IIRC, we usually turn GC off, because as long as the code doesn't constantly declare and release variables, you won't burn through the heap in three minutes. If you could burn through it that quickly, you would almost certainly see it during practice sessions which run many times as long.

cpapplefamily 12-12-2015 20:30
Re: Command based code secan
 
1 Attachment(s)
All this input is great. When it comes right down to it, attempt to assure the methods completes before the next iteration of the command < 20ms. I maybe beating this to death but it must be predicable what would happen if the method was not complete on the next iteration like item 1 it initialize() was not complete would the execute() simply start in the first positive clock after it completed. Same with item 2 if the execute() was not complete would the isFinshed() still run and a new execute() start only after the previous finished on a positive clock cycle.

These timing charts are what I expect may happen. The last timing chart has not been discussed here but if the command is scheduled to run but has not finished. Would the end() method run and a new initialize() start?

In the PLC world I work with professionally if I have a periodic task that does not complete before the next period I get a minor error and that iteration is skipped nothing horrific happens only I loose a scan.

Joe Ross 12-12-2015 21:27
Re: Command based code secan
 
Your picture for #1 is correct, for that command only. #2 is not correct, because isFinished will not run while execute is still running. In addition, it will also delay the execution of every other command. You could think of it as there only being a single clock, and any command method can stretch the clock.

cpapplefamily 13-12-2015 23:58
Re: Command based code secan
 
1 Attachment(s)
Quote:
Originally Posted by Joe Ross (Post 1511814)
Your picture for #1 is correct, for that command only. #2 is not correct, because isFinished will not run while execute is still running. In addition, it will also delay the execution of every other command. You could think of it as there only being a single clock, and any command method can stretch the clock.
We are getting somewhere now. I shifted the isFinished() to after execute() completes and before the next iteration of execute(). Also attempted to depict the second command and how it would be effected by other commands methods taking longer than one period on the second part "Special Conditions". Take a look.


All times are GMT -5. The time now is 09:16.

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