# Encoder Problem

Team 5430 thought they had a really strong autonomous code for this year, but had nothing but problems and reverted to drive for time.
We have finally have both encoders reading and working but we are getting really weird responses. Sometimes the left encoder stops the left side but the right side runs continuously, but sometimes it is the right side that stops. I’ve uploaded an image of the specific code. I think the problem lies in the logic that stops the while loop

Thanks Jack Gillespie

Hi Jack,

Are you zeroing the encoder values at autonomous init?

Alan

Yes we have the Encoder Reset VI wired in just be the screen shot

I think you have a logical error.
Yes, you need to zero the encoders before, and zero (or stop) the drive after this. But the logic to continue the loop may be wrong (see attached).

The while loop has two modes,
A stop if True mode (what you currently have it set to) - designated by the stop sign
A continue if True mode, or stop if false - designated by a green arrow

There is a Boolean rule that sais the “Not of the And is equil to the Or of the Nots” that is to say that it would be logically equivalent (as far as the loop is concerned) to invert the comparisons, and OR them (I hope this shows how you’re stopping the loop in a couple of cases where you don’t want to).

I think there are (at least) two correct implementations for the logic:

1. just swap the and for an OR
https://i.imgur.com/VdCGwCo.png
https://imgur.com/a/N1HD5zA

2. invert both comparisons and take the And (remove the invert you currently have) - you can use a complex for this, set the mode to AND and invert both the inputs.
https://i.imgur.com/afkom1K.png
https://imgur.com/a/hnfQeqX
https://i.imgur.com/7HzL789.png
https://imgur.com/7HzL789

There are other solutions that involve changing the loop to “Continue if True” mode; personally, I prefer to use the “Stop if True” mode primarily because it is the default (although switching context from other languages can get tricky).

I should also note that Breakaway (3937 - the team I worked with while in college in Arkansas) had better success using the gyro to drive straight (using it as the process variable on a P loop and sending the output to the arcade drive x) and just using one encoder for a P loop feeding into the Y axis of the arcade drive (although one year, we did use both encoders. We read both, negated the one that went backwards, and used the average of the two to determine the distance we had gone).

Yes, you need to zero the encoders before, and zero (or stop) the drive after this. But the logic to continue the loop may be wrong (see attached).

Jack, I think both parts of Matthew’s post here tell the story. You’re exiting the while loop as soon as one side reaches its threshold, so unless you immediately follow the while loop by a command to stop both motors, in most cases one motor – the one that didn’t reach its threshold – will continue to spin.

I should also note that Breakaway (3937 - the team I worked with while in college in Arkansas) had better success using the gyro to drive straight (using it as the process variable on a P loop and sending the output to the arcade drive x) and just using one encoder for a P loop feeding into the Y axis of the arcade drive (although one year, we did use both encoders. We read both, negated the one that went backwards, and used the average of the two to determine the distance we had gone).

+1 to this – this is how we code a simple straight-ahead autonomous.

Alan

Mshafer, AlanG, thanks to both of you.
You were absolutely right.
I took Shafer’s spread sheets and created one based on what we had and it was immediately obvious what the problem was and why it was a problem.
We have changed the and to an or and have already tested it.
Once we have finished testing all of our flavors of autonomous code, we are planning on connecting a gyro and an accelerometer and experimenting with them.

Thanks again for the help