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.

[TedP]

Originally Posted by KenWittlief

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!!

I actually didn't realize there was such a flag... However, it might be a good idea for those who are using things like PID controllers to stop integrating while not in competition or autonomous mode. That might make a cleaner transition from disabled to the competition/autonomous...

Additionally, we also have a spot in our code where we wait for the user to hit a particular button the OI during competition mode BEFORE the robot starts responding. We don't like the robot suddenly becoming live at the end of autonomous mode. This forces the operator to make sure all the OI settings are correct before enabling the robot during the match.

[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?

[ryan_f]

last year our team just shorted 2 pins on the competition port. Im not sure if it works on this years controller though

[Joel J]

I've heard talk of doing this both last year and this year; however, didn't IFI release a firmware update that did away with our ability to retain the last value sent from the OI? There was something mentioned about it in one of the team updates. They may have changed some other aspect of the control system, but maybe we should check first, eh?

If IFI's firmware update did make this method impossible, then the only option left would be to not perform the upgrade on the controller, if you have yet to do so.

[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

[Phil_Lutz]

Originally Posted by TedP

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.

Can you provide a sample of your code that displays this?
I am curious, but don't quite "see" it.

We mounted 2 switches on the robot to indicate which auton mode we wanted and which side of the field we were on.

If I'm hearing you right, what you are saying is I can have these switches on my OI (say port3) and read them in Disabled mode and act on then when not disabled.

Thanks,

Phil

[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 Phil_Lutz

If I'm hearing you right, what you are saying is I can have these switches on my OI (say port3) and read them in Disabled mode and act on then when not disabled.

You ARE hearing me right. It's important that you need to SAVE the state before going into autonomous mode. Autonomous mode DOES NOT MAINTAIN the state of the OI inputs. It clears them. That's why it's important to save.

There's a working example here:

http://www.osufirst.org/twiki/bin/vi...04RegionalCode

More specifically, in main.c, when **NOT** in autonomous mode:

int autonomous_on = 1;

void main()
{
...
autonomous_on = ( winchPneuSwitch == 1 ) ? 0 : autonomous_on;
}

That is, in the main.c the autonomous_on is set to 1 as a default. winchPneuSwitch is set to 0 while in autonomous mode -- Getdata() does that.

So our main.c just sits and churns while disabled and waits for winchPneuSwitch to get set to 1. If it gets set to 1 even for an instant, it LATCHES that data in. The autonomous code can then basically say:

if( autonomous_on )
{
do autonomous code
}
else
{
do something else (just sit?)
}

Additionally, we never were planning on doing anything in autonomous until competition. So we never had any switches anywhere. We show in this example we use a switch designed for a "winch pneumatic" to set our autonomous mode bit. We don't even need special hardware on the OI to set this -- we can just use switches already have.

Additionally, we don't enable immediately after autonomous mode -- we wait for the user to hit a button. So it's okay to leave these switches in a bad state because the driver can set them back before "enabling" the robot.

I hope that helps.

[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.