Hi everyone, this season really pushed a lot of teams to develop large mechanisms with many points of failure, and I think everyone saw a robot’s elevator/arm snap off sometime this season (us included). This leads me to my question: what are the best teams doing to stop their mechanisms from self imploding under shock loads (i.e. when their motor is holding a position, and the arm is rammed into a wall, the motor tries to hold position and the mechanical parts of the arm fail first)?
This season our main programming push was for swerve drive and swerve autonomous, which I think we were able to hammer out. We lacked mechanism protection that I think could have elevated us even further. I hope that during this offseason we will be able to make improvements with that, but I don’t know where to point our students.
I think the most important thing is to plan ahead. One of the main failure points for us during the season was whenever our arm had to move a great distance from one setpoint to another. The PID was way too violent for the robot. This led us to add physical and digital safety measures. For example, using a ProfiledPIDController as well as clamping the output to a certain safe value made it so that the arm couldn’t move too fast or it made it far more controllable, given the acceleration and deceleration.
Not a direct answer to your question, but if the mechanical side of things is the failure point, then you really need a mechanical solution. Adding plasticity/elasticity to the mechanism does wonders. Surgical tubing and gas shocks work well to provide some shock absorption to a system. Pneumatic mechanisms can also provide some shock absorption capabilities in the actuator itself.
It turns out that if you don’t want to break your mechanisms or the field, a good way to do that is to prevent your mechanisms from exerting too much force.
This strikes me as a design issue. Collecting game pieces from the HP positions should not have needed the arm to be extended. Many teams would design the arm position such that when the bumpers reached the wall, the intake was at the proper location to collect the game piece and therefore the bumpers protected the arm from getting rammed into the wall. During ground intake mode, you could design the intake to rest against the bumper such that ramming the intake into the wall when in ground intake mode would not exert high loads into the arm or joints (only into the intake itself).
The only time you needed to have the arm extended where it was exposed to the kind of damage you are describing was during scoring. Generally, in this case, your bumpers would be very close to the scoring grid such that you really could not ram the arm into the wall by driving forward on accident. However, when the arm is extended like that you could potentially rotate the robot and swing the arm into a wall. To address tis concern, you could lock out or limit rotation of the robot (in code). Or you could lock out high speed motions in any direction when the arm was in an extended position.
The bigger concerns that many teams had with the arm in the extended position was the tippiness of the robot. For that reason, we implemented a “stowed position” for the arm that we used whenever we were driving at high speed. That alone should help prevent high speed collisions between the arm and the wall.
So, in general, you should be able to design the arm positions as a part of your overall robot control scheme so that you are not exposing your arm to the risk of being rammed into the wall.
Redundancy: logic protections, carefully constructed control loops, mechanical protection. Built such that any one of those options will save from a catastrophic event of the others failing and all ideally working together such that a catastrophic event is difficult to reach in the first place.
Logic protection: sensors and soft limits and code to prevent unsafe configurations (without automating absolutely everything, you need to be able to recover mid match from the drivers station if logic fails, often called safety subsystem)
Control loops : current limits and appropriately tuned PIDs or feed forward
Mechanical: hard stops, clutches, complient mechanisms, designed failure points
One thing that has been done in years past on teams I have been on: give the programers a quick and dirty approximate prototype for high degree of freedom systems (i.e. arm gripper and intake interaction , or mechanisms that could theoretically sweep through the same space) (made from brushed motors, plywood, polycarbonate, pool noodles, etc) they can test logic on in the real world without fear of breaking the bot. Get it mechanically representative (no need for an exact replica, just the appropriate degrees of freedom). Give them the opportunity to be aggressive and try to break their code (with good logging and graphing of course, so they can find the problem)
I think the other answers have covered pretty much everything but I’ll list some things we did
On our elevator we had a disk break to prevent burning out a motor when holding it still, it was taken from a bicycle and we attached a piston to the cable.
For every single PID controller that was used, we would clamp the output to safe values in case if the error is extremely large
Similarly, we used a slew rate limiter on a bunch of mechanisms that were driving a motor at a constant speed. It would limit the acceleration so we wouldn’t have too much shaking or risk putting too much torque on the motors. Next year though I want to try using trapezoid profiles so we can have smooth motion everywhere.
