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