OI Input Autonomous

[Ultima]

What our team is trying to do this year is to select our Autonomous mode by using the joystick buttons or some other type of button mounted on our control box. While searching Chief Delphi forums for possible solutions we have stumbled upon this code:

It's written by Kevin Watson. We used a slightly modified version of it.

Quote:
void auton_selector(void)
{
static char last_sw1;
static char last_sw2;

if(AUTON_UP == 1 && AUTON_UP != last_sw1)
{
if(auton_select < MAXAUTONROUTINES)
auton_select++;
else
auton_select=99;
}
if(AUTON_DN == 1 && AUTON_DN != last_sw2 && auton_select > 0)
{
if (auton_select == 94)
auton_select=MAXAUTONROUTINES;
else
auton_select--;
}
last_sw1 = AUTON_UP; //oneshot the trigger and top buttons
last_sw2 = AUTON_DN;

User_Mode_Byte = auton_select;

}
User_Mode_Byte is the user display on the OI. Use that little button to change to it.

AUTON_UP/DOWN are the defines to which a joystick button or something similar.

Now we are stumped as we are unable to make this code work for us. First of all we are unsure in which of the program files should we put this function into. Second of all when we tried simply pasting this code into our user_routines.c or user_routines_fast.c functions the compiler came out with a bunch of errors. Can anyone take a look and maybe guide us to a solution if possible. Thanks in advance!

[esquared]

Hmm, why would anyone want to select autonomous modes from the OI... :cool:

A better question is, will the drivers need to step back from the OI BEFORE the refs move the rack?

[Ricky Q.]

Hmm, why would anyone want to select autonomous modes from the OI... :cool:

A better question is, will the drivers need to step back from the OI BEFORE the refs move the rack?

I'd guess not, but I'm sure it can be asked on the Q&A, this is the closest I've found.


<G45> TEAM members over the PLAYER'S LINE during AUTONOMOUS PERIOD - No TEAM member may pass the PLAYER'S LINE in the ALLIANCE ZONE until the conclusion of the AUTONOMOUS PERIOD. Each violation will result in a 10-point penalty to the offending ALLIANCE. Exceptions will be made in cases involving personal or robot control safety.


Many teams have selected auton on the OI for years, seeing it as better than putting switches on the robot.

[Alan Anderson]

Put that snippet of code in user_routines.c and call it from the same place you're reading the joysticks for other purposes. Default_Routine(), perhaps.

Your compiler errors are probably because you didn't get the hint to replace AUTON_UP and AUTON_DN with the actual OI controls you will be using to step the number up and down. p1_sw_trig and p1_sw_top, for example. You will also have to declare auton_select as a global variable so you can use it in your actual autonomous routine.

[Ultima]

I have a few questions. Well first of all I edited the code and this is what it looks like now as I try to compile:

void auton_select(void)
{
static char last_sw1;
static char last_sw2;

if(p1_sw_trig == 1 && p1_sw_trig != last_sw1)
{
if(auton_select < 2)
{
auton_select++;
}
else
{
auton_select=99;
}
}
if(p1_sw_top == 1 && p1_sw_top != last_sw2 && auton_select > 0)
{
if (auton_select == 94)
{
auton_select= 2 ;
}
else
{
auton_select--;
}
}
last_sw1 = p1_sw_trig; //oneshot the trigger and top buttons
last_sw2 = p1_sw_top;

User_Mode_Byte = auton_select;
}


Second of all, how would I got about declaring auton_select as a global variable, and third I would need to get around the following errors:

C:\2007 arm code\FrcCode2005v2.4\user_routines.c:661:Error [1128] compatible scalar operands required for comparison
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:663:Error [1147] scalar type expected for increment operator
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:667:Error [1131] type mismatch in assignment
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:670:Error [1128] compatible scalar operands required for comparison
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:672:Error [1128] compatible scalar operands required for comparison
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:674:Error [1131] type mismatch in assignment
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:678:Error [1148] scalar type expected for decrement operator
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:684:Error [1105] symbol 'User_Mode_Byte' has not been defined
C:\2007 arm code\FrcCode2005v2.4\user_routines.c:684:Error [1101] lvalue required

The code is from 2005 since we are just testing our prototype arm with the 2005 controller.

[Alan Anderson]

Well first of all I edited the code...

You made the name of the function the same as the name of the variable it's trying to set. That's what most of your compiler errors are about. You should probably change it back to auton_selector the way it was in the example. You also misspelled User_Mode_byte with a capital B.

To declare a global variable, do it at the top of user_routines.c where it says DEFINE USER VARIABLES AND INITIALIZE THEM HERE.

Oh, and I believe there was a typo in the example code. It looks like the 94 ought to be 99 instead.

[Ultima]

Thanks so much for your help so far. We have managed to get the code up and running displaying the numbers on the OI, however anytime I try to get a value from auton_select in my Autonomous Mode I keep getting

C:\2007 arm code\FrcCode2005v2.4\user_routines_fast.c:154:Erro r [1105] symbol 'auton_select' has not been defined
C:\2007 arm code\FrcCode2005v2.4\user_routines_fast.c:154:Warn ing [2058] call of function without prototype

even though I have defined auton_select in user_routines.c as so


/*** DEFINE USER VARIABLES AND INITIALIZE THEM HERE ***/
#if _USE_CMU_CAMERA
#include "user_camera.h"

int auton_select;

Any solution for this problem? Thanks in advance!

[Mark McLeod]

Add this at the top of user_routines_fast.c to tell the compiler that auton_select is created in another file.

extern int auton_select;

[Ultima]

C:\2007 arm code\FrcCode2005v2.4\user_routines_fast.c:137:Warn ing [2058] call of function without prototype

Keep getting this warning, is it important or not really?

P.S. - Got it working HOWEVER I still have one more question. When the robot is disabled through the competition port it refuses to change the autonomous mode. Will our team have to change autonomous modes before we come to the player stations.

[kaszeta]

P.S. - Got it working HOWEVER I still have one more question. When the robot is disabled through the competition port it refuses to change the autonomous mode. Will our team have to change autonomous modes before we come to the player stations.

If the competition switch is set to manual (non-autonomous) and disabled, you should still be able to read the OI settings.

[Michael DiRamio]

Keep getting this warning, is it important or not really?

P.S. - Got it working HOWEVER I still have one more question. When the robot is disabled through the competition port it refuses to change the autonomous mode. Will our team have to change autonomous modes before we come to the player stations.

It's important. It means you're calling a method that doesn't exist. Check your spelling on that line. Remember that method names are case sensitive.

[Dave Scheck]

It's important. It means you're calling a method that doesn't exist. Check your spelling on that line. Remember that method names are case sensitive.Either that or you're calling a function before it is declared. This code will generate the warningvoid void main()
{
func();
}

void func()
{
}From the compiler's point of view, it doesn't know that func exists when it parses through main and thus throws the warning.

Here are two ways to get rid of the warning. I prefer the first method.

1. Create a function prototype either at the top of the C file or in a header included by that C file. This will tell the compiler that a function named func that takes no inputs and returns nothing is defined somewhere in the code.void func(void); /* Here is the prototype */

void main()
{
func();
}

void func()
{
}
2. Write your function before you call it. In this case, the compiler will parse through the function and know about it by the time it gets to the call.
void func()
{
}

void main()
{
func();
}
I highly suggest that you get in the habit of dealing with warnings as they pop up so that they don't get lost in the shuffle and manifest themselves into a problem.

[pheadxdll]

I thought the Master code didn't allow any data transfer between the OI and the RC during autno mode.

[kaszeta]

I thought the Master code didn't allow any data transfer between the OI and the RC during autno mode.

It doesn't. But when the robot is on the field before the match, it isn't in autonomous mode, but it is disabled.

In this state, you can do just about anything except set any outputs on the RC (you can read inputs on the RC and the OI, and save these for when you start autonomous mode).

[Astronouth7303]

In this state, you can do just about anything except set any outputs on the RC (you can read inputs on the RC and the OI, and save these for when you start autonomous mode).

Close - You can set outputs, but they don't actually make it to the pins.

This is an important distinction when debugging. The dashboard displays the PWM values, even when you're disabled. This is useful if you don't want your arm to swing wildly.

[/nit pick]

[kaszeta]

Close - You can set outputs, but they don't actually make it to the pins.

A useful nitpick. I use this very technique to demonstrate how the drive train feedback loop works every year, and how you can make sure the values are correct before enabling it.

[Tt321b]

I like that code that you found and i tried using it in our code but I get a syntax error on the line that says:

void auton_selector(void)

I declared the global variable in user_routines.c and put the extern int in the user_routines_fast.c (both are in the correct places). I changed the AUTON_UP and AUTON_DN to buttons on the joystick. I changed the 94 to 99. I also checked the lines before it so see if I left out a ; or } but I did'nt.

I also got another syntax error when I try using auton_select in user_routines_fast.c to select the autonomous.


Thanks!

[TheRoche]

I thought the Master code didn't allow any data transfer between the OI and the RC during autno mode.

I thought this too, for the competition radio completely disconnects the RC and OI, so maybe do this when you are on the field, but the match has not started

[Mike Betts]

The RC and OI are always in communication with each other (as long as they are on and the radio link is good). The OI/RC master code determines what information is passed depending on the competition port state (disabled, autonomous, et cetera).

[AlmightyPiMan]

sorry for my lack of knowledge, i'm a rookie, but i don't get why a team would want to set a button for autonomous mode at all. isn't it controlled via the competition port and thus out of our hands? in the docs for the OI it says that if you jumper pins 5 and 8, it puts the bot into auto mode. i imagine that's what they do at the competitions, not have a team member push a button on the controller...

[Jim E]

Basically, you want to build a dongle to simulate autonomous mode for code testing. Yes, during the competition, the field controls autonomous, but you need the dongle to test out your code (if any) prior to getting there. It can be built with $5.00 of parts. It is VERY USEFUL to have. Do the right thing and build it. Do not forget the disable switch either. You never know when your code registers may carry over and find you robot going backwards at maximum speed when you least expect it.

[kaszeta]

sorry for my lack of knowledge, i'm a rookie, but i don't get why a team would want to set a button for autonomous mode at all. isn't it controlled via the competition port and thus out of our hands? in the docs for the OI it says that if you jumper pins 5 and 8, it puts the bot into auto mode. i imagine that's what they do at the competitions, not have a team member push a button on the controller...

You're confusing two (related) issues:

1. You can build a dongle or jumper the competition ports to test your autonomous mode during development. At the competition, you are correct, the competition port handles this.

2. Many teams have multiple autonomous strategies, or at least variations on strategies (for example, left- and right-handed versions of the same strategy for starting on that particular side of the field). Our team usually has a whole suite of strategies (eight last year, although only three of them turned out to be useful, plus a fourth we developed at the competition based upon experience), and we pick them right before the match in consultation with the rest of our alliance. Sometimes we also call an audible and change the strategy right at the last possible second. Of course, you can't change the code at this point, so you need a way to change which autonomous mode you're running, either from the robot (switches and pots hooked to digital or analog inputs), or from the OI (using the OI ports). The latter is what people are talking about here, ways of setting the autonomous strategy while the bot is disabled and the field is being set up, but before the match (and autonomous mode itself) starts.

Real example: Last year, our primary strategy was to drive towards the goal, line up, and shoot copious amounts of balls into the target. We had three versions of that strategy, with different amounts of distance to drive depending on which position we started from.

We also found that the other alliance would usually dedicate at least one bot into crashing into us during autonomous to either block us or mess with our aim, usually by dead-reckoning across the field. So we had a variant of the primary strategy that waited several seconds in our starting box before driving towards the goal and scoring (we scored very, very quickly, so we could afford to wait five seconds). This (usually) allowed the other team's defensive bot to drive right by, and we'd then move up and score. The decision on whether to drive directly at the goal or do the delayed version was decided by the drive team based upon how the other alliance lined up their bots: if they were obviously aiming to intercept us, we'd change strategies.