Situation:
(1) As seen in the picture below… the robot upon Enabling Autonomous moves forward for 3 inches and then stops until the time of 2 seconds runs out. Exactly as planned.
(2) Then the robot moves forward until 26 inches as planned, BUT the LEFT encoder (REV HEX Through Bore Encoder) continues to count up the ticks (distance) and the motors continue to run. So the right side stops as planned, but the left side continues.
This motion continues well past the 2 second time limit so we are afraid that not only is the encoder not responding, but also the robot is not reading the time limit in that frame.
To clarify, we are able to read the values of the encoders as the autonomous runs. The distances are accurate, but this is how we know the encoder is working properly, but not responding to the code as planned.
Note that the frame AFTER what is pictures only contains the 0 power command for the drive motors.
There is no 2 seconds time limit. The wait happens independently of the while loop. The only thing that wait will do is lets say the loop finished in one second then the sequence structure would still not advance until the wait was finished at 2 seconds. If you want a two second time limit you should use the elapsed time vi or get timestamp and compare before to current and or that to the loop conditional terminal.
Can you probe the values going into the less than and the boolean going out, also check the wire going out of the selector to make sure it matches what the boolean is telling it. My gut tells me you have some wires swapped, but probing should quickly clarify where the issue is.
You’ll have to help me a bit with how to probe the wires and then run the autonomous from LabVIEW (as opposed to the dashboard).
I know how to run from teleOP where then I can see values on a LabVIEW dashboard, but not auton.
For what you thought might be the issue, we tried literal copy and paste of the first frame and only adjusted the distance numbers. The same behavior repeated.
I would run the program from main using the run arrow. Then you can go to the Autonomous VI and set some probes where mentioned above. Finally on your driver station start the autonomous routine and observe the values on the probes to try and debug what is happening.
You’d do this the same in teleop or auto. You’re likely sending values in teleop through the network tables and either reading through that tab to see updates or writing to an indicator in the dashboard code to view them. You’d place the same VIs you’ve been using in teleop in the auto VI instead.
Though, the probes you can get by running the VI and right-clicking on a wire are easier for this purpose.
You mentioned copy/pasting code. Looking at that picture, it looks like a copy paste of the code. The probe showing the value of the left encoder is something interesting.
Other things I’d consider trying:
Only use one loop while testing. 3 works. What happens if you start with 26? Does it still work? If not, the copy/paste isn’t surprising to see not working.
What happens if you reset the encoders between loops?
Were you seeing negative values with the encoders? I noticed the absolute value being used each time.
Swap the motors in code. Does the behavior follow the change in the code or remain with the left motors?
BIG shoutout and thanks to @jadming for his help this morning!! FRC6391 has a great resource in this guy!
Solved the issue. The problem appeared to be in the wiring from the T/F gates to the TANK DRIVE module (forgive me if I do not use the right words). The left encoder was wired up to the right side motors and vice versa.
Once the wires were swapped, all was good. And a bunch of cleanup tips along the way!
