Ok… this seems like such a stupid question, but its been bugging me and I honestly am not seeing the reason for this… but maybe its just me.
What is the purpose of comp_mode?
Yes, I know what it does… it is set at the beginning and end of a match… its function is very clear. But why does it exist? Personally… I disregard it completely because like I said… its useless. All it tells me is that the motors and stuff are now active and can be controlled. But, really, why does the program care? If I activate motors or relays or the light before they are enabled, then nothing happens, right? I could have someone moving the joystick around and have the stamp send out signals to the motors… but if their disabled it doesn’t do diddily squat.
There’s only one purpose I can think of, and that is having some kind of timer so you can determine how long the match has been going… but I cant really think of a reason software would need to know that…
My starting code waits in a loop until the robot is enabled at the beginning, from there it jumps to autonomous banks based on the position of our selection switch on our controls.
Without comp_mode, it would be more difficult, not impossible, but slightly more difficult.
is that so now? hrm… here’s what I have in my “operator-controlled” portion…
if auto_button = 1 OR auton_mode = 1 then
get 10, auto_selection
select (auto_select)
case 0 to 3 'line tracking
run 6
case 4 to 7 'dead reckoning
run 7
case 8 'joy 1
run 2
case 9 'joy 2
run 3
case 10 'joy 3
run 4
case 11 'joy 4
run 5
case 12 'joy 5
run 2
case 13 'joy 6
run 3
case 14 'joy 7
run 4
case 15 'joy 8
run 5
endselect
else
gosub operator_control
endif
Not really so hard… and it allows me to simulate auto mode by using a joystick button or something…
[edit]
Also… this seems to be more efficient because it promotes a better transition from auto mode to user mode because of user mode is the default…
[/edit]
Comp_Mode is the Iffy name for kill. If you make a dongle (the new one), and operate the kill switch, the comp-mode bit is changed.
The significance of the comp_mode bit is not that you can’t use it, but that it is the bit that disables your robot in the arena except for a certain 2:00 minute interval.
If you can make use of it, do so. You stilll have to Serin the PBmode byte to tell when the auton_mode bit is alive. Now, about the User_mode bit . . . .
I use it to reset my Auton_MOde timer. That way The robot doesnt have to be reset each time I want to test auto mode. Also RoboEmu doesnt support reseting the robot.
*Originally posted by redbeard0531 *
** Also RoboEmu doesnt support reseting the robot. **
Sorry about that. I’ll try to get it into version 2.0.
Anyways, about comp_mode: the main reason I can think of would be for people who log data and use it to analyze post-match. It’s also probably just left over from before the days of autonomous mode, when it was the only way to determine when a match actually started. Finally, I know of some teams that have counters run for the entire match. These people probably don’t want to keep incrementing counters, etc after the match ends at the risk of overflowing a word-sized variable, etc.
I also use it in my autonomous program select code. When the robot is disabled, and the OI is in user display mode, I use a joystick button to cycle through the autonomous programs, displaying the program number on the OI for feedback.
*Originally posted by gwross *
**I also use it in my autonomous program select code. When the robot is disabled, and the OI is in user display mode, I use a joystick button to cycle through the autonomous programs, displaying the program number on the OI for feedback. **
Displaying a number on the OI? How is this done… I could never find anything about that anywhere… just goes to show how well I read instruction manuals
*Originally posted by randomperson *
**Displaying a number on the OI? How is this done… I could never find anything about that anywhere… just goes to show how well I read instruction manuals **
Now I just realized that I should be able to do this without setting the bits individually. The following SHOULD work, but I haven’t tried it, so don’t sue me if it doesn’t work for you.
get AUTON_PROG_NUM, OUTH
OUTH is a predefined byte variable that encompasses all the output pins 8 through 15.
Edit:
This will display the value in temp10 on the 3 (or 4) digit display on the operator interface when the OI is in user display mode. You put your OI into user display mode using the same select button with which you tell the OI to display the team number, radio channel, or robot battery voltage. You can recognize that the OI is in user mode when two decimal points appear in the display. When the OI is NOT in user mode, out7 through out15 are displayed by the PWM and relay indicator LEDs on the OI.
RoboEmu doesn’t have the OUTH (or OUTL, etc) yet, but it should work by 2.0. From everything I’ve heard, OUTH should work just fine and I’ve even heard from one person that they used it in their code without any problems. out8-out15 are literally just bit-sized aliases into outh, which is just a byte-sized alias of outs, so I see no reason whatsoever that it shouldn’t work.
question: can you use outh during disabled mode, ie right before human player period? that way, you could use it to show what auto mode you are in, if you use multiple slots, and make sure your driver has your auton control board set the right slot. see just use the wheel on one of our joysticks to select slots, which means it is a pain to make sure you are in the right range. Also, back on topic, thats what we use comp mode for, to let us know auto mode hasnt started yet, so we dont start the counter for auto mode, and to read in what auton slot should be run. it would be harder without the bit!
*Originally posted by JasonStern *
**… thats what we use comp mode for, to let us know auto mode hasnt started yet, so we dont start the counter for auto mode, and to read in what auton slot should be run. it would be harder without the bit! **
Yes… it would be harder without the auton_mode bit… but comp_mode is still useless especially if you have multiple slots because each slot should reinitialize its varibles and start all the counters and stuff… cuz you can tell if auton_mode is on when the bit is switched… right? So…
if auton_mode = 1 then
'do auto stuff
'reinitialize timers and other crap here as well
run 1
else
'do manual stuff
endif
That only activates autonomous programs when the bit is set, without worrying about comp_mode… because what it is really doesn’t matter to the program.
So, still don’t really see much usefulness for comp_mode yet… but who cares anyways? If ya use it ya use it… if you dont you dont. And I don’t
*Originally posted by JasonStern *
**question: can you use outh during disabled mode, ie right before human player period? that way, you could use it to show what auto mode you are in, if you use multiple slots, and make sure your driver has your auton control board set the right slot. see just use the wheel on one of our joysticks to select slots, which means it is a pain to make sure you are in the right range. **
That’s exactly what I do. As I stated earlier:
I also use [comp_mode] in my autonomous program select code. When the robot is disabled, and the OI is in user display mode, I use a joystick button to cycle through the autonomous programs, displaying the program number on the OI for feedback.
