Hey so we’ve been having some problems while finding the right angle to place our launcher at. We have a tilt motor but the motor is not being very accurate. After working perfectly for a couple runs it would be far off the next. Is anyone having the same problem or know the solution. Is the encoder values carrying over even after we end the program, or are they just not accurate enough for what we are doing.
Encoder counts are not absolute relative to position, nor are they carried over once a program stops or power is cycled. I’m not sure if they persist from run-to-run as long as the motor is powered, but either way it’s not a reliable starting point for what you’re doing.
You might consider putting a routine in the pre-auton() task that moves the tilt mechanism all the way down (i.e., until the encoder value is no longer changing), then resets the encoder value to zero. From there you can move the motor (via the encoder) a number of ticks to get to the same angle repeatably.
One of my teams had a puncher with a tilt motor, and did as @WillRobinson suggested. Pre-loaded with the arm in its down position, then reset rotations on the motor in pre-auton. It worked well.
You could do what WillRobinson said. Or if you can, try a potentiometer. They will remember their position even when powered down. Do note that they have a certain rage they will work with, so if your tilt motor moves past like 270 degrees the potentiometer will stop functioning as intended.
I’ve been struggling with this - thought the difference between rotateTo (A) and rotateFor (B) is A is absolute, B is relative position.
Perhaps someone can clarify this…?
You are mostly correct, but what you must understand is that the point that the encoder thinks of as zero is not always the same, so to counteract that, you pretty much do what @WillRobinson said.
Thanks JtG - we do close to WiilRob’s suggestion but find it to be inconsistent!
We have to methods() to move saw our arm: rArm() & aArm() - r = relative, a = absolute. We position everything B4 turning it on and reset encoders in pre_auto().
Sadly when we as the arm to go to a absolute position it sometimes does, other times not. I ‘assume’ we don’t need to give a direction because the motor should ‘know’ which way to turn.
Yep. This is the perfect use case for a potentiometer if you can fit it somewhere.
Baring that, sounds like it’s time to observe your sensor values directly and understand what’s really happening. Print your encoder values out to the console or Brain LCD and make sure your code is really doing what you think it’s doing.
90% of the time there’s some nuanced and non-obvious logic error that’s screwing things up.