Despite what IFI says, you can configure autonomous from OI...

[TedP]

I've noticed a lot of robots building special inputs onto their robots connected to the digital ports on their RCs in order to configure their autonomous mode. They do this because they can't "see" the OI during autonomous mode and thus these configuration utilities can't be put on the OI.

However, if you're smart about it, there's no need to add additional hardware to your RC just to configure autonomous mode. Personally, I'd much rather have delicate electronics on my OI than my RC...

Remember that the OI *can* be heard while disabled. That is, all "disabling" the robot does is to disable the sattellite processors that actually do the work communicating with the relays and the speed controllers. However, as far as the robot is concerned, it's not disabled at all -- it's running fine. It even sees all the input changes on the robot. This is useful for debugging -- the robot can still respond to OI inputs and produce output on the program port even though it won't drive any outputs.

All robots start disabled and then move into autonomous mode. During this disabled time, simply sample the state from your OI and store that somewhere where it won't be touched. When it moves into autonomous mode, read from that the proper state of the autonomous mode. You've now configured your RC from the OI.

I ran this by the IFI guy at our regional, and he was skeptical. Then he saw our robot work during the next match while being configured from the OI and not the RC; this was apparently news to him.

We did the same thing last year with our Stamp-based RC. In both cases, as long as you pay attention during disabled mode, keep some memory, and only pay attention to the memory during autonomous mode, you can configure autonomous mode from the OI.

I'm sure some people are very familiar with that trick, but a lot of people I ask are still convinced that the RC is the only way.

[KenWittlief]

great idea - students have a difficult time remembering to set auton switches while they are planting the bot on the field

one important thing - if you are going to use the competition_mode flag to determine when you are disabled, the documentation from IFI is WRONG!!

competition_mode = 0 when the bot is enabled

competition_mode = 1 when the bot is disabled

( I sat up half the night at cleveland staring at my code trying to figure out why it wasnt working right. ^ turned out to be the reason).

[MikeDubreuil]

Originally Posted by KenWittlief

great idea - students have a difficult time remembering to set auton switches while they are planting the bot on the field

one important thing - if you are going to use the competition_mode flag to determine when you are disabled, the documentation from IFI is WRONG!!

competition_mode = 0 when the bot is enabled

competition_mode = 1 when the bot is disabled

( I sat up half the night at cleveland staring at my code trying to figure out why it wasnt working right. ^ turned out to be the reason).

If you have avaliable I/O on the OI (I love that line)...

Last year we set autonomous mode at the operator interface. The students pressed a "SET" button on the interface that would tell the robot to store the autonmous selection.
One thing I would change: throw some LEDs that blink rapidly if the autonomous program is not set. Even cooler: figure a way to add an audible alarm.

[KenWittlief]

why do you even have to store the inputs from the OI? if the RC keeps reading the OI in auton mode they will all be valid

and if it stops reading the OI in auton mode, the inputs will be left at whatever was read the last time they were read - right? nothings going to change them unless you initialze those variables in your auton mode and overwrite the data?

[KenWittlief]

we use competition_mode to read the yaw rate sensor when the bot is disabled, so we know exactly what it puts out when the bot is not moving (the zero point)

as you can imagine, the spec being backwards reeked havoc on our code - esp since we average the zero reading for 32 SW loops, so it seemed like it was sorta working.

[KenWittlief]

with the update, if it clears the inputs from the OI, then an easy solution is to read the OI auton switches while disabled, using (competition_mode==1) as the IF test

1=disabled

[MikeDubreuil]

Originally Posted by KenWittlief

why do you even have to store the inputs from the OI? if the RC keeps reading the OI in auton mode they will all be valid

and if it stops reading the OI in auton mode, the inputs will be left at whatever was read the last time they were read - right? nothings going to change them unless you initialze those variables in your auton mode and overwrite the data?

I have actually never checked. I was operating under the assumption that all inputs would be set to neutral, 127 for an analog input and 0 for a digital input.

I plan on doing a lot of research in the preseason this year so I'll settle the issue once and for all before Fall.

[TedP]

Originally Posted by MikeDubreuil

I have actually never checked. I was operating under the assumption that all inputs would be set to neutral, 127 for an analog input and 0 for a digital input.

The inputs go to all neutral. That is, they go to all 127 and 0 for analog and digital respectively.

This actually caused a big problem with our arm, takes in that 127 input and uses it as a position set point. Our initial set point wasn't 127. So the first time we jumped into autonomous mode, our arm very quickly lurched forward so that both of its joints were at 127! It was quite an annoying little find. We had to not pay attention to Getdata for those inputs during autonomous mode.

This is why I say you need to SAVE your inputs while in DISABLED mode. Then in autonomous, you can REMEMBER what they were before they got cut off from your vision.

LATCH first, use later.

[deltacoder1020]

as a global variable:

char my_setting = 0;

in the Default_Routine() (or wherever you process inputs):

if(competition_mode)
{
     my_setting = p3_sw_trig; //whatever input you want to read
}

thus, settings will only be read when the robot is disabled. you can then use my_setting as the setting for whatever during autonomous.

[10intheCrunch]

Here's how we "saved" the data for switching between autonomous programs this year (its all on the OI, left/right as well as three switches for programs).

First, we set up a new structure to hold all previous data. This is unbelievably useful for many functions on the robot, including switching relays with triggers. All the rxdata is stored in that new structure right before Getdata is called.

In ifi_aliases.h, we #define'd the input bits coming in to something a little more readable, in this case, autoProgSide, autoProgBit0, autoProgBit1, autoProgBit2.

Now, you need to put those data bits into a number you can read, and you need to use the previous ones. When autonomous mode is enabled all the data coming in is set to neutral, so you need the previous values to have useful information. Put them together using bitwise Or and the shifter function, and save the input regarding the side you're on in some manner:

autoProg = prevautoProgBit0 | (prevautoProgBit1 << 1) | (prevautoProgBit2 << 2);
autoSide = prevautoProgSide;

Now you've got a side and and program number that you can use a switch statement on in your autonomous code.

To Ken: the inputs do indeed all go to neutral.

[TedP]

This probably should be a separate thread, but...

Originally Posted by 10intheCrunch

In ifi_aliases.h, we #define'd the input bits coming in to something a little more readable, in this case, autoProgSide, autoProgBit0, autoProgBit1, autoProgBit2.

Rather than changing what was in ifi_aliases.h, we just added a user_aliases.h and added that to the project. Then we #defined our user alias names to names that were setup in ifi_aliases.h.

The advantage to this is that it was really easy to back track to find out that pumpPnuFWD is relay1_fwd and so on. It also prevented changing a bunch of other FIRST code that initialized the ifi_aliases to certain things.

It seemed like a pretty clean way to do things. Made it very nice to have all of our user aliases in one place where it was clear which one was supposed to be which.

[10intheCrunch]

Whichever way works for you =). The only aliases we *changed* were those in from the OI, though, not any pwm/relay values (for those, we redefined them somewhere else, so the compiler traces back the defines to what the variable actually is).

[TedP]

Originally Posted by 10intheCrunch

Whichever way works for you =). The only aliases we *changed* were those in from the OI, though, not any pwm/relay values (for those, we redefined them somewhere else, so the compiler traces back the defines to what the variable actually is).

When I said "traces back," I was referring to us when we had to remember on the seat of our pants... "So which relay is this supposed to be controlling?" "Which light should turn on here?" "This is referring to which digital input?"

It basically documented our wiring for us by doing it that way.

But again, I don't mean to start a separate sub-thread just for something silly like this. Just something I wanted to mention: don't be afraid to add your own files to the project.

[Jay Lundy]

Originally Posted by TedP

Rather than changing what was in ifi_aliases.h, we just added a user_aliases.h and added that to the project. Then we #defined our user alias names to names that were setup in ifi_aliases.h.

The advantage to this is that it was really easy to back track to find out that pumpPnuFWD is relay1_fwd and so on. It also prevented changing a bunch of other FIRST code that initialized the ifi_aliases to certain things.

We did the same thing. For example our motors are #define LEFT_MOTORS pwm01.

We handled our relays slightly differently. Since there are several different ways of controlling solenoids using a relay (2 singles on 1 relay -- M+ to GND and M- to GND, 1 single on 1 relay -- M- to M+, 1 double on 1 relay M+ to GND and M- to GND) we made a function to hide the implementation.

Our relays are #defined as just numbers (1-9), we have #defines for each function, and we have a SetRelay function which handles all the setting of relays.

For example:
#define BALL_GRABBER 1

#define BALL_GRABBER_OPEN RELAY_REV
#define BALL_GRABBER_CLOSED RELAY_FWD

SetRelay(BALL_GRABBER, BALL_GRABBER_OPEN);

(Or a little more accurately)

ballGrabberState = BALL_GRABBER_OPEN;
SetRelay(BALL_GRABBER, ballGrabberState);

In this example ball grabber is a double solenoid on 1 relay. If we wanted to change it to a single solenoid all we have to do is change the #defines for the 2 ball states to RELAY_OFF and RELAY_FWD / RELAY_REV. If we wanted to move it to relay 2 all we have to do is change the BALL_GRABBER #define.

That way not only does the code document the electronics, it is also easy to update should the electronics change in some major way.

By the way Alex, I'm pretty sure we left all the original ifi aliases intact, even for the OI. The autoProg bits are just #defined on top of the other alises.

[DKolberg]

We used the OI to program our autonomous mode and stored the mode in eeprom to ensure that it is available at all times. We only allow the mode to be changed while not in competition mode. We also used the leds on the OI to indicate the mode selected. We used the Switch LEDs to indicate 1 of 8 modes for autonomous and the Relay2 to indicate either left or right operation. This allowed quick verification / changes before the match began and could be programmed at any time prior to the match. Storing the mode in eeprom allows the mode to be maintained while power is off until the next time the mode is programmed.

if(compeition_mode !=0)
{
if (grabButton == 1 & freeButton == 1)
{
autonLR = autonMode & 0x8;
autonMode = ((armCmdInput-8) >> 5) & 0x7;
if (upButton == 1) {autonLR = 8;}
if (statButton == 1) {autonLR = 0;}
autonMode = autonMode + autonLR;
}
else
{
if (autonMode != autonEEP) //Update eeprom as necessary
{
writeEE (1,autonMode);
autonEEP = autonMode;
}
}
}

...

if(compeition_mode !=0)
{
Switch1_LED = (autonMode&0x4)>>2;
Switch2_LED = (autonMode&0x2)>>1;
Switch3_LED = (autonMode&0x1);
Relay2_green = (autonMode < 8);
Relay2_red = (autonMode > 7);
}


Dave
SBotz