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

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

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

[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

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