Autonomous user-input loophole?

Was working on the code late last night, and this scenario occured to me:

While in autonomous mode, it’s likely that the Operator Interface user_mode button will still be enabled, so that we can get feedback from the robot running in the form of a byte or use our LED’s on the OI. The first forums talk about disabling all user-input ports, but I’m going on the assumption that the PB_mode byte will remain untouched.

Looking at the Competition Port pinout, it seems as if they only can toggle the autonomous_mode bit. So unless their “extra” chip inside the OI is coded to mess with individual bits of the PB_mode byte, teams should still have control over the user_mode bit.

So here’s my idea. You have a single bit, the user_mode bit, as input during the 15 second autonomous period. If it were not held static by the judging station, you could very easily use it to trigger events in your autonomous code such as turning at breakpoints, or waiting at the top of the ramp until user_mode goes low, or any number of things. You can do a lot with a single bit in 15 seconds.

Does anyone know the state of this? I personally don’t plan on giving my autonomous code any input whatsoever, but it would be nice to know if other teams might be able to implement this questionable hack.

DISCLAIMER: This only occured to me. I and my team have no intention whatsoever of giving our robot any input during autonomous operation.

This would be unethical and questionable as to whether it would work. I do not have an operator interface in front of me, so I am unable to test what is sent.

I’m sure if the referees caught you cheating in that way, they would kick you and your team out of the competition.

And rightfully so. With nearly 60 views and only one reply, it would seem this is a subject that’s up in the air. I think I’ll post a question to the innovation first forums to see if they’re aware of the possible loophole.

*Originally posted by Jnadke *
**I’m sure if the referees caught you cheating in that way, they would kick you and your team out of the competition. **

I don’t think the referees would do this. Worst case, they DQ you.

As for whether it works, I don’t know. I have a couple of ideas for setting the program remotely, but haven’t tested any of them.

I believe First’s stance on setting programs remotely is that you shouldn’t do it.

Basically, it’s my understanding that once you put your robot down on the playing field, you can’t give it any more information until after the autonomous period is over. Well, you’re not supposed to at least, I’m questioning if you’re technically able to… So the 10 seonds it’s sitting there, powered on while your human players are running around is supposed to be dead-air time.

Just my intrepretation of the rules so far.

isn’t the user mode controlled THROUGH the competition port, which is completely covered by the competition “teather” (i don’t know what it’s called, but it provides power, so i’ll call it a teather :)). unless you cut that open, and touch a few leads together, you can’t alter the user_mode bit, cause it’s part of the PB_mode byte, which is controlled by the referees. so, that leaves you without a bit to control what’s going on in your robot…

there is a way around this though, but it’s highly unethical. i’m pretty sure it was posted here before, but well, here it is again. another bit in the PB_mode byte is the competition bit, the one which disables you. you can disable yourself through the E-Stop button. so, you could technically use that to control your robot in the way mentioned above. as i said though, it’s highly unethical, and almost sure to get you a nice DQ. to eliminate this, FIRST should make the E-Stop button work only once during autonomous mode. say your robot goes wild, you hit the E-Stop button, robot is disabled till the end of the 15 seconds. this would stop this idea from being used. on the other hand, i’m sure if teams use this, the referees would get mad. but, then again, there’s no rule against it, yet.

I was under the impression that there would be no power to the driver’s station during autonomous time.

From the FIRST Forums…

The transition from the human player mode will be activated by the field control system when all of the pressure sensitive mats have human players on them.

At that time the field control system will send the ‘Autonomous Mode’ signal and the ‘Enable’ signal to the Operator Interface.
The ‘Autonomous Mode’ signal disables all user accessible ports on the Operator Interface while the ‘Enable’ signal is passed through to the Robot Controller.

The Robot Controller will then begin running the user program. At the end of the Autonomous period the field control system will terminate the ‘Autonomous Mode’ signal enabling the user accessible ports on the Operator Interface.

there is no 115v power, however the “competition tether” provides power to the OI. (does anybody know which pins do this?)

Technically, as soon as the Competition cable is plugged into the Operator Interface, the operator controls have power. However, whether or not the operator control data is transmitted to the robot is another story, and that’s what the Enabled and Autonomous mode controls do…

*Originally posted by Ian W. *
**isn’t the user mode controlled THROUGH the competition port, which is completely covered by the competition “teather” (i don’t know what it’s called, but it provides power, so i’ll call it a teather :)). unless you cut that open, and touch a few leads together, you can’t alter the user_mode bit, cause it’s part of the PB_mode byte, which is controlled by the referees. so, that leaves you without a bit to control what’s going on in your robot…
**
When you push the select button on the Operator Interface until you have a u_000 or whatever, that’s changing the user_mode bit of PB_mode. The OI will have power during autonomous operation. Furthermore, from the pinout of the competition port they don’t have controll over the entire PB_mode byte. Just the autnomous mode. I could be wrong, and they do actually have control over the entire byte, so they simply need to force the user_mode bit to something constant. I guess I could just play around with the competition port and see if I can toggle user mode from it…

*Originally posted by Jeff McCune *


I could be wrong, and they do actually have control over the entire byte, so they simply need to force the user_mode bit to something constant. I guess I could just play around with the competition port and see if I can toggle user mode from it…

Remember that we only have documentation of 4 pins of the competition port. We know that there is a power pin on there somewhere, but don’t know which one. We also know that they have some way of setting the channel, becasue they do it at the competitions, irregardless of the dip switches on the front of the OI. So basically, there are more things that we don’t know about the competition port then we do know. It would be very easy for them to give us a completely different interface then they use at the competitions (the already do this with the channel setting).

So basically, we don’t really know :slight_smile:

Although this post has mainly gone to the technical aspects of human control through the operator interface there are countless other ways of inputting data to your bot.

Example:
You could put an IR sensor on the bot with 9 preloaded programs. Have it look for a signal from a TV remote and choose the corresponding program. 1 for 1, 2 for 2, ect. Or you could stear it from the channle and volume buttons.

Personally I think its cheating to have any human input during the 15 seconds but I know someone will try.

*Originally posted by sevisehda *
**
Personally I think its cheating to have any human input during the 15 seconds but I know someone will try. **

It is cheating to have human input. The whole point of “autonomous” mode is to have the robot control itself autonomously. Any “loop-holes” in the rules for autonomous mode will prove to be closed or wrong/hard to use by competition time. Hopefully people won’t waste their time trying.

*Originally posted by Joe Ross *
**Remember that we only have documentation of 4 pins of the competition port. We know that there is a power pin on there somewhere, but don’t know which one. We also know that they have some way of setting the channel, becasue they do it at the competitions, irregardless of the dip switches on the front of the OI. So basically, there are more things that we don’t know about the competition port then we do know. It would be very easy for them to give us a completely different interface then they use at the competitions (the already do this with the channel setting).

So basically, we don’t really know :slight_smile: **

Pin 1 is for the power. I know it because I was fooling around with the pins and when I touched pin one with a keychain, sparks flied out of pins, and the OI reset itself. However I can’t build one that provides power, because it could void the warrantee, and the OI isn’t cheap.

I was always been finding a way to build a dummy arena controller, with power and switching the channels to the ones more than what can be provided by the channel select on the OI.

However I know when you power the OI from the cable, you get all that functionality plus more.

As for loopholes in the programming, well there are always loops in software, nothing is 100%. However you will be caught, and it won’t look good for your team.

*Originally posted by Kyle Fenton *
**Pin 1 is for the power. I know it because I was fooling around with the pins and when I touched pin one with a keychain, sparks flied out of pins, and the OI reset itself. However I can’t build one that provides power, because it could void the warrantee, and the OI isn’t cheap.
**

Ok… So making the pins shoot out sparks doesn’t void the warrantee? :slight_smile:

*Originally posted by Moshingkow *
**Ok… So making the pins shoot out sparks doesn’t void the warrantee? :slight_smile: **

Well I was testing it on a male to male connector attached to the OI, so it wasn’t technically touching the OI and wouldn’t affect the warrantee.

I hate to revive old topics, but I have a question. Is it possible for the robot to know if a button is pressed at the beginning of autonomous or the end of the human player mode? We plan on having a few dip switches, each one pertaining to a different autonomous program. When a button is pressed, a certain variable gets it’s value changed, then it checks the value of that variable at the beginning of autonomous to determine what it should do. Right now we have a turn-left program and turn-right program. Will this work, or is it not going to work and/or illegal?

It will work if the dipswitches are on the robot and connected to the RC. If they are connected to the OI, you will be able to access them until the moment autonomous mode begins. This means that you could, in theory, read them in during the human player period, save the data somewhere that doesn’t get overwritten in the SERIN, and then use it during autonomous mode.

i wish Innovationfirst would just release the full pinout of the connector. i would clear alot up.

Good luck trying this. Last I checked there was a rule implemented where the drive team had to stand ‘away’ from the controls during the autonomous period (3’ at that). With that said, I’m not sure how you can get any human interaction aside from hitting the e-stop.