Smart motors VS potentiometers

Hi we are a new team, on our lift should we be putting our energy into learning how to use potentiometers or integrated encoder modules.
Also does any one have an easy c generic program for a lift?
Any help/advice would be appreciated

Wrenshall Robotics

Take a look at this series of blog posts from Renegade Robotics: https://renegaderobotics.org/vex-sensors-introduction/

Don’t use IME unless you have to. They are not nearly as reliable or simple to program as a potentiometer. Just make sure your range of motion does not fall outside the limits of the potentiometer.

If you aren’t too limited on space I would recommend quadrature encoders. They are pretty much external IMEs that don’t break everything.

If you are using it on a lift then use a pot. It has mechanical memory so if your bot resets by accident after hitting something you still know where you are in lift angle.

+1 on what @TriDragon said. Pots are great if your range of motion is limited. If you need complete rotation (or more than about 270 degrees) try to make room for the shaft encoder. The IME is more precise, but less accurate/reliable. The odds of you needing more precision than 1 degree of rotation is fairly slim.

how about… don’t use either :smiley: only use Optical Shaft Encoders (the big red encoder thingy)

That’s a pretty limited way to go. You can only use a maximum of 5 optical shaft encoders (two wires each, 11 digital ports - can’t use #10). So opting to use nothing but optical shaft encoders means you can only measure 5 different rotations, plus you limit how many limit switches and the like you can use. Switching to pots or IMEs gives you access to the analog ports and the i2c port for measuring rotation as well.

A big question would be what sort of a lift this is. If the rotation is fairly limited somewhere, pots are great as @TriDragon pointed out. You can go further than the normal rotation limit by using gears or sprocket and chain. With significant rotation, this gets difficult. But sometimes, such as with many rack-and-pinion setups, you can swap in limit switches or similar on the ends instead of looking for rotation.

If you don’t need to know which direction the motors are turning (i.e., you already know which way the motors are turning, say, in autonomous), then you can get away with only plugging in one of the 2 wires from each encoder; the other one just does not get plugged in (zip-tie it off somewhere). It’ll cut down your required digital port usage when necessary.

While true this advice can be a little misleading. In my experience people have a poor intuitive understanding of what exactly “not getting direction information” means.

I would definitely suggest this technique for any mechanism which is always in the same direction AND never stops. It can also work when measuring stopping is unimportant.

@tabor473 - thanks for the tip!

Can you? Maybe conditionally only? I can’t call encoderInit in PROS without two port numbers. I thought RobotC also required two port numbers, automatically setting the second one based on the first. What happens inside the code if you plug something else into that port instead? I suppose you could just redo all the encoder stuff by reading the digital input while only looking at one port…

Should be possible in principle. I’ve never tried it to be certain. The whole point of Quad encoders is to provide a direction and higher resolution by basically overlaying the information of both channels and observing the phase shift. Read this for a quick summary: http://www.dynapar.com/Technology/Encoder_Basics/Quadrature_Encoder/

A single channel should provide you with a lower resolution no-direction encoder value. However, I don’t know if PROS or RobotC has the code to handle this case so SensorValue] or encoderRead() may not correctly retrieve the information.

I’d imagine you could try an encoderInit(port, 0) and not have the other port. Or do max int (-1) or something.

RobotC supports “Encode (Single Wire)” mode. That was used with the older optical shaft encoders and should work equally well with the current ones using a single cable only…

Any simple hack is unlikely to work. You need to use an encoder designed for 1 wire, ROBOTC supports this but PROS might not. Observe the 4 states of a quadrature encoder

low high
low low
high low
high high
(moving up along this pattern increases the encoder value, moving down decreases the encoder value)

If you only have 1 wire plugged into a system designed for 2, the second wire is always low (for example) so as the encoder rotates you move up 1 state and then down 1 state over and over.
low high
low low
high low

high high

If you have ever had a wire come unplugged from and encoder you see it alternates between 0 and -1 or between 0 and 1.

All this is why I said “Maybe conditionally only?” I couldn’t guarantee it would work in any let alone all programming environments, at least not without a lot of work-around just reading the digital signal.