EasyC autonomous modes

[TubaMorg]

It's after ship date now, but when we get to the regional, we want to program EasyC to select between various autonomous programs, depending on our starting position. We already wrote the various modes prior to ship, but didn't figure out how to select the proper one in EasyC. The old way, with MPLab and "default code" was to select your program after the robot is turned on and disabled, prior to Autonomous by setting a global variable to the appropriate value. From previous posts, it appears as if when the robot is powered up disabled, Initialize() is called then EasyC goes into a while loop until enabled. Am I getting this right? So neither OperatorControl() nor Autonomous() is called? I hope I am interpreting this incorrectly, because I am unsure where to put code that would read input from the OI while the robot is disabled awaiting Autonomous mode....

[TubaMorg]

I've been thinking about it.....

Could we put a while loop in Initialize() like this:

while (!IsEnabled())
{
// capture OI input for auto program
}

So when the robot is turned on and disabled, it will stay in the loop, listening to the OI. When enabled, the Autonomous will be called with the correct program hopefully.

[Dillon Compton]

Shouldent you be able to just call the OperatorControl() function in initialize? Unless I am mistaken, you should be able to stick that in the initialize function and access the OI input that way.

[TubaMorg]

Originally Posted by Dillon Compton

Shouldent you be able to just call the OperatorControl() function in initialize? Unless I am mistaken, you should be able to stick that in the initialize function and access the OI input that way.

Hmmm that might work, too. I guess we will have to try it at competition. Another less desireable alternative is to just set the Autonomous program we want in the code and compile and upload. This will only work if we have time to consult with our alliance partners before we leave the pits pre-match, though. Baaahh, I wish we figured this out before we shipped, but all of our effort was focused on finishing the robot.

[intelitek_Chris]

Good Question!

There are probably many ways to do this (select between multiple autonomous programs). Here is one of many possible suggestions.

Have a series of switches that form a binary number (like the channel selection on your OI). If you had 3 switches, all off, for example, you would have program 1 selected. If the switches were all on, program 8 would be selected.

In your easyC code, have Initialize stuck in a loop, waiting for somekind of input from the controls (say Button BB). When you have all your switches set correctly (this can be after the robot has been placed on the field), press button BB. This will set a variable, say 'AutProg' to a number, as designated by your switches, and exit the loop in Initialize. Now, when the match starts, your autonomous function will immediately begin running the program that corresponds to the variable 'AutProg', and begin running the program.

If you ever have to reset the robot for any reason (from the OI), you can jump out of initialize by pressing the button BB. You won't run any autonomous code, because the field control will be in Operator Control (and the autonomous flag will be off), but this way you will have direct control over how long the initialize function stays looping (it will loop until you hit button BB).

You could do all of this with a single button, if write enough code, and don't have multiple switches. Just set some timers up to record times between button presses, and create a code for entering in which autonomous program to use. Hope this helps!

[TubaMorg]

Thanks, that really does help. Or at least it eases my worries Right now we were thinking of having:

while ( !IsEnabled() )
{
p4_trig = GetOIDInput ( 4 , 1 ) ;
if ( p4_trig )
{
if ( autoProgram < 6 )
{
autoProgram ++ ;
}
else
{
autoProgram = 1 ;
}
SetUserDisplay ( autoProgram ) ;
while ( p4_trig )
{
}
}
}

This would be in our initialize loop. This should work right? The idea being that the only time we will be setting the Autonomous program will be while the robot is in disabled mode. We plan on just using a joy plugged into port 4 to cycle between 6 programs. The program number should show up in user display I hope. So even if the RC needs to be reset during the match, since the field is enabled the autonomous selection code above won't even run right?

[BradAMiller]

Originally Posted by TubaMorg

Thanks, that really does help. Or at least it eases my worries Right now we were thinking of having:

while ( !IsEnabled() )
{
p4_trig = GetOIDInput ( 4 , 1 ) ;
if ( p4_trig )
{
if ( autoProgram < 6 )
{
autoProgram ++ ;
}
else
{
autoProgram = 1 ;
}
SetUserDisplay ( autoProgram ) ;
while ( p4_trig )
{
}
}
}

This would be in our initialize loop. This should work right? The idea being that the only time we will be setting the Autonomous program will be while the robot is in disabled mode. We plan on just using a joy plugged into port 4 to cycle between 6 programs. The program number should show up in user display I hope. So even if the RC needs to be reset during the match, since the field is enabled the autonomous selection code above won't even run right?

Here's another example of setting the autonomous mode. Each time you click the joystick trigger, the mode increases by one. In this case there are 5 modes so the MOD (%) operator limits the modes to have values from 0 - 4.

This code can be placed at the end of the initialize function - and just continues to run waiting for either autonomous or operator control to start. That way the robot is continuously allowing the mode to be set right up to the start of the match. There is no need to check if the robot is enabled.

// code sample from EasyC (or WPILib)
void Initialize ( void )
{
      unsigned char mode = 0; 

      while ( 1 )
      {
            while ( GetOIDInput(1,1) == 0 )     // wait for the trigger
            {
            }
            mode++ ;                            // increment mode
            while ( GetOIDInput(1,1) == 1 )     // wait for trigger release
            {
            }
            mode %= 5 ;                         // make sure mode < 5
            SetUserDisplay ( mode ) ;           // put mode in LED for feedback
      }

[TubaMorg]

That is pretty slick. My only concern was/is that the code would be stuck in Initialize() in the while(1) loop, but from what you said this isn't true? So say we start the robot up normally for testing with our dongle set to enable and manual (OperatorControl). Initialize is called first, but how does it get out of the while loop and continue on to OperatorControl? Similarly, during competition, how does the program know when Initialize is done if it's always in the while loop in Initialize()?

[BradAMiller]

Originally Posted by TubaMorg

That is pretty slick. My only concern was/is that the code would be stuck in Initialize() in the while(1) loop, but from what you said this isn't true? So say we start the robot up normally for testing with our dongle set to enable and manual (OperatorControl). Initialize is called first, but how does it get out of the while loop and continue on to OperatorControl? Similarly, during competition, how does the program know when Initialize is done if it's always in the while loop in Initialize()?

You are correct... I don't know what I was thinking.

How's this:

// code sample from EasyC (or WPILib)
void Initialize ( void )
{
      unsigned char mode = 0; 

      while ( !IsEnabled() )
      {
            while ( GetOIDInput(1,1) == 0 )     // wait for the trigger
            {
            }
            mode++ ;                            // increment mode
            while ( GetOIDInput(1,1) == 1 )     // wait for trigger release
            {
            }
            mode %= 5 ;                         // make sure mode < 5
            SetUserDisplay ( mode ) ;           // put mode in LED for feedback
      }
}

Thanks for pointing out the error!

The only other thing with this method is making sure that the field doesn't become enabled before the operator is finished incrementing the mode to the right value. Otherwise, autonomous will start with some intermediate setting.

[TubaMorg]

Great! Now it is 100% cool I will add this on to the ole to-do list for competition.

Hopefully the driver will set the auto program and back away behind the line before the field is enabled. Of course if anything goes wrong it ALWAYS operator error and not the program's fault.

Thanks for all the help this season. Yall have always been very timely in your responses to any EasyC questions!

[TubaMorg]

Uh...hate to be a wet blanket, but for others that are looking at this I just thought of another problem with your snippet. Won't the INNER while loops also cause the program to stick in Initialize()? Say the operator sets the auto program he wants then backs away, then the code sits here in:

while ( GetOIDInput(1,1) == 0 ) // wait for the trigger
{
}


Right? The only way to escape to the outside loop is to press the trigger again after the field is enabled (not allowed).

[Dillon Compton]

Originally Posted by TubaMorg

Uh...hate to be a wet blanket, but for others that are looking at this I just thought of another problem with your snippet. Won't the INNER while loops also cause the program to stick in Initialize()? Say the operator sets the auto program he wants then backs away, then the code sits here in:

while ( GetOIDInput(1,1) == 0 ) // wait for the trigger
{
}


Right? The only way to escape to the outside loop is to press the trigger again after the field is enabled (not allowed).

Would this work (changes in red)? If I am not mistaken, this will break you out of the inner loop as soon as the field is enabled, eliminating the infinite loop type issue.

// code sample from EasyC (or WPILib)
void Initialize ( void )
{
unsigned char mode = 0;

while ( !IsEnabled() )
{

while ( GetOIDInput(1,1) == 0 && !IsEnabled())// wait for the trigger, but only if the field is disabled
{
}
mode++ ; // increment mode
while ( GetOIDInput(1,1) == 1 ) // wait for trigger release
{
}
mode %= 5 ; // make sure mode < 5
SetUserDisplay ( mode ) ; // put mode in LED for feedback
}
}

[TubaMorg]

I was thinking that, too, which will certainly get you out of Initialize(). The only problem with that, though, is that the mode counter increments 1 more, taking you off the program you set. I'm thinking my original sample is the answer, although if you like the %= (which is pretty slick) you could substitute that for my way of counting.

[Dillon Compton]

Originally Posted by TubaMorg

I was thinking that, too, which will certainly get you out of Initialize(). The only problem with that, though, is that the mode counter increments 1 more, taking you off the program you set. I'm thinking my original sample is the answer, although if you like the %= (which is pretty slick) you could substitute that for my way of counting.

Yea...you are probably right on this one, i'll give you that.

But for the sake of argument (and because I like the way Brad's code is layed out more[no offense]), I think this might work...

// code sample from EasyC (or WPILib)
void Initialize ( void )
{
      unsigned char mode = 0; 

      while ( !IsEnabled() )
      {
            while ( GetOIDInput(1,1) == 0 && !IsEnabled() ) 
            // wait for the trigger, but only if the field is disabled.
            {
            }

	    if ( !IsEnabled() )
	    {
           	 mode++;      // increment mode  
            }
         
            while ( GetOIDInput(1,1) == 1 )     // wait for trigger release
            {
            }

            mode %= 5 ;                         // make sure mode < 5
            SetUserDisplay ( mode ) ;           // put mode in LED for feedback
      }
}

[TubaMorg]

That's it! And I agree, Brad's code passes the coolness (and elegance) test better than mine