How to go about programming the elevator

So, no sensors. No limit switches for a while. Just a Talon SRX, the motor, and an elevator. How would I go about programming it so that when a joystick moves its Y axis, the elevator would start ramping upwards until a certain height, and then go down to where it came from.

We have not tried this but I have seen other teams mention using hard stops and monitoring the current draw on the Talon to know when they have hit the hard stop. Maybe it would be possible to affect the current draw at a set position on the elevator in some way. Just brainstorming here so it may not be a great suggestion.

As noted in this rambling thread, current reported and limited by the Talon is average input current, not output current. At low output commands, this can mean there’s a significant difference between the current reported by the Talon and current in the motor. So I’d use this method with extreme caution unless the elevator’s driven by (mini)CIMs.

FYI, there is another parallel thread from the same OP here. Would appreciate is a mod could merge.

Even still -

Guess what kind of motor we’re using on our elevator. Also, guess what kind of motor we burned out Sunday night :).

OP -

I believe what you’re describing is some sort of closed loop system.

Here’s how I’d break the problem down: The operator commands a “desired height” (in inches). Maybe this is based off of buttons or joysticks… but at the end of the day, you’ve got some variable in software that represents what height the operator wants the elevator to be at.

The job of software is to run the motor such that it actually gets to that height.

If you knew everything about how your elevator worked, you might be able to get by by running the motor for certain periods of time - enough time to cause the elevator to run to the desired height (as commanded by driver input). However, things like friction, a pit crew re-assembling things slightly differently, or another robot crashing into you will probably change how your elevator works slightly. But, enough that a time-based strategy will likely not be good.

What we are doing is measuring the actual height (again, in inches) of our elevator. We do it with an encoder on the gearbox, plus some fancy schmancy math to get from shaft-rotations to inches-of-elevator-height. I’ve heard other teams using a LIDAR or other sensor. But, the key again is, you have a variable in software which represents the actual height of the elevator above the ground, in inches. At any time, you should be able to measure this height with a tape measure, and the variable should always report the same height.

Once you have both these desired and actual heights in your code, you can now start to write software which compares them. A super simple (but highly functional) strategy (known as “bang bang”):



heightError = desiredHeight - actualHeight;

if(heightError < -0.5){
    //Cause downward motion
    motorCmd = -1;
} else if(heightError > 0.5){
    //Cause upward motion
    motorCmd = 1;
} else {
    //Stop motion
    motorCmd = 0;
}

motorController.set(motorCmd);


There are more advanced ways of doing this (see PID), but at the end of the day it’s the same story: You must know where you are, and also where you want to be. You do some logic & math on these numbers to generate motor control commands. For well-designed logic and math, those motor commands will cause the end system to go from where it is, to where you want it to be.

To accomplish what you’re asking for, you’ll want to ask your mechanical & electrical folks to help you add a sensor to the system. Not sure if this is reasonable for your team on bag day or not.

Presuming it’s not, here’s an alternate control strategy: Put a human the feedback loop.

Tie a joystick value straight into the motor command. The operator will see the height of the elevator, and move the joystick. The joystick movement will cause the elevator velocity to change, making the elevator go up and down. The operator has to manually adjust the height by inputting velocity commands via the joystick. Yes this requires some skill and extra thought from the operator, and is more error prone. But, it doesn’t involve adding an extra sensor.

All of engineering is tradeoffs :).