We are using a jumper in the digital input ports to select different autonomous modes. Because the slots and labeling are tiny, we thought it would be helpful to use LEDs to indicate which autonomous mode was selected (to see if we were plugged into the right slot). We were mystified as to why the LEDs were constantly lit when we were expecting them to be “off”, even though the correct autonomous routines would execute. Finally, it dawned on us that the light configuration would not display properly until autonomous mode begins. This defeats the purpose of the LED’s because we want to check the jumpering when we first turn on the robot, not after the match begins.
When we tried to insert code before the “autonomous” function in the EasyC template (v2 and v4), it would not allow us to do this.
Is there any way to activate a digital output before autonomous executes?
Yes. The trick is to have it in a loop, so that it constantly updates the LEDs during Initialize, but also have the loop exit when the robot goes into Autonomous mode. To do this, you would use something like:
#include "Main.h"
void Initialize ( void )
{
// Do NOT place infinite loops inside of your Initialize Function.
// If your Initialize Function never terminates, your program
// will never progress to Autonomous and Operator Control.
// See Help for more information about this function.
//
// (That's why we're checking for the loop to end with an 'IsEnabled()' function call ;-) )
// All your one time initialization code goes here, outside the loop
while ( IsEnabled () )
{
// All your repeating code (like checking jumpers and setting LEDs) goes here, inside the loop
}
}
The key here is to drag a ‘While Loop’ block in, and in the textbox after the ‘While (’, type in: IsEnabled ()
Thanks – it worked! We had previously used EasyCv2 extensively, which has no “initialize” function in the template. We only recently transitioned to v4 and had overlooked “initialize” completely (but won’t any more :)).
Forgot to mention that we didn’t even need a loop. We simply saved our digital inputs (where we plug in jumpers) to variables and output those variables to the digital outputs where our LED indicators are. It means that the code only executes once when the robot is first turned on (so inserting/removing jumpers with the robot already on doesn’t change the LEDs), but we actually prefer it that way, as it fits into our standard sequence for initializing the robot before each match. It also avoids the risk of an infinite loop where your robot is paralyzed if a certain condition isn’t met.
That is a good point. We did the same thing for ours last year with a potentiometer; that way, when we started the robot, the potentiometer couldn’t accidentally get ‘bumped’ resulting in the wrong autonomous.
I don’t understand how this While (IsEnabled()) loop can work. As soon as the field is enabled, IsEnabled will be true, and the loop will execute. Then how will you exit the loop to start autonomous? Seems like you will always be in the loop.
OK. So now my question is: if I put code inside the loop that lights up LEDs, will they actually light up? In other words, what is the actual sequence at the start of a match from the time the team puts their robot down? (1) they turn it on. Does initialize start then? Or does the field have to be ‘turned on’ but not enabled? My understanding is that autonomous starts when the field is ‘enabled’. But something must happen before that to start the initialize mode on the field because it doesn’t happen outside the field when I turn the robot on in the pit.
I don’t know how Initialize in the RobotC template works, but in the EasyC template, commands inside Initialize begin executing as soon as you turn on the robot. To begin autonomous requires a switch or field trigger, but Initialize should execute when your turn your robot on in the pit.
What command do you have inside “Initialize”? If you’re using a digital output to light an LED, is it possible your logic is reversed (1 instead of 0) and “hiding” the fact that your code is actually executing?
Initialize is a bit weird in EasyC, it executes more than once when in competition mode. If you power up with the field control connected then the sequence is this
Power On → Initialize → Wait for field control enable
When the field control enable is received then either Autonomous or operator control will run. When field control disables the robot, Initialize will run again, in the usual situation of autonomous running first, when autonomous ends then initialize will run and then the program will wait for the next enable.
If the competition switch or field control is not connected, then initialize runs followed by operator control.
ROBOTC is a little different, the pre_auton function is called only once at power on, tasks can be started here but will be stopped after autonomous (although there is a new flag to disable this in versions 3.06 onwards). When I get around to it I will release an alternative competition template for ROBOTC that allows for additional functionality.
