Oh god did our robot just run into the driver station auto club

[IronicDeadBird]

And no the one that went flying out of the field doesn't count.

Our robot at least twice at Arizona North decided it would love tap the driver station opposite of the low bar. Turns out motion profiling is easier to spell then it is to implement.

[GreyingJay]

I'm fully expecting ours to accidentally do that at some point during our matches in North Bay this weekend. I'll be mortified, of course, given my vocal stance against this "strategy". But irony is what it is... If it happens, we'll fix it.

Our students agree that "run and gun" is NOT a viable auto strategy on our team. We have code that we think will do the job.

[yonip]

Well one time our robot just rammed the wall repeatedly for ~10 seconds. Next match (I think) it hit the driver station wall again... and then ran away :0 (both during CHS Greater DC, and that was all the castle crashing we've done)
We totally forgot that velocity PID is sticky so we never stopped the bot when it went far enough...

[GreyingJay]

As expected, we had a few unexpected crashes at North Bay. Our most egregious happened when an encoder was ripped clean off the gearbox in a previous match, and nobody noticed...

We fabbed up a skid plate after that!

[Nyxyxylyth]

Yeah, nobody noticed the encoder wire had fallen out.

We've since put in a timeout, just in case.

[EmileH]

1786 at Granite State, every single match

[messer5740]

Ours did that at the Buckeye Regional once... We increased the time and speed to get over some of the ground defenses and on our first run, we went over the rough terrain and went full force into the opposite driver station. Our drive team was mortified because this had happened to us multiple times in our previous regional and vowed to never intentionally do so. We changed the time slightly to avoid that happening again. We make up for a lack of aggressive auto by playing great tele opp!

[Tim Sharp]

Originally Posted by Nyxyxylyth

Yeah, nobody noticed the encoder wire had fallen out.

We've since put in a timeout, just in case.

Encoders seem to be the cause of a lot of that. We struggled with a similar issue at Rocket City. The encoders turned out to be counting down instead of up.

[Ari423]

423 did that in almost every eliminations match at Springside Chestnut Hill, but just barely so. During quals we always stopped before we crashed. Between quals and elims we upped the power from 50% to 85%, but forgot to change the timing. Now the robot would stop almost exactly 1/2 second after it crashed, consistently. Sadly because of quick turn-around time and LabVIEW's slow and inconsistent deploys, we weren't able (or willing to risk) reloading the code to stop a second earlier. I'd like to officially apologize to any team we may have hit and let you know that we've fixed that problem for Westtown this weekend by adding an ultrasonic rangefinder to auto-stop when we get close to the wall.

[jkoritzinsky]

I never thought I'd say this, but open loop timed auto FTW!

[GreyingJay]

Originally Posted by Nyxyxylyth

Yeah, nobody noticed the encoder wire had fallen out.

We've since put in a timeout, just in case.

Holy cow your robot goes over that moat fast.

[plurp911]

Our robot did this for many matches, and after asking software to make auton end a bit sooner, they decided to go by the motto "if it ain't broke, don't fix it"

[Tom Line]

Originally Posted by Ari423

423 did that in almost every eliminations match at Springside Chestnut Hill, but just barely so. During quals we always stopped before we crashed. Between quals and elims we upped the power from 50% to 85%, but forgot to change the timing. Now the robot would stop almost exactly 1/2 second after it crashed, consistently. Sadly because of quick turn-around time and LabVIEW's slow and inconsistent deploys, we weren't able (or willing to risk) reloading the code to stop a second earlier. I'd like to officially apologize to any team we may have hit and let you know that we've fixed that problem for Westtown this weekend by adding an ultrasonic rangefinder to auto-stop when we get close to the wall.

This is the primary reason we took a year working on implementing a simple text file system where everything is read in from text files that we FTP to the robot. Deploying labVIEW in a competitive environment is nearly impossible. Just FTPing new constant and auto text files takes a matter of a second.

[tcjinaz]

Originally Posted by Nyxyxylyth

Yeah, nobody noticed the encoder wire had fallen out.

We've since put in a timeout, just in case.

Yeah, verily.

Is anyone else watching gravity to see if they're on a defense or not?

[tcjinaz]

Originally Posted by Nyxyxylyth

Yeah, nobody noticed the encoder wire had fallen out.

We've since put in a timeout, just in case.

And the LORD spake, saying, "First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who being naughty in My sight, shall snuff it."[