A significant part of engineering is learning from failures. Many engineering standards exist as a response to a failure of some type. I would like to start a thread where teams share present specific robot failures (failure to control mentors and bad dancing by the drive team would not qualify). I would also like for those teams to share their solution or ask the community for help. If, for example your bot took a strong hit and something unexpectedly bent or broke, show some pictures, tell us about it but be specific. The legitimacy of the hit does not matter (in this thread), but the response of the system does. I believe that we could all learn a lot from the “good work” of others. Remember: if it never breaks, it must not be close enough to the edge.
I know that much of CD kind of get’s to this, so what I’m asking if for a more structured “failure analysis” of the problem, and ultimately a “root cause analysis” I think this would be great all around, as not only do we all get to learn from them, but we get to teach a real world process at the same time.
So here’s some simple rules to follow:
Quantify it. Don’t say “fast” think about roughly how fast
Specify the type of material if you can. (6061 and not just aluminum)
Include Pictures or drawings of the failed part, and in particular a close-up of the actual failure, like in CSI
Don’t be judgmental. It doesn’t matter whether the other guy was going too fast, or they were already yellow carded. Focus on the failure.
The goals of this thread would be to begin to develop some standards and practices for durability built from real world examples so that teams can have a common point of reference for “I built it like this”.
I think as a community we could all benefit from this type of discussion.
**Brief description of the situation:**During our semi-final match at BMR, we lost power to 2 of the 3 wheels on 1 side of the robot. (6 wheel tank drive) Upon further investigation, it was determined that the drive sprockets which transmit power from the trans to the middle wheel and the middle wheel to the front wheel no longer functioned. A replacement was attempted but could not be completed in time. Components Involved:
Andy Mark 2 speed GEN 2 servo shift trans
IFI 24t aluminum sprockets
IGUS .625 aluminum shaft #35 chain
custom turned 6061 aluminum hubs with 1.2 OD, .625 ID and .125 keyway (welded to the sprockets)
.125 tool steel keys
Failed Components
It was determined that the custom hub on the sprocket which transmits power from the trans to the middle axle failed (see photo) , allowing the sprocket to rotate on the shaft.
Failure analysis
There are 2 sprockets mig welded to 2 hubs on the center axle. Sprocket 1 transmits power to the axle via a .125 key. Sprocket 2, which drives the front wheel is powered by the same key. The total length of the key is 1.0, with the hub on sprocket 1 having a depth of .6, and 2 being .4. The design did not specify 1 or 2 hubs. It was built with 2, as 1 is the same sprocket used throughout the robot. The key specified was designed to handle only the load of 1 wheel, not 2. This extra load caused the keyway to get “sloppy”. This slop increased the load on sprocket 1, (interestingly enough this sloppiness was detected before the semi-finals began, but we had no replacement parts readily available). The hub failed.
Root Cause
The root cause was that hub 2 was too small to handle the load.
Remediation
Both sprockets should have been manufactured as 1 part. This would transfer the load from sprocket 1 to sprocket 2 through the hub and not through the key, reducing the stress on the key.
The outer diameter of the hub was too small to handle the shock load caused by the sloppy key, therefore the hub outer diameter should be increased, giving a larger safety factor in the event of the key getting sloppy.
Results
This new design was used at WMR without issue. There was no increase in key “slop” during the regional.
This is more general, but it is something we dealt with several times during the season.
Do not side load motor output shafts. If you are going to run a drive directly from a motor shaft, support the outside end of the shaft.
We nearly failed 1 window motor (keyang) by sideloading it running our arm. The second one held together throughout the remainder of our matches, but the output shaft on it is bent as well.
Likewise, we tried running a high-speed ballscrew directly off the Mabuchi (spelling?) motor, and that motor’s shaft was forced into the motor by 1/4", rendering it inoperable.
Pay very close attention to the direction of load on the motors. Side load is rarely good, axial load is never good. It is a tempting shortcut that isn’t worth it.
You say that the key was designed to handle 1 wheel. Can you explain why or how you know that? Were you using a resource like The Machinery’s Handbook to determine the key to use?
My team ran into a similar situation several years ago. We had a steel sprocket attached to an aluminum hub via bolts and lock-nuts. These were then put on a 5/8"(?) steel shaft. These components were being driven by a Fisher-Price motor. All of the design and machining of the key and depths of keyways had been done using The Machinery’s Handbook as a resource.
During the course of the competition, the key was literally tearing the aluminum away until there was a catastrophic failure in which the keyway on the shaft also gave out.
Our solution was to never use an aluminum hub where there’s going to be a large amount of stress on the area of a key/keyway. The coach of the team and I were so serious about this solution that the following year, a college student was saying, “Let’s use aluminum for the hub, it weighs less.” We told him several times to use steel. We finally said that it was a lesson learned from last year. Then he gave in to using steel.
Not sure if the titanium is a useful grade, but the point stands.
Im sure a mechanical engineer would help me but I remember reading that there is a alloy of titanium that has the same properties of certain alloys of aluminum. It still costs more but you are not getting any advantage over using it.
Compare 7075-T6 aluminum (McMaster-Carr 9063K163) with grade 2 titanium (McMaster-Carr 89145K363). They don’t have the same properties, exactly, but the tensile yield strengths are similar. These particular materials aren’t representative of the huge variety of alloys and tempers available, though.
1726 used dewalt transmissions last year, and had some failures where the pinion gear is attatched to the motor shaft. The pinion gear is a sintered gear, and is bored out to fit on the shaft. There just is not enough material left in the gear to be reliable.
solution: AM shifters this year, no problems at all.
Sorry to sound like a broken record, but I see no reason to use aluminum hubs and shafts in the drive system…weight down there keeps the robot from falling over, and steel is more appropriate for any keyed shafts and hubs. Aluminum would probably be acceptable if it is a hex shaft.
Squirrel:
Was this on the input side of the Delwalt? If so our solution was to make a adapter plate on the delwalt side, it has 4 small holes which match the 1st reduction planet gears, eliminating the need to bore out the gear. On the motor side, it’s drilled to accept the motor output shaft. we than have a setscrew. It adds about .5 to the overall length of the system, but no mods to the gear were required.
Why Aluminum? For this drivetrain, is saved over 7 pounds, and if carefully designed, it can work. Perhaps the question should be what alloys will work for us (most drivetrains undergo similar loadings) and under what conditions.
We ended up doing something similar. A mentor from 245 (I think?) suggested that we put a keyway in the aluminum backing plate of the motor with a file (thanks for the vice 1388!). It wasn’t a solid fix, but it survived through the eliminations and all through championships.
I think that this has more to do with software issues, but no one on the team is really sure what exactly is going on here. (We managed to fix this, but we don’t know why what we did worked.)
The mechanism for releasing our ramps works by pulling a pin out of two holes in two pieces of metal spaced about 1.5 cm apart. This pin holds in place two pieces of string that are attached to our ramps, which are spring loaded. Thus, pin comes out - ramps fall down. The pin is pulled out by means of a servo mounted above the pin. (See the attached image for a better description. Blue is the servo, green is the link from the servo arm to the pin, Black is the pin, red represents the loops of string attached to our ramps)
On practice day, the ramps on our robot started deploying right after the field switched into teleoperated mode. At first, we thought that we didn’t properly set the mechanism and that something shifted out of place when we started driving.
However, the ramps did the same thing in our next match. We double checked to make sure that none of the buttons on the joysticks were linked to the ramp controls. I had also switched out a joystick for a button box so we switched back to the joystick in case there was a wiring problem with the button box. Same problem.
We thought that maybe our driver was hitting the ramp release button thinking it was something else so we talked to him and confirmed that he wasn’t hitting the wrong switch.
We took our robot to the practice field and had the driver start shaking it like crazy, the ramps didn’t deploy. We couldn’t recreate the problem outside of the competition field.
We had absolutely no idea why our ramps were deploying. I thought that it might have something to do with switching from autonomous mode to disabled mode to teleoperated mode, I don’t know why this would have anything to do with our ramp mechanism though because we do nothing in autonomous mode and disabled mode disables your robot. We didn’t have a dongle (we did have one, but it broke before competition. I guess really small wires weren’t made to support a lot of strain, whoops) so we couldn’t test this theory.
We looked through the code and saw that we initialized the servo to 255 (which is the position which keeps the pin in, 0 pulls it out) and not 127, like the motors. We searched the code for every alias for that servo output and nowhere is it modified (except for the function that is supposed to release the ramps). We never programmed the servo to actively drive to 255 after initialization though, so we decided to add code to do that, both in teleoperated mode and in autonomous mode. Somehow, this works. We don’t know why, but it works. The pin stayed in during the match until we flipped the switch that releases the ramps.
Does anyone have any idea as to why this would happen?
Our really only failure through the course of the season was when another robot would get up, over our bumpers and knock off our front steering chain in our swerve drive assembly.
To fix this we added a protective brace above the bumper, on the frame. We never had another problem with it after our first match on Curie.
The servo pwm output always has a value even if you haven’t personally set it to anything.
It can be the 127 that pwms are set to by default in the User_Initialization routine, or if uninitialized altogether then it will be some random value.
When you don’t explicitly give it a value it will retain whatever random value happens to already be in it’s allocated memory location. Most often this random value is zero.
I have seen that servos can occasionally twitch with large random movements when the RC changes states or when it is reset. I’ve observed the random “twitches” to get worse or better depending on the master code that happens to be loaded and which PWM output is used. Victors controlling motors haven’t suffered from a similar twitch since IFI fixed that part of the problem with Master Code v11.
Having the value already set to 255 during initialization then resetting it to the identical value later to solve your problem certainly is puzzling though. It’d be interesting to check the value just before the reset to see if it is occasionally not what it should be. (Makes me want to go play…)
Activity: Removing pinion from two 3" Minibike motor shaft using heat from a propane torch, then striking with a punch and hammer.
Problem: Both motors were very squeaky afterwards and the shafts had more play pulling in and out.
Analysis: The height of the shafts were different from motor to motor. The motor smelled of plastic. Opening up the motors, the armature was hot.
Conclusion: Too much heat softened the adhesive fastening the motor shaft to the armature. The shock from the hammering then moved the shaft backward, where the adhesive rehardened.
Solution: Oddly enough, the solution came right after this incident. Out of frustration the pinion was hammered on an anvil, causing it to fracture and break away from the shaft cleanly. Test on the other pinion was also successful.
We’ve had a lot of drivetrain analysis here, but not much on one of the interesting things I observed in this competition. Many teams specifically had spare gripper components ready for quick replacement. It looked like a lot of thought went into what to bring in order to prepare for gripper failure. Were these teams designing their grippers to fail at an easily repaired point or just going from hard experience or some combination of the two? How did they decide whether to upgrade design or simply repair the existing design when it was damaged?
We made spare parts for our manipulator arm and claw for our regional competition. However, we came to realize that it would likely take about 90 minutes to replace the arm if it became necessary, as it would entail the disassembly of the support structure, and to reset a potentiometer. Our students redesigned the arm between the regional and the Championship so that they could replace it in 5 minutes if necessary. Our students learned a valuable lesson in “Design for Assembly.”
