I am trying to program presets where a lift would go up a set amount each time a button is pressed. Like if button 3 is pressed the lift will go up 12 in. If button 2 is pressed the lift will go down 12 in. Could really use the help.
While it is possible to do this in TeleOp using a state machine, it is probably easier to put this code into Periodic tasks. You can directly check the joystick button there, or you can check the button in teleOp and use a global or other notification mechanism to tell the periodic loop what to do.
The buttons will either add or remove some value to a common set point, and the loop will drive the motor as appropriate to get to the set point.
I know that I’ve glossed over many of the details, but I don’t want to go into details that you don’t need. Feel free to ask more questions if needed.
Greg McKaskle
Hardware: Maybe this is obvious to you, but assuming that you have a motor or other actuator that can move the lift, the most important thing you need to make this work is some sort of feedback sensor that tells you how high your lift is. You could get the AndyMark “string potentiometer”, but it’s limited to about 30" of travel. You could use one with a second string tied off to the top of the shaft and the lift, then passing through a pulley at the top of the potentiometer string to reduce the travel by a factor of 2, but that seems prone to tangling. If you’re interested in a design which we have built and calibrated but not yet used operationally, PM me and I can send you build directions for the “electrified tape measure” we’re using do do this; the only required tools are a hack saw, drill press, vise, wrenches, and screwdriver, though a chop saw makes most of the cutting easier. Apart from the 10-turn potentiometer (about $15 from Jameco) and a bit of scrap aluminum that we cut off the KOP drive chassis, all the parts and a 1-1/8" spade bit were bought locally (Lowe’s, Radio Shack, Hobby Lobby, Ace Hardware) for about $25.
Software: You need to have a variable that keeps track of how high you currently would like the lift to be – on the ground, one tote up, two totes up, etc. You may have intermediate stages as well; last I checked we had four additional positions associated with: flipping totes, scoring on the platform, pulling things off the step, and doing the coopertition stack. The value of this variable is the “state” of the “state machine”. You then develop a set of “state transitions” (probably using case statements) to handle rules like:
- If you’re at ground level, and “up” is pressed, got to level one
- If you’re at level one and “up” is pressed, go to level two
- If you’re at level one and “down” is pressed, go to level zero
Then, you drive your lift to the desired level using your favorite algorithm, whether it’s a PID or something fancier or simpler.
Both Greg and Stevil99 have made good points. I just want to point out some additional options.
As far as software, it may be advisable to use a pid, have the buttons select a set point (which is “remembered” either via a shift regiser or a feedback node), and some way of measuring the location of the elevator. My team typically utilizes encoders connected to the gear box (this yields a position relative to power up), alternatively, one could use a 10turn pot (yielding an absolute position). I won’t go into details on that, but I am attaching an examples of what it could look like.
To change from encoder to pot, merely swap open the open and read vi’s. This version would be for use in Teleop (it is designed based on the idea of a state machine, although not a true one), to put it in Time Tasks, switch the loop constant to false so it doesn’t exit.