Chief Delphi - Robot gone wild

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Technical Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=22)

- - Robot gone wild (http://www.chiefdelphi.com/forums/showthread.php?t=19745)

Quote:

Originally posted by Solace
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.

Re: Robot gone wild

Quote:

Originally posted by Gui Cavalcanti
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.

Anyone else have a robot gone wild story?

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

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.)

Quote:

Originally posted by Jessica_166

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

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:

Quote:

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.

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)?