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
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:
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.
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.
