When Autonomous is over, will easyC Pro stop sensors (encoders, sonar, etc) automatically?
Everything you have going in the Autonomous block will stop, but anything in Initialize will still be going, and the Operator block will begin. The code will essentially restart.
So if you started the sensor in Autonomous, it will stop.
The sensor itself doesn’t generally stop what it’s doing, it’s just that your program will ignore it.
Some sensors that rely on the code to tell them when to send out a Ping for example, will just sit quietly waiting.
So if the quadrature encoders start an interrupt routine, I don’t have to worry about it stealing overhead from the operator control? Interrupts will be stopped?
If you use Optical Quad Encoder in Autonomous, the interrupts [edit]will[/edit] continue in Operator.
However, I think I’ll go test that to be sure some other EasyC behavior isn’t cropping up…
PPS: It’s going to depend on how the WPILIB kernal is setup, so restarting the user process may leave the interrupts running. I’ll test it when I get near a controller and report back.
PPSS: Background processes do continue between the Autonomous & Operator blocks.
I checked and the kernal does maintain the interrupt schedule created in the Autonomous block.
Sorry for the misinformation.
So to answer your question, you will have to stop the Quad Encoder as your first step in the Operator block.
Put the call before the while(1) loop, as it only needs to be called once.
This’ll be true for any of the sensor commands with a “Stop” option (Encoder, Gear tooth, Ultrasonic, Gyro, Accelerometer, Interrupt Watcher).
Thank you. I had a feeling I would need to stop these sensors.
Edit… I know there is a 'while(1) loop in the default IFI code, but don’t see while(1) loop in EasyC OperatorControl…???
A while(1) isn’t absolutely necessary in the Operator block.
I just teach the students to use one, so they can use the beginning of Operator for initialization, then follow that with a while(1) to do the repeating part of their processing.
You should use a while(1) in operator control as the looping behavior was not intentional on our part and more a function of WPILIB. EasyC V2 doesn’t use WPILIB, and doesn’t loop in operator control for competition templates in Vex which could lead to a headache if you don’t get in the habit.
To answer your question about switching from Autonomous to OperatorControl, here’s what happens:
When you put the robot on the field and turn it on (or anytime you reset it), your Initialize() function runs from the start to completion. If there are sensors like gyros that are initialized in the Initialize function, they will completely initialize. This can take a few seconds to complete, so if you reset the robot in the middle of a match you might see this delay before the robot starts driving again.
When the match starts and hybrid mode starts, your Autonomous() function will start running. Your Autonomous() function will either run to completion or…
When the field switches to tele-operation, your Autonomous() function will be interrupted (stopped), and the OperatorControl() function starts executing. As was said, you would typically put a while (1) loop in there to repeatitively read controls and send values to motors.
The switching from Autonomous to OperatorControl is automatic and you don’t have to do anything to make it happen. Any background processing of sensors that you start in Autonomous or Initialize will continue until you explicitly stop it. Background processing starts whenever you do a Startxxx function on a sensor. For example StartGyro causes the code for the Gyro to automatically start polling it and computing headings in the background. You don’t have to do anything else to make it work. The reason the background stuff doesn’t stop between Autonomous and OperatorControl is so teams that want to use the Gyros and Cameras in their operator control programs won’t have to wait for them to reinitialize at the start of the OperatorControl() function.