Inspired by this post.
Doesn’t matter if it happened off-season. Just doing this for fun and a learning experience!
12 Likes
Testing the robot on a cart/table with the wheels touching said cart/table… bent a few frames doing that.
Having the IMU in a different ordination on the practice robot and comp robot.
Given the robot 3 days… 3 hours before bag to program.
4 Likes
For my team, I think that goes to @cpaggron setting the shooter motor current limit to 1000 for testing purposes and forgetting to revert it back to 80 on practice day at our first competition. We got one note stuck in auto and immediately cooked a motor. The next day, after we had swapped the motor and fixed the current limit we got a note stuck at the same point in auto and he yelled to a-stop the robot, leading to a yellow card for technician communication.
4 Likes
Spent about half of Tallahassee troubleshooting issues with field oriented drive to find out one line of code was causing our issues.
Enabled the robot without taking it off autonomous mode, it rammed directly into my leg, I still have a scar.
I reset the swerve wheel offsets because they were slightly off but I did it in the opposite direction they were originally set to so we ended up tearing up some carpet after trying to drive into a wall continuously without realizing it was running.
1 Like
We spent countless hours developing an auto-score for 2023 and got everything right. We then found our gyros were misconfigured and deteriorated by 10-15deg/match, meaning it didn’t work.
Another time, we deployed code before a playoff match but the rio lost power midway through and needed to be reimaged.
We also have racked up over $1,000 in drywall repairs due to bad coordinate frames.
5 Likes
I had a similar experience lol. We were given the robot 3 hours before bagging.
Although we technically had the robot for the last week, we barely had any time to test at all, because there was always something that needed fixing (ie: something went wrong during test; elec/mech take the robot back). This is not to blame elec/mech or anyone on the team, we were quite behind on schedule and sometimes things just happen.
We had a “dummy” robot that we’d use to test code before we rewrote it for the real robot. This dummy robot roughly mimicked the real robot, but it almost caught on fire, so it was out of service.
We (programmers) got electrical to give us a series of specifications on paper which told us what devices were plugged into what, what subsystem they belonged to, and what purpose they served.
So we were basically writing code off of theory, we didnt have any robot on hand. Luckily, our main functionality worked perfectly, it could shoot, drive, intake and do whatever in teleop mode.
However some of our autonomous commands didnt work as intended, but we had prepared with multiple contingency autos. We still achieved our goal of having a 2-piece auto + leave.
2 Likes
My freshman year I required just about every Subsystem on the robot for an LEDCommand and almost broke the climber when we tried to run the code the night before load-in for a competition
8 Likes
I saw some teams get a Yellow card for that too, luckily one benefit we had was that one of our drivers is also one of our programmers.
So he was able to recognize when something during auto was going wrong very quickly, so he can A-Stop before anything bad could happen.
I also reccomend informing your driver/operators on how possible ways your autos can mess up, so that your drivers know when something is going wrong and hit A-Stop.
3 Likes
In 2020 my very first year in FRC, i was programming PID for a turret, i had no idea how PID worked, so i set the gains to a very “reasonable” 50, the hard stop was no match for the speed of the turret
10 Likes
I got one, last year our lead programmer was not the most open minded person. He wanted to try to do all this stuff that we just did not have time to do and would never fully do 100% of something. well we are at bayou and our lead programmer the day before adds logging so we are recording everything that happens on the field well what ended up happening is for the first 3 match’s we did not move, but no it was not a programming issue it must be the can, then finally we convinced him to remove it and then BANG we move.
1 Like
That drywall part reminds me of this one time, where i was testing out some driving code for funsies (this is off-season), and I accidentally drove full-speed at into a door.
That door had to made from the branch of a sacred thousand year old tree, for that door did not budge one bit, and only a chip of wood broke off from the door.
I don’t think that was even the first time we rammed into that door, it was strong as heck.
4 Likes
The 8 steps, we were the first to learn 6/8 of them will cause the robot to spin out of control 
3 Likes
Our driver from 2022-2024 had her first time driving our robot from 2020 and ended up going full speed into the side of an open door. Surprisingly the only thing that broke was the intake bending in
didn’t program the limits on our arm correctly a couple times, so it was either slamming into the ground or bending the limelight mount (luckily the mount was a thin metal sheet so we just bent it back. I really dont want to think about if it was 3d printed or strong enough to resist the arm)
2 Likes
This past year we had a really weird issue where our auto routine would run the first few steps, and then immediately stop as soon as it shot the first note. We couldn’t figure out why. We reverted code, issue stopped, but we didn’t investigate enough.
Somehow, the code we reverted made it back in (probably because it was in another branch, and we didn’t realize it was the culprit), an saw the same weird behavior at a week 4 event.
Eventually we found that we had a trigger that would automatically start aiming our wrist once we took in a note, but more specifically when that note left, we would command the wrist to go back to the home position. This interrupted the auto command group, stopping auto after the first shot 
Lesson learned: make sure triggers that might occur in auto don’t command subsystems used by auto
Back in 2023 we spent a while debugging our charge station balancing code only to find a WPILib bug. Also, mistimed commands in paths led to the robot slamming a NEO 550 on an intake against a wooden cube node during auto testing. Surprisingly, the motor was fine, although later it started smoking due to the lack of a current limit. The motor eventually got some walls around it to protect against future incidents (later, another bot ran over our intake in a practice match).
Unrelatedly, our robot’s arm created a minor fire when we were moving it and it went past its limit and ripped some wires.
In that same year, it took a while to realize that 4" neoprene swerve wheels do not actually have an effective diameter of 4" (especially when you use the same tread throughout the entire season), and this made us need a lot more time messing around with auto paths. Also, in general, we spent way too much time on auto testing and not enough time on driver practice, which went unnoticed in part because our drive team was essentially our programming team.
We also ran into an issue in playoff eliminations where the auto SendableChooser just completely disappeared from SmartDashboard. I tried to create a fix by creating a button to resend the same chooser but with random digits appended to the name. Unfortunately, during the next match, the old chooser stayed on the dashboard and caused confusion, causing the wrong auto to be selected.
This offseason, we had a few issues. Our shots depended on the ClosedLoopError motor signal to determine whether the shooter flywheels were at the right speed, and I later realized it only updated at a rate of 4 Hz by default on the RoboRIO CAN bus. This created nondeterministic behavior, especially with the auto preload note, where the bot would sometimes try to shoot the note before it should be doing so and just get the note stuck.
This issue was only noticed at the offseason competition because we didn’t actually test any part of our autonomous before competition. If we had, we also would have noticed earlier that the robot’s headings were all rotated by 180º in the autonomous path, which explained why the robot didn’t seem to be following paths correctly (it was trying to move into the subwoofer when it should have been moving away from it).
And, before a match, I changed the output voltage of the indexer motor to try to help fix notes getting stuck in the intake. I’m not sure whether it actually improved the intake situation, although it caused notes to get stuck in the shooter.
I also spent half of the qualification matches trying to fix our shooter speeds. There was a minor angle issue, I changed the speeds, there was a greater issue in the next match, I changed the speeds even more for the next match, etc… Eventually I settled on a slight increase over the speeds we had had at the start of the competition.
at our first comp this season, our auto failed like 3 times because of mismatches between the names that appeared on shuffleboard vs the actual filenames of the pathplanner autos. after the 3rd i think i quickly wrote out an enum and called it a day. that was a silly one
1 Like
Same horror story between the 2 threads
13 Likes
Inverting things in the wrong places leading to an all day bug hunt in 2013? during comp.
2 Likes
I accidentally changed 0.1 to 0.9 instead of 0.09 in our charged-up auto balance PID. We were running a 6 neo tank drive so that thing could go if it wanted to. Our robot got at least a foot off the ground but somehow survived with no issues.
3 Likes