Autonomous workking differently tethered in pits, than from feed during competition.

[Elgin Clock]

Has any one experienced this???
I don't know the full details bacause I am not on the electrical team, but from what I have gathered the autonomous program that works perfectly time after time on tether, fails to work and cuts out power again and again during the automonous mode during competition.

Now the tether is basically just a simulation of the actual feed from the players station during competition, but just done this way so as to not risk the fear of interference from any other bots in the pits and other non sanctioned official radio transmissions. Right??

So in theory the tethered response should be exactly the same on the floor of the pits and on the playing field, of course not counting such variables as friction against the wheels and floor, and other basic variables like that.

So why is it different???
So confused right now....

[pras870]

just out of curiosity, what regional did you attend?

[Elgin Clock]

NYC @ Riverbank State Park, this weekend. We had trouble in almost every match we played with this.

We even had the FIRST tech guy come over and suggest a few things but.. the problem has not gone away with the suggested changes/fixes.

[Koci]

Realize that when you turn your robot on on the field is NOT when autonomous mode starts. Make sure that your autonomous mode does not start in your code until the autonomous variable turns on. Otherwise, the robot is going through the code while it is just sitting there. This happened to some of the teams during the practice rounds in AZ. If its not that, I would have to see exactly what is not working in order to tell you what's wrong. I hope that helps.

Edit: Also, if you have any switches connected to your OI that change autonomous programs, make sure they are stored in a variable while the compmode variable is on (this is on only before the match). I had forgotten to place the "fieldside" variable in that part of the code on our robot, so our robot ALWAYS defaulted to being on the right side (in case anyone was ever wondering why our robot tried to destroy the field during one round).

[pras870]

well I know at SBPLI, we were having a problem with ours, we found out that the carpet we tested on was single layer, and we get to the field, and it was doubled up with carpet. Added more friction, which cut down on our turns, it's weird.

[Elgin Clock]

OK. This is a start. Thanks for all the info.

Like I said I am not on the electrical or programming team, and have no idea what is supposed to go on during the autonomous mode nor do I claim to know. But I do know that we tested the autonomous mode in the pits under tether many times and it worked, then we get out on the field and BOOM... it goes freaky.

What this simple(HA!) program was supposed to do, and does under tether, is drive the robot about 3 feet out of starting position towards the diamond plate wall, turn like 30 degrees to face the ramp and then drive up it to knock down the stacks.

What it actually does under competion is go forward the 3 feet, turn the 30 degrees, stop, turn another 90 degrees, and then ram into the side barrier at the same amount of programed length of time/liner movement that it would do if it were heading up the ramp in it's "normal" programming mode.

As it is doing this, our pneumatically controlled drop down casters keep rising and falling as if the whole robot is turning it self on and off again and getting back into ready position.

We do have switches to have different programs, mainly right and left sides of field start positions for the same program, and I will forward that "variable" concern that Koci had to the electrical team. That might be it. Who knows??

And, it does only start after the autonomous mode is started, or the "bit"?? is sent to the robot by the auto start sequence of events during competition, so it does start when it's supposed to do.

Oh, and FYI, human player mode works perfectly... well let me rephrase that, the electrical portion works perfectly, everything else, like driver descisions and anything else to that affect, is totally random of course. lol

[pras870]

if it's any help, you can email me your program (pras@optonline.net) and i could take a look at it for u and figure out what was wrong.

[Koci]

That extra 90 degree turn baffles me; I'd have to see the code.

About the pneumatically controlled caster, tell the electronics team to search for every time they use this variable, and make sure that it is initialized only once, and is not changing. When in doubt, comment out all instances of that variable other than the intialization.

[rbayer]

Same here. Feel free to send me any/all portions of your code: rob-bayer@mn.rr.com

[Elgin Clock]

Thanks for the offer.

What I am going to do is forward this WHOLE thread to our head electrical/programming mentor and see what he says. Maybe a new view on a problem will help... It's always better to walk away from a problem and then go back to it (if you can), than stare it down until you are mentally beaten to a pulp and are no further to the answer than you were before.

I have all the faith in our electrical/programming team, but I sure hope it is something simple in the code that can be fixed and just was not caught, and not something wrong with a major supplied component that we have no control over.. Like a bad OI or radio or something like that.. If it is something like that and we do find out that that is the case, then there is going to be a HUGE "what if?" factor involved and other unanswered question brought about.

Thank you for your offers. I will forward these very gracious offers to him as well.

[KenWittlief]

when you say it was working fine in the pits, do you mean with the bot up on blocks, or on the floor (carpeted) - actually driving around in auton mode?

if your bot is wacking out it sounds like:

1. your battery is surging lots of current, causing your robot controller to reset cause the voltage is too low for an instant. you wont see this when the robot is up on blocks with the wheels spinning unloaded, but when the bot has to move its a different story - esp if you have things in your code like going from full backwards to a hard left turn in one cycle, or full reverse to full forward.

2. I have seen some posts that say if you output 255 to the victors they do weird things - making the spikes wack out - all sorts of bizzard behavior - I dont know if this is true or not, but I try to stay away from the ends of the control outputs (0 or 255).

3. what are you using in the pits to make the bot think its in auton mode? did you make up a comp-port control switch box? with the auton and comp switches? or do you have a variable somewhere in your code or a switch somewhere else you set to make the bot think its in auton mode? maybe you dont have the 'real' auton mode bit properly processed in your code.

4. could it be something to do with your compressor code? does your code look at the pressure limit switch and do something different when the pressure is at 120? (like jump into the comp mode code instead of the auton code?

[ahecht]

You shouls never output 255 to the victors. The range of input is only 0 to 254.

[Coach C]

Occasionally - depending on how your solenoids are wired/programmed - we found that a dropped packet could set off our pneumatics. Low battery voltage seemed to exaggerate this. Just play with the solenoid and program - experiment with ports that are normally opened and normally closed until you find a setting that works.

If you have a castor shooting down accidentally, your robot might be sent into more of a spin, hence the 90 degree turns.