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.
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.
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.
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’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.
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.
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
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.