Receiving info from OI to select autonomous mode
 

I've tried searching for this topic, because I'm sure someone has mentioned this before, however:


Can I read values from the OI during autonomous mode?

All I want to do is read a few switches and joystick axes to select an appropriate autonomous mode to run, so they don't even need to be updated while autonomous mode is running.

It would be nice to know if I can use variables like p1_x, p3_sw_trig, etc without having to do anything special.

Thanks in advance!

Re: Receiving info from OI to select autonomous mode
 

It cannot read from OI during the autonomous mode, but you can read it before they (whatever at FIRST competitions that sets the modes) set it to autonomous mode

Re: Receiving info from OI to select autonomous mode
 

See the above code for reference - it's what I used last year. I call the SelectAutonomousProgram routine from Process_Data_From_Master_uP. To store any OI switch-driven settings I want to make available to the program once the match starts, I create variables (i.e. sideselect, autodriveselect, autocode) and write the status of the OI switches to them while the robot is in human control mode (which it is when it's powered on and disabled before match start). When autonomous mode starts, these variables are still available to the autonomous code while the OI switches, joysticks, etc. are being ignored. This routine also sets initial robot behavior when the bot first comes out of autonomous mode.

This year, we're using a 3-position toggle switch (wired to an analog input with the help of 22k and 47k resistors) and a BCD thumbwheel switch (8 distinct program options that consume three digital inputs) to yield 24 different autonomous program possibilities. The likelihood of me having the time to program our robot to do 24 different things in autonomous is almost nil, but that's beside the point.

Re: Receiving info from OI to select autonomous mode
 

Question: Are we allowed to use the OI while the robot is in disabled mode, before we have to step back and wait for autonomous to start?

If we can't touch the OI before autonomous, but can still transmit data, then I guess we'd have to use a set of switches to select a mode, since they don't require anyone to physically hold them in place.

Re: Receiving info from OI to select autonomous mode
 

Really, if you use toggle switches or other devices which maintain their state once you set them, you don't have to wait for the robot to be turned on before setting up your controls at the player station. Just use the toggles to choose the autonomous settings you want and then step back behind the line and wait for the match to start. In your program, you still need to copy the OI variable values to your own custom variables in order for them to be accessible during autonomous, because all OI variables are reset once autonomous starts.

Re: Receiving info from OI to select autonomous mode
 

Actually, this would not work. A similar question came up in another thread, so I asked Tony Norman at IFI exactly how and when various data may be passed between the OI and RC. Tony double-checked and said that the field control system will not allow any data to be passed between the OI and the RC prior to the start of the match and the completion of the autonomous period. The OI and RC will both be active, but the field control system (which is different this year than last year) will prevent them from communicating.

So if you want to have a switch or dial setting to choose between autonomous programs, you should put it on the robot and not on the OI. The RC will be able to read the state of any switches, sensors, etc. that are local to the robot when it is powered up, and can use that information during the autonomous period.

Just to complete the story, if the robot is disabled later during the teleoperated period (like when the human player steps off the pressure pad sensor) communications between the RC and OI can continue. But the field control system will disable all the outputs from the RC so the system cannot activate any motors or actuate any other devices.

-dave

Re: Receiving info from OI to select autonomous mode
 

I was also planning on using a switch for autonomous mode, but I guess I have a few more inputs for something else...

AS I was browsing through the code, I noticed this comment:
This seems to say that inputs are still being read during the autonomous mode?

How do they prevent you from reading inputs during the first Disabled mode, but not later disabled modes after you leave the pad? Do you know how to simulate this outside of the competition or does disable mode automatically disable all OI inputs even after the first time?

My code reads the inputs and prints them out every frame (even autonomous) and every variable ended up at 0 for autonomous mode. It seems that instead, the values should be whatever they were before autonomous mode turned on, not reset to 0.

But, according to other team members, this is not true for disabled mode at the beginning, and you can be allowed to read inputs at some point.

Are the other experienced people on this team wrong? Is this rule new this year?

Re: Receiving info from OI to select autonomous mode
 

A new wrinkle:

Posted on IFI's FAQ site yesterday:

Re: Receiving info from OI to select autonomous mode
 

Thanks, Kris. The specific detail of the FAQ post makes it hard to argue with what is posted - I'm inclined to listen to the IFI "techie geeks" who reply to those FAQ questions. I hope the FAQ is true because quite frankly, I can't see why IFI would ever disable such a convenient feature as setting autonomous parameters from the OI.

Dave, there seem to yet again be multiple conflicting answers to the same question. I'm not going to 100% say that the FAQ is true, but as I said, I'm inclined to believe the "straight from the geek's mouth" version. I'll leave it up to you to clarify this confusion with Mr. Norman and make sure everyone's on the same and correct page.

Thanks,

Re: Receiving info from OI to select autonomous mode
 

Tony Norman and the IFI documentation disagree.

It sounds like Tony is describing autonomous mode, not disabled mode. With the documented features of the system, I know of no way to prevent the kind of communication required to implement a mode switch on the OI. If FIRST is using an undocumented "uber-disable" mode while the robots are being placed on the field, a whole lot of teams will be surprised to find they have no autonomous mode selection control.

The recent FAQ on the IFI site also contradicts Mr. Norman. It explicitly approves the kind of OI automode selection asked about in this thread. (It gets a technical detail incorrect, though -- disabled mode doesn't set the RC PWMs to 127, it turns them completely off.)

Re: Receiving info from OI to select autonomous mode
 

When in doubt, always err of the side of caution.
We will be placing the switches on the Robot.
No good just sitting there the 15 seconds. ;)

Re: Receiving info from OI to select autonomous mode
 

Caveat:

Dave Lavery mentioned that this year's arena controller is different than last year's.

If this year's arena controller places robots in both autonomous mode AND disabled mode (they are independant control bits) before a match, then I would agree that OI switch data will never be passed to the RC. OI data would constantly be reset to 0.

Unfortunately, the details of the arena controller operation aren't really information most of us are privy to.

Can I respectfully request someone to contact IFI again, and attempt to garner a definitive answer?

In the meantime I think I'll err on the side of caution, and hook up our Autonomous selection to the RC's I/O.

-SlimBoJones...

Re: Receiving info from OI to select autonomous mode
 

I witnessed this circumstance during the SBPLI regional last year. The autonomous mode bit would be set sometime during disable mode, then the disable mode turned off some number of seconds later.

Re: Receiving info from OI to select autonomous mode
 

That code snippet could be just old stuff IFI never took out from last year, so don't completely trust it I'd say.

Couldn't someone test this with a simple dongle? There's two bits, Autonomous and Disable, nothing else (unless it's super secret and in that case all bets are off). So, if you have a dongle (or two paperclips), couldn't you easily test all scenarios of bits being on and off, there can't be that many combinations, and then post the results up here? I would think that's all you need, and I'd offer to do it, but I don't currently have access to an OI/RC.

Re: Receiving info from OI to select autonomous mode
 

Whoops. SlimBoJones pointed out the way to do it. If the FIRST field system sets the autonomous mode pin active early, even before field setup, and doesn't release it until the beginning of teleoperated mode, that would indeed keep the robot from ever getting information from the OI controls until after the match begins.

It would also break every autonomous program I've ever seen, since they universally assume the autonomous_mode flag will become active at the start of the match. They would blindly start running as soon as communication with the OI was established, but the robot would still be disabled. Default code version 2.4 works that way. Can someone with both a copy of the "scripted autonomous" software and a grasp of the software issues involved look to see how it's handled there?

Re: Receiving info from OI to select autonomous mode
 

To look at the OI switches during disabled mode (before autonomous is on) do we have to add a fuction that looks at the variable disable_mode and then if it is on, stores the operator joystick values in a temporary variable.

This is what we have added into our program for now. But my question is that...if your program in main.c checks to see if disable_mode is on before autonomous_mode won't it still be able to recieve values from the joysticks? Even if it only does it one time? Or is there some other program in the master processor somewhere that prevents this from happening if both autonomous and disable are on at start up.

Re: Receiving info from OI to select autonomous mode
 

ok, so if we were to put the variables for autonomus switches in the Process_data_from_local_IO section the robot would never see these numbers while autonomus is enabled. im asking this becasue this is where i have the switches now and even there they are causing trouble. the way i have it set up, is that the values are read from four swiches. they are p4_sw_trig, p4_sw_aux1, p4_sw_aux2, and p1_sw_trig(due to that whole port duplication thing).

so if i had this code in Process_data_from_local_IO

if(p4_sw_trig == 0 && p4_sw_aux==0 && p4_sw_aux2== 0 && p1_sw_trig == 0)
{
auton_state = 0;
}

would these values never acutally get to the rc?

ive already lost to much sleep working on the code, i really want to finish it before atlanta comes around.

Re: Receiving info from OI to select autonomous mode
 

Just a quick reply here, but...

You need to make sure you grab the state of the switches in a seperate variable BEFORE autonomous mode is enabled or else you will lose your inputs. We did this in main.c last year and we are planning on doing it again this year.

An example of this can be found at http://www.osufirst.org/twiki/pub/OS...nalCode/main.c

Specifically:
We expanded upon this further for nationals last year, but I don't think I have that code readily available on the web.

Re: Receiving info from OI to select autonomous mode
 

Earlier this year I got to our shop early one day, and a new person interested in programming was there too. So we busted out kitbot and I decided it would be cool to write a dead reckoning code that would just make it drive really fast, then spin in place (I had never written dead reckoning code before so yeah...). The point is that I used a counter to tell it when to do what, and it incremented the counter within the autonomous section. I worried that if both my autonomous switch, and my disabled switch were on the counter would start counting early, but it did not. To me this means that if the bot is in autonomous and disabled (at least using a dongle) the autonomous code doesnt run. Now I forget why that was important to this conversation, but I do remember that it was somehow.... Oh yeah and I cant 100% garuntee that I was using the latest firmware there either.

Re: Receiving info from OI to select autonomous mode
 

OK, forget (almost) everything that I just said. I talked to Tony again tonight, and we are revising our answer (in other words, I got it wrong; I blame it on sunspots affecting my cell phone and causing static so I could not hear what he really said the first time). The CORRECT correct answer is that prior to the start of the match, the OI and RC do indeed communicate. The motor outputs are disabled, but data from the OI can be received by the RC (in other words, the robot is in "disabled" mode as described earlier). When the match starts and the autonomous period begins, the communication channel between the OI and RC is interupted, and they can no longer pass data. Then the autonomous period ends and normal operations begin.

So, yes it appears that it is indeed technically possible to set switches/controls on the OI prior to the start of the match, and have the RC receive the information. However, before we all rush off to implement that capability, note Question #1598 just posted on the FIRST Q&A system:

Oh well, so much for that idea...

-dave

Re: Receiving info from OI to select autonomous mode
 

One method I have used for the last two years is storing data in the EEProm while in disabled mode. This way the value is there independent of whatever method they choose to use on the field. There was some code posted last year with some routines for accessing the EEProm. Just load some autonomous Variables from EEProm in the initialization area. While in disabled mode use buttons or joystick position along with a button to select the autonomous variables.

Re: Receiving info from OI to select autonomous mode
 

Thanks, that's a big relief. :) If we couldn't use the switches we set up today on the OI, I'd have to grab some jumpers and hope that the person switching them on the digital input pins wouldn't break the RC. Or I might've tried using an EEPROM module. This is a lot easier.