Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   EasyC autonomous modes (http://www.chiefdelphi.com/forums/showthread.php?t=44749)

TubaMorg 25-02-2006 21:06
EasyC autonomous modes
 
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 25-02-2006 22:18
Re: EasyC autonomous modes
 
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 26-02-2006 00:59
Re: EasyC autonomous modes
 
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 26-02-2006 13:27
Re: EasyC autonomous modes
 
Quote:
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 26-02-2006 16:51
Re: EasyC autonomous modes
 
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 26-02-2006 17:14
Re: EasyC autonomous modes
 
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 26-02-2006 20:34
Re: EasyC autonomous modes
 
Quote:
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:
// 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 26-02-2006 21:00
Re: EasyC autonomous modes
 
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 26-02-2006 22:01
Re: EasyC autonomous modes
 
Quote:
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:
// 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 26-02-2006 22:32
Re: EasyC autonomous modes
 
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 26-02-2006 23:01
Re: EasyC autonomous modes
 
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 26-02-2006 23:25
Re: EasyC autonomous modes
 
Quote:
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.

Quote:
// 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 26-02-2006 23:31
Re: EasyC autonomous modes
 
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 27-02-2006 00:06
Re: EasyC autonomous modes
 
Quote:
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:
// 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 27-02-2006 00:54
Re: EasyC autonomous modes
 
That's it! And I agree, Brad's code passes the coolness (and elegance) test better than mine :]

BradAMiller 27-02-2006 08:34
Re: EasyC autonomous modes
 
All I can say is too cool, too elegant, and too late at night.

Thanks for fixing the example.

JJMax7 09-03-2006 15:15
Re: EasyC autonomous modes
 
Can't you also just put a couple of switches right on the robot using the digital in ports. That way they can be read right at the begining of autonomous mode. Rather than risking getting stuck. This is what my team plans on doing. Hopefully it won't have too many bugs to have to deal with.

Dillon Compton 09-03-2006 17:03
Re: EasyC autonomous modes
 
Quote:
Originally Posted by JJMax7
Can't you also just put a couple of switches right on the robot using the digital in ports. That way they can be read right at the begining of autonomous mode. Rather than risking getting stuck. This is what my team plans on doing. Hopefully it won't have too many bugs to have to deal with.
That should also be fine JJ- I prefer having the auton. mode set at the OI, but either way will work, provided the code is properly written.

Dad1279 09-03-2006 19:00
Re: EasyC autonomous modes
 
Quote:
Originally Posted by JJMax7
Can't you also just put a couple of switches right on the robot using the digital in ports. That way they can be read right at the begining of autonomous mode. Rather than risking getting stuck. This is what my team plans on doing. Hopefully it won't have too many bugs to have to deal with.
To keep it simple, and use only one port, we use a radio shack 6 position switch, with 5 resistors as dividers connected to an analog input on the RC.

Dillon Compton 06-04-2006 12:09
Re: EasyC autonomous modes
 
Hmm. I attempted to use the code on the first page, after all the bugs were worked out and all, and it wont display to my userbyte on the OI- any ideas?

TubaMorg 06-04-2006 17:43
Re: EasyC autonomous modes
 
Quote:
Originally Posted by Dillon Compton
Hmm. I attempted to use the code on the first page, after all the bugs were worked out and all, and it wont display to my userbyte on the OI- any ideas?
Well my final version worked ok so here it is:

Code:
while ( !IsEnabled() )
      {
            p4_trig = GetOIDInput ( 4 , 1 ) ;
            if ( p4_trig )
            {
                  if ( autoProgram < 8 )
                  {
                        autoProgram ++ ;
                  }
                  else
                  {
                        autoProgram = 0 ;
                  }
                  while ( p4_trig )
                  {
                        p4_trig = GetOIDInput ( 4 , 1 ) ;
                  }
            }
            SetUserDisplay ( autoProgram ) ;
      }
Uh, just to ask a dumb question: Did you switch the OI to u-mode? I'm sure you did, just checking though. Also make sure the variable "autoProgram" is set as a global unsigned char.

Kingofl337 07-04-2006 13:19
Re: EasyC autonomous modes
 
IS the OI set in the correct mode. Eg when you get set to user mode it should
first display u012 then u000 until you chage modes.

lynca 09-04-2006 11:24
Re: EasyC autonomous modes
 
When configuring globals to be either on or off (i.e. only two conditions) such as the "isEnabled" global mentioned above. You might want to instead use a

#define ISENABLED 1 // instead of defining a global

//later in the program put
#ifdef ISENABLED
//put autonomous code here
#endif

This page is a good tutorial on using MACROS, http://vergil.chemistry.gatech.edu/r...al/basic2.html

TubaMorg 09-04-2006 13:13
Re: EasyC autonomous modes
 
Quote:
Originally Posted by lynca
When configuring globals to be either on or off (i.e. only two conditions) such as the "isEnabled" global mentioned above. You might want to instead use a

#define ISENABLED 1 // instead of defining a global

//later in the program put
#ifdef ISENABLED
//put autonomous code here
#endif

This page is a good tutorial on using MACROS, http://vergil.chemistry.gatech.edu/r...al/basic2.html
Pretty good advice if not using EasyC, which is what this discussion is about.

P1h3r1e3d13 12-04-2006 01:06
Re: EasyC autonomous modes
 
I believe that all your creative solutions using !IsEnabled() are actually moot.

Input from the competition port overrides code loops. In other words, even if you have a while(1) in your autonomous code, when your dongle (or whoever's running the match) switches off autonomous, your code drops whatever it's doing, and the Operator Control code starts.

Our code has a while(1) in Autonomous() and it works fine. I can't remember if I've tried it in Initialize(), but I have every reason to think it should work the same. Still, test it with a dongle, just to be triple sure.


On the other hand, the simple way (the way I used) is to have a switch (or several, or an analog input as described above), set it before you power on the bot, and just read it once (no loops).

Dillon Compton 12-04-2006 22:53
Re: EasyC autonomous modes
 
The advantage to this is that it allows us to use the pre-existing joystick; something I much prefer. I got this working on last years robot, so it should be fine; no reason to mess with the safety measures in place- redundancy is my friend. I'd rather have something I know that I wrote backing it up than mystical field-happenings.

Thanks for the info, nonetheless.


All times are GMT -5. The time now is 23:05.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi