Robot gone wild
 

Alright, so we're competing in Philadelphia on Friday, and I notice as the driver that the robot can no longer turn the left wheel forward (we have two-wheel drive). The funny thing is, reverse works fine. Since we're in the middle of a qualification match, however, I don't think about it,but I do what I can and get to the top of the ramp in reverse.

Once I get there and let go of the sticks, the left drive starts to jerk. I wonder if the joystick calibration is off, and compensate by moving the stick forward, holding on till the last second. The buzzer sounds, and I unhook our controller. That's when it happens.

Suddenly, our machine is no longer on the top of the ramp. At first I thought it had merely slid off because I had not positioned it correctly, but the still-going video of the match showed that the robot was actually moving under it's own power . Remember, the competition controls were not only disabled, but physically disconnected from power.

Referees fled from the field as the 422 machine started spinning randomly. Our operator station crew, including me, was obviously flipping out. The robot's left drive was powering forward at our maximum possible speed, knocking bins out of the red scoring zone right and left. My crew and I ran over to the red side of the field.

Needless to say, the FIRST crew was very nervous, and the announcer was freaking out. Our robot is incredibly menacing when it's spinning; when it's arm is down, it has two horns at it's top denoting where our grippers used to be. Luckily, a quick-acting referee grabbed the robot's side and lifted the wheel off the ground, and one of our teammates hit the power switch.

Apparently, a bin had hit the left drive's Victor 884, and had shattered two of the transistors inside. We took it apart later, and it looked like pieces of the broken transistors were shorting out the rest. Carnage! Anyway, we had replacement Victors on the robot (we had removed a couple of systems that day, sadly) so all was well thereafter.

Anyone else have a robot gone wild story?

Hopefully you're in the process of designing a shield to protect all your controls! :) Sounds like you guys learned the hard way that even though the Victors look pretty solid, every piece of the control system is relatively fragile and should be protected from falling bins, other robots, etc.

As for robots gone wild, I don't have any stories quite that good, but when we visited the St. Louis regional I could have sworn that I saw at least a couple of robots that had their rotating lights turn on after the end of the match (I don't believe they weren't tethered...). I think I saw TechnoKats have an incident like that. Can anyone from that team confirm/deny?

Yep
 

In St. Louis during one of the many matches were our robot would die and come back or act just plain strange it did happen. I'm still not really sure how it happened or why it happened, but during the match the robot died, and right at the end the light came back on and stayed on after the match was over.

Sounds a lot like what happened to us during our first practice round at Sacramento. We had been drilling out a screw with a busted head that held the Victor to our electronics board. Apparently, some filings got into the speed controller... drive started failing towards the end of the match. We got on top of the hill, then the robot just started spinning around and around. Our driver didn't know what was going on; one of the FIRST people yelled at us to hit the e-stop, we did, it kept spinning; that person came over and hit the e-stop himself, it kept spinning; the match ended, it kept spinning... There was also some wisps of smoke rising out of the bot. The field people eventually ran in there, lifted the bot up, and turned it off. The speed controller had shorted.

We were very glad we had cut a hole in the top of the Lexan that day, or else they wouldn't have been able to turn it off.

Gui,
The damaged Victor was most likely the result not the cause. The transistors in the Victors rarely can be shattered by a plastic bin but will blow apart when they encounter a short in the load. You may have replaced the bad controller but you haven't found the original problem yet. Keep looking.
As to the temporary failures, see my other posts on the possibility of teams powering up in the pits with modem instead of tether. It seemed more prevalent on practice day than on competition days.
Nice work on the part of officials, knowing that they can pick up one side of a robot, get it's wheels off the ground and it becomes pretty helpless.

At SBPLI, there was a match in which we didn't trust our autonomous mode systems, and thus we switched the program selector to 00, the setting for no autonomous. Then we closed the shield on our robot, and soon after, the match started. Wonder of wonders, our robot goes back at full speed, and then inexplicably climbs the ramp and stops in from of the boxes. It turns out that the lid was closed with sufficient force to change the setting on the program selector to "full back mode" AND one of our sensors was not mounted correctly, and so only one side ran, and our robot ran up the ramp.

This is experimental proof that two wrongs DO make a right.

there are several things that can make your bot wack out:

1. if someone in the pits has a comp-port adapter, and they unplug the tether with the bot still powered up, the bot and or OI can be transmitting (some teams dont know you dont need the powersupply for the OI with the tether).

If the 'pit-bot' does not have the same team number programmed then they will not be taking over control of your bot on the field, but if they are on the same channel it can jam your link, causing your bot to stop running, or to become erratic.

2. if you output 255 to any PWM in your code, then the serial out link looses sync, and the data will no longer be going to the right devices- PWM data may end up going to relay spikes, PWMs may use the wrong PWM outputs. You should always use the

drive= (2000+drive)min 2000 max 2254)-2000

line right before your serial out section, for all your PWM variables, if there is ANY chance the math your SW uses might end up with 255 in a PWM variable.

3. low voltage on the robot controller, or on sensors, will make your bot shut down, or act flakey if its right on the edge. I would like to see FIRST use a separate battery for the RC and sensors, since pulling 120A out of the gelcel can drop its output very low. We had repeated problems with our bot at the Canadian regional, saying 'low battery' when we had a fresh bat - we replaced several wires, including the main battery wire, but never did figure out why it was happening.

Not a robot freaking out story, but funny nevertheless. On one Practice match Thursday, or a match Friday morning at SVR (I dont remember) we were either in the middle of autonomy, or the beginning of human control. The robot had just started to go up the ramp, and suddenly did not respond to user control. We could not see it, but when the wall fell, one box fell just right and actually tripped the push button on our 120A circuit breaker, turning the robot off... Definitely the weirdest thign ever to happen to our team while I've been around.

Cory

heh.. so how did the score for that round go?

If it was a practice match, dont remember. If it happened in our first match, which I think it did, we got 6 points.

Cory

At SBPLI, 173 learned the hard way that the 120a breakers can be quite susceptible to hard impact.

Please explain.

When programming autonomous mode one day (still during the six week build) we decided to test it out. We positioned people all around the robot about 10 feet away, and we put one of the parents, Myron, directly behind the robot to turn off the power if it went out of control...

Unfortunately for Myron, I flipped reverse and forward around in the program, and our bot goes flying into him at full speed in high gear. After his shock, we get the robot turned off and I immediately start working on the mistake.

Now here is the best part :D

We try it again, and this time Myron starts off a little bit farther back. The robot starts making its arc towards the ramp, and relieved, Myron starts following it. Obviously not being happy with Myron's remark that it wasn't very smart, it suddenly runs straight backwards once again right into him.

I have no idea how it happened, there was no reverse code for the motors in that program... It was just really funny because our robot actually faked him out into thinking it was safe to follow it, and then it attacked :rolleyes:

I swear these bots have a mind of their own! :ahh:

Is Myron going to Houston, can you talk him out of it? He is obviously a robot magnet.

If you run into something hard enough - be it a wall or another robot - the main 120a breaker in your robot can trip from sheer impact.

We accidentally ran into the walls protecting both driver stations in autonomous mode a few times.. neither tripped the main 120 amp breaker. In one match we were tangled up in another team's robot, and it ended with the weight of our robot breaking their arm, and thus body slamming our robot onto the floor from about a foot off the ground... that tripped our breaker.

i stand corrected

Re: Robot gone wild
 

We had a problem with static at our regional where when the power was turned off our robot light was still going. This might have happened to your robot since you think there was a problem with your controller
Jessica

wild robot
 

While we were programming our autonomous programs, we had to do several testings to see what was going on.

Well I had forgotten to initialize the drive constants so that the robot was at a standstill when it got power. So when we turned it on to test the program, it started going fullspeed in reverse and ended up running a student over....
It also took us a while to figure out why this was happening. You can imagine the boggled people wondering why the program that worked a little while ago is suddenly doing unexplanable things!
-Jessica

Before shipping our robot, we were testing our auto mode, and we only had half of a ramp:

/[]

The back side didn't have mesh on it, and our programmer held the button to enable autonomous too long... Our robot fell off the ramp and landed on its front. It's a good thing our robot was sturdier than the light was (which didn't actually hit anything but broke anyway from the sudden decelleration.)

Re: wild robot
 

Yah we did that during build time, too. turn on the robot, not expecting anything to happen (yet) and the robot goes flying backwards. a couple of our team members run after it and hold it until someone can hit the breaker. after we pick up the bot, we notice it burned two holes thorugh the carpet :rolleyes:

one of our matches at nats, our partner was faster than us, I programed in a 3 second delay in or auton code, or so i thought..... autonomous starts and 3 out of the 4 robots on the field start moving, only the stationary bot isn't us, it's our partners. meanwhile, we go flying up the ramp and knock down one side of the boxes. somehow our code get reset, so we back all the way off the ramp, rotate, then go forward again, knocking down the other side of the boxes!
:yikes:I guess our robot wasn't happy being told to sit and stay:yikes:

Could you elaborate on this? I have seen some "interesting" behavior when output a 255 in a serin. Is there something in the documentation that says not to do this? Is this a best guess as to why wierd behavior results (ie losing sync)?