autonomous mode problem on field
 

At our practice rounds today, we had a bit of an issue with some of our autonomous mode code working, and I'm wondering if maybe any of you can help me out with how this could be happening.

OK, here goes. Our robot has the capability to do two different things during autonomous mode. It can either seek boxes, for which it uses light sensors and a thing we made to count wheel rotations, or go up the ramp, which is based entirely on wheel rotations. There are two on/off switches on the robot that tell it what to do during autonomous mode. These switches are set by the people who put the robot on the field at the start of the match. One switch (rc_sw10) tells the robot which side of the field it is on, and the other (rc_sw14) tells the robot which program to use (Go up ramp when 0, seek boxes when 1). Now, both of these modes worked fine when we practiced at Rockwell Automation, where we work on the robot.

We got to competition today, and during practice had 3 chances to test out autonomous mode. We tried box seeking mode 3 times, and it successfully knocked down the opponent's big stacks, but when we had the switch flipped to try going up the ramp, nothing happened at all during autonomous mode. After this, back in the pits, I sat the robot on a box and used our autonomous mode dongle to test these modes. Both appeared to be cause motion when using the dongle on the competition port, but for some reason, the robot did not do anything when it was told to use the ramp program and was in an actual practice round connected through FIRST's radios, instead of a tether. So, my question is what could be causing one of these two parts of autonomous mode not to be working? Is there something different about the way a competition port dongle and tells the robot through the tether that we are in autonomous mode than when we hook up to the FIRST competition port on the field tells the robot through the radio? I spoke with Eric Rasmussen from FIRST about this at the event, and he thought maybe it could have to do with the fact that on the field, the competition port also enables and disables the robot in addition to changing the autonomous mode state, and that the order that this happens in could be messing it up, but, after looking at my code, I don't really think that is it, though I may be just missing something (It happens a lot :) ). here is some of the code:

OK, first we have the section that tells the robot whether or not to do box seeking, then the section that tells it whether or not to go up the ramp. here is what it looks like:

If auton_mode = 0 or rc_sw14 = 0 then skip_box_seek:
(box seeking code here)
skip_box_seek:

If auton_mode = 0 or rc_sw14 = 1 then skip_up_ramp:
(code to drive up the ramp here)
skip_up_ramp:

I don't think those middle parts should matter too much, since really the problem seems to be with how the robot enters autonomous mode, and since the program is actually on another computer next to me that I am looking at and then retyping here, it's not worth the time to retype all of it. At any rate, none of that stuff considers the auton_mode bit at all anyway. I'm pretty stumped at what could be causing this (though I really can't claim to be any type of a programming god), so please let me know if you have any idea. Also, please forgive the length of this post :). Thanks.

--Chris C.

have u tried running the auto code on the ground? it might be that after the robot has sat in a box for a few weeks the drive train isnt as smoothe as it was before, so it might be that your values for turing are too low, therefore when its sitting ontop of the box the wheels turn, but when you put it on the ground the power isnt there to get the bot to move. Try running the program tethered up in the pits in a nice open area.

Could it be a timer problem? (See my post in this "RoboEmu 1.11beta1" thread.)

Yeah, I think it's a timer problem, as said above. The code begins executing as soon as the robot controller gets contact with the OI. The master processor just doesn't allow anything to be output to the speed controllers. Your timer is probabaly expiring before your robot gets a chance to do anything.


If you look at Team Update 11 it shows how the bits are for the phases of the match. Whenever autonomous mode is set to 1, all operator interface feedback will be overridden.

When comp_mode is 0, your robot is active. Basically, make your if statements to read:

If auton_mode = 0 or comp_mode = 1 or rc_sw14 = 0 then skip_Blah

Well, I don't consider time in my program, only wheel rotations, and these only get counted when there is motion in the wheel, so unless I am misreading this, I don't think that is the problem. I'll try out your ideas though and see if they help. Thanks.

Solution
 

You can't test your controls during autonomous control, because they default to 0/127. Instead you must test any autonomous selection switch in your non-autonomous code and then save this value in a "dummy variable" for the autonomous period.

ie....
if automode =0
if switch = 0
dummyvar = 0
else
dummyvar = 1



if automode = 1
if dummyvar = 0
'Box mode
if dummyvar = 1
'Ramp Mode

Something like this should solve the problem

Re: Solution
 

That's true of the switches that connect to the OI, but the ones on the RC should still work fine. (ie you can't use p1_sw_trig, but you can use rc_sw1).

True....
that was the glitch we had when we were first testing. We don't use the default names, so rc_sw14 means little to me.

Anyways, i'd make sure that the robot was tested properly. Did you use both the disable and autonomous switches to test the machine? FIRST disables the robot then starts autonomous mode and enables the machine. Could this make a difference in your code? It may be possible to get a different response if you tested the robot by turing on autonomous mode while enabled.... although I don't think we encountered such a difficulty. Never hurts to check though.

I found that with the new dongle, when the "kill" switch was on, even if the auton_mode switch was demanding auton_mode be set (= 1), the auton_mode bit was in fact reset (= 0). When the "kill" switch was flipped to "Operate", auton_mode then set itself, until the auton_mode switch was flipped. The kill switch affects the state of the comp_mode bit, in case you were wondering.

..............Auton_mode bit state:

..............AutoOFF......AutoON
Kill ON........0.................0
Kill OFF.......0.................1

I wouldn't imagine there is a different way to do the disable and auto functions via the comp-port.

BTW - does anyone know _if_ the user_mode bit affects the other two ? (And if, then how ?)

We had some problems early on with debug statements that seemed to cause a similar sounding problem. I removed them and then it worked on radio. After that, I only used dashboard.

Chris, Good idea to use the switch to choose sides! Some made multiple programs. We used a switch because I figured edits would kill us if they were separate programs.

-- I was just happy my auto-code didn't lose us any matches!

Eric

bit sequence is incorrect
 

Update number 11 has the bit sequence of comp_mode and auton_mode for the match. Its supposed to go like this:

Before the match: comp_mode = 1, auton_mode = 0
Autonomous: comp_mode = 0, auton_mode = 1
Teleoperation: comp_mode = 0, auton_mode = 0
After the match: comp_mode = 1, auton_mode = 0

We have a thumbwheel switch on the OI to select the autonomous program, so its important to make sure we grab the value before autonomous starts or it will be overridden to 0. We wrote the initialization program with the following conditions:
Slot 1 holds the teleoperation code and slots 2 - 5 hold autonomous programs. During testing with the dongle it worked fine, but on the field it kept running slot 1. We didn't realize right away what was wrong, but you cannot depend on the bits flipping in the order they tell you. I think they drop comp_mode low before raising auton_mode, which is what messed us up. Its fixed now, but it was very frustrating.

we had that problem alittle too

if you're sitting still at the beggining of the match its possibly because your human player didnt get off the feild in time, not nessisaraly the auton code. make sure that they get off in the oloted time

You should cycle the robot power before starting an autonomous mode match. This way you will be sure all of you variables (flags, states, etc.) are reset to their default state.

If you do not, the processor is still running in your main loop after the match. When the competion controller disables the robot, it disables the inputs and the outputs but does not force a controller reset. When re-enabled, the controller picks up where it left off.

When the second match starts, the processor continues to run but the initialization section is not executed thus any variables remain at the same value as at the end of the previous match.

The effect can be:
Let's say your dead reckoning code has a timeout so your robot doesn't run after it knocks over the boxes. You use that value to stop the motors. When you start the next match, that variable has not been reset and your code will think it is still at the end of the previous autonomous mode session.

By doing a power off and power on (POPO)before the match, you are assured of a proper controller reset and thus the initialization code will be executed properly.

We had this happen in our first practice round in the regional and didn't have a problem since doing to "POPO".

Redukes has the correct answer here.

We experienced the same problem, which you would only encounter during the practice matches.

Auton mode works the first time, because the RC is in a fresh reset state at the start. However, the field does not reset your robot controller between the two practice runs, so if you counted your auton operation to 400 steps, the step counter is still at 400, and nothing will happen. You can solve this by simply pressing the robot reset switch between the two test runs - or cycling power.

We had the same problem at NASA/VCU during our first two runs - we were going crazy trying to figure out why one of our auton modes wouldn't work, but it had nothing to do with our coding.

BTW, there is an elegant fix for this in code. Once Auton mode is false - reset you timers, counters, whatever. This makes the robot essentially self-reset the auton variables once driver control is initiated.

After the initial powerup sequence on the field causing problems with some autonomous programs, FIRST has switched the bit toggle sequence to(If i understood what Eric told me correctly):

Pre Match: auton_mode = 0, comp_mode = 1
Human Player Phase: auton_mode = 1, comp_mode = 1
Autonomous Phase: auton_mode = 1, comp_mode = 0
Remote Control Phase: auton_mode = 0, comp_mode = 0
Post Match: auton_mode = 0, comp_mode = 1

So, what I'm going to recommend is that your code only starts running in autonomous if BOTH auton_mode and comp_mode are in the states described above. As an FYI, FIRST changed this after realizing that with the original field control code, it was possible for one or two program loops at match start that the PBASIC program would think that it was in user control mode, and possibly skip over the auton program entirely(see other threads on this).