|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
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. Last edited by Jeff McCune : 21-01-2003 at 13:19. |
|
#2
|
||||
|
||||
|
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. |
|
#3
|
||||
|
||||
|
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.
|
|
#4
|
||||||
|
||||||
|
Quote:
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. |
|
#5
|
||||
|
||||
|
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. |
|
#6
|
||||
|
||||
|
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. |
|
#7
|
|||
|
|||
|
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. |
|
#8
|
||||
|
||||
|
there is no 115v power, however the "competition tether" provides power to the OI. (does anybody know which pins do this?)
|
|
#9
|
|||||
|
|||||
|
Re: Operator Power During Autonomous MOde
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...
|
|
#10
|
||||
|
||||
|
Quote:
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... |
|
#11
|
||||||
|
||||||
|
Quote:
So basically, we don't really know :-) |
|
#12
|
||||
|
||||
|
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. |
|
#13
|
||||
|
||||
|
Quote:
|
|
#14
|
||||
|
||||
|
Quote:
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. |
|
#15
|
|||
|
|||
|
Quote:
![]() |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| A better autonomous method.. | randomperson | Programming | 4 | 24-02-2004 18:02 |
| crazy idea for autonomous | Mike Ciance | Programming | 16 | 24-04-2003 21:50 |
| variable? | manodrum | Programming | 11 | 01-04-2003 17:20 |
| autonomous mode problem on field | Chris_C | Programming | 17 | 26-03-2003 19:11 |
| Autonomous Kill Switch | UCGL_Guy | Programming | 8 | 15-01-2003 17:39 |