Precautionary Measures Against Climber Plate Bending

We are using a Climber in a Box/ThriftyBot telescoping arm design for our climb this year, and we accidentally ran the motor in the wrong way when the rope was already tight to hold the climber down. This results in us bending the support plate pretty heavily. I feel like this will happen again once we are climbing. Is there any good precautionary measure besides being careful and having stronger plates to prevent this?

I would say that you should definitely have your programmers implement soft limits on the motor to stop it from driving too far. Not sure about physical solutions.

1 Like

Limit switches?

That is, sense the physical situation of the system and, if it enters a configuration where damage could occur, use software to stop it before the damage and allow the operator to address the issue.

When you say “support plate”, it’s hard to know what you’re talking about. A picture of the part that gets bent could help get more specific answers!

That said, there are a few things you can do. Sensors (limit switches, for example) can help ensure the motor won’t move past the hard stop. We used Neo’s on our climber, and instituted a “no-stall” mode - basically, if we’re commanding it to move (in either direction) and it doesn’t, then assume something went wrong and cut power. That prevents us from driving it up while the ratchet is engaged, and prevents us from driving it down past the bottom.

You can also look at your physical structure. A plate bending means either a force significantly more than expected, or you don’t have anything in place to prevent the plate from being torqued to the side. That’s where a picture can help :slight_smile:

Just another possible solution. Some combination of logic based off motor direction and current.

If(motorIsNotClimbing and motorCurrent>40 A)
stopMotor

I don’t have quick access to the robot right now but it is the plate on the bottom of the climber holding up the winch spool. The programming soft limits and limit switch should do the job! Thx.

If you only have a plate on a single side holding it, then that explains it - it applies a torque on the plate that can bend it given enough force. It’s better to have plates on both sides supporting your shaft - that eliminates the torque and creates a much stronger structure for something like climbing!

If I have a chance at our meeting tomorrow, i’ll grab our code for the “no-stall” mode and post it - I have a feeling it could help many :slight_smile:

Here is a printable microswitch mount for the 2-stage CIAB that you can directly connect to a SparkMax to implement hardware limits: AndyMark Climber In A Box Limit Microswitch Mount by MadOverlord - Thingiverse

Also, one thing you can do in pure software is have it assume that on startup, you are fully retracted, then keep track of the motor position and once it has gone past a certain point (say, 5% extension), don’t let it go back below that point.

Hope this helps!

3 Likes

We do have plates on both sides - sry if that wasn’t clear in my previous posts.

It will indeed. Thank you so much!

…2177 code…
As Iproposed this code feature, I originally suggested it as a ‘Safe-motor’, or else a ‘Smart-motor’. The students liked the NoSmoke name immediately when it was mentioned, it stuck. Because this extends our existing TachMotor (tachometer…) class, with the one @override, it could be activated or deactivated with a single line-edit within RobotMap/setup code. Plan was that no subsystems/commands needs to change when this is enacted for key motors, the ‘feature’ is automatic once the motor-variable is created…

Note this ‘danger-limit’ as currently coded could be a big handicap; there is no reset, so each command-start likely adds a couple counts of err, and multiple commands to traverse, etc. could easily fail when they should be safe. This isn’t a problem for us so far, a stop()/reset() could rectify this, e.g. if called from command-end()…

NoSmokeMotor.java (994 Bytes) TachMotor.java (3.0 KB)

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.