Command based code secan

Technical Java
1

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

2

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.

3

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



double myCounter = 0;

while(true){

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

}
4

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.

5

pseudo code


public class myCounterCommand extends CommandBase {

double myCounter;

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

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

or do I



...
...
   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



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

6

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.

7

This one is closer:

but the comparison in the if statement should be “>” or “>=”, not “<”.

8

< – > 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?

9

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.

10

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.

11

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.

Command Period 2.JPG
Command Period 2.JPG715×744 88 KB



Command Period 2.JPG
Command Period 2.JPG715×744 88 KB

12

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.

13

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.

Command Period 3.JPG
Command Period 3.JPG1224×763 135 KB



Command Period 3.JPG
Command Period 3.JPG1224×763 135 KB

14