[kramarczyk]

Great bunch of questions.

Originally Posted by Tristan Lall

I'm not totally clear on how you constrained the system—did you pick the middle hole in the channel, and constrain its surface to ground? I don't think that's going to give you good results in the region of that hole...but far away from it, you're probably alright. (It's not that it's a singularity—as indicated in slide 18—so much as it's just a constraint that isn't representative of the real structure and loads.)

First of all, I was using Autodesk Inventor for the analysis, so there were some limitations imposed by that choice. I originally wanted to cut the frame in half and use a symmetric constraint at the cut face. The purpose of that would be to allow the risers to float. Unfortunately I didn't have a symmetric constraint available. After some thought I decided to discard the idea of cutting the frame since FEA was a very new concept to the team I didn't want to confuse it with an additional layer of abstraction. I just dealt with the additional solve times that this choice required. At this point I needed some piece of geometry to lock down so I grabbed the center hole with the understanding that it might generate some false peak values in that region. You are right that it is not truly a singularity as it is more that a single point. I need to correct my habit of referring to false peaks with that term.

Also, the load of 300 lb_f in an arbitrary direction is a critical assumption. How was that arrived at? I can't help but think there needs to be some consideration of the other forces transmitted through the wheel and the frame in a collision—even in a static case, isn't the loading significantly more complicated in real life? Even neglecting other components of the loading, and focusing on this principal one, what was the reasoning behind this particular magnitude?

The load choice were derived from our ability to replicate the problem. At events we were unable to duplicate the problem in the pit to verify that we had fixed it. This led to 'hope' as part of the troubleshooting process which is less than effective. This also led to us thinking that is was a complicated interaction of forces to result in the chain coming off. In the post season, we played with it and thought we could force the problem to occur during a brick wall push test. We could have come up with a way to run this test at the event, but we just didn't think of it. Consequentially, the load was based off this simple test and the direction was intended to be nominally along the chain path. The magnitude of the force was derived from the kitbot components.

A single CIM outputs 2.42 N-m of torque at stall which converts to 21.4 lbf-in.
The kit toughbox has two 14:50 stages in it for at torque amplification of 21.4*50/14*50/14 = 273 lbf-in
The output sprocket is a 15 tooth #35 sprocket.
15 teeth * .375" pitch = 5.625" circumference.
5.625" / 3.14 = 1.8" diameter.
1.8"/2 = .9" radius.
273 lbf-in / .9" = 303 lbf of chain tension.

I rounded to 300 lbf because it simple. With 2 CIMs per side there would be capacity for 600 lbf of chain tension. With all of that being said, these load can only be achieved if they are countered by the traction of the wheel. During normal operation of the robot (driving on a flat surface) the normal force for each wheel would be around 37.5 lbf (assuming a central CG location). With the kit 8" traction wheels (published mu of 1.0) they are capable of resisting a 150 lbf-in torque at the wheel.
The kit provided 22 tooth #35 sprockets for the wheels.
15 teeth * .375" pitch = 8.25" circumference
8.25" / 3.14 = 2.63" diameter
2.63" / 2 = 1.31" radius
150 lbf-in / 1.31" = 114 lbf of chain tension resistance.

This is clearly less than the 300 lbf number used in the analysis. In order to reach those higher chain tensions a transient condition is required that increases the normal load on the wheel. A trainsient like this can easily be achieved during contact with the bumps on the field, ramps in front of the goals or during contact with other field elements or robots. This is where the analysis gets a little funny. As you mention, this is a complicated interaction and I would feel foolish trying to defend a specific load case. I took a simpler route and viewed it as a safety factor. I felt that the transient had the capacity of increasing the normal force by 2.5-3x momentarily, so that made the 300 lbf load achieveable. There is debate as to if this was a reasonable assumption; I would love to hear alternate approaches.

And because the material isn't actually homogeneous, you've got to be careful with your conclusions about the areas of peak stress which lie in strain-hardened areas (like corners that have been bent on a break). You're probably going to have stronger material in that area—counteracting some of the stress—but with more crack initiation sites that can fail (maybe in low-cycle fatigue). Since the safety factor calculation assumes homogeneous material, there's significant uncertainty here as to when failure (either by yielding or fracture) will actually occur.

Inventor (to my knowledge) is only capable of linear static FEA with homogeneous materials, so there wasn't a way to bake that into the analysis. I understand what you are saying about processing modifying the grain structure and consequentally the material properties. Based upon the time and tools I have available I choose to take any strain hardening as a bonus and make my assumption based upon the lower yield strength. Another important thing you touch on is the definition of failure. Failure come in many forms depending on the application. Material fracture or yielding are obvious ones, but I think in this case excessive elastic deformation causes the failure. Unfortunately, because it is elastic, we don't see any thing obviously wrong after we remove the load.

Now of course, if you just picked this as a worst-case scenario, that seems quite reasonable as a rough estimate. But then it implies that you're not going to put too much stock in the safety factor calculations, because they're necessarily imprecise. It gives you a good order of magnitude study, tests relative performance of several options and highlights points of failure, but won't allow you to say with confidence exactly what the failure loads are.

As soon as I started taking the dynamic environment outside of my robot into account during the analysis it became more of a qualitative exercise that quantitative. I tried to keep the quantities resonable, but a grain of salt is required. I think it certainly provides us with a better understanding of how the loads are carried in the frame and where, specifically, to watch for problems.

So basically, it's a useful exercise, as long as the students are clear on its limitations. The key is to treat this as an estimate, rather than "the solution" (as if it was a deterministic math problem). I think that's basically what you guys noted in your conclusions—good work!

Thanks for the constructive comments!