Encoder Testing

Update 9/1/2011

It amazes me how many bugs were still outstanding! The logs ( 1, 2 ) tell the story. At first the dzk (dead zone skip) was backwards and the start is locked up as the PID cs does not update. At first I thought this was because, that the zero check failed on the encoder, but small enough to make multiply equal zero. I changed to using iszero() check to allow some tolerance just to be safe. The actual fix is in the PID keep reading more on this. I also noticed the squaring has adverse effect on the acceleration and I really should clip when I do square as the numbers became too large. I've tuned down the PID and lowered the range, but I also found the PID getting stuck see here for more details.

Update 8/26/2011

I have updated all the proposed fixes mentioned above and the results can be seen here in this there are a couple of test runs. First I did the full distance run with the "DeadZoneSkip" implementation, and we can see the improvement on the deceleration. To my surprise it really didn't improve as much as I'd had liked on the distance and control, but this is because the PID had to work harder before when I entered the boosted voltage, so really I believe this is the right thing to do as there appears to be improvement (from 3 to 2 inches). The second fix was getting the goal to complete. I found that I need not worry about unifying the tolerance to the voltage override, but instead make sure the goal can have this set. I've used 0.10 by default which is roughly 4 inches, and then I found a serious bug which is the real cause, this is that the PID updates were starved if the encoder speed was stopped. What happened is that the CS (calibrated scaler) was so high that the initial new movement got divided out, and then as long as it never moved the cs never changed. The fix was to allow the PID to update even when the encoder is stopped. This allows the CS to come back down to a reasonable level and viola it works. The new added benefit with the tolerance is that I can now compensate for overshooting to hit the mark exactly! This will require getting the actual distance, perform the run (with the robot really moving) and see where the final resting distance is. We can adjust the tolerance to compensate for the momentum to get the perfect measurement. In the dump I used a smaller distance and the results actually stopped short of the mark which is great, and that means for this distance I could derease the tolerance.

Encoder Testing 8/23/2011

One of the more challenging tasks is to get the cim motors and encoder to agree on the same speed. My first obstical was to figure out a way to inject the actual current velocity into my existing code, and unfortunately this is my own complex issue where the solution was to inject it prior to displacement computation, and set it back to its original value. Doing it this way allows the PID to function properly. Once I worked this out I found that I really did not need the delta slice multiply in the PID. With these changes alone it went from unstable back and forth motions to a case where it over compensates quite often. This over compensation is hard to track down as it appears to mostly be due to momentum. The best improvement I made was to square the voltage, and for short distance testing it did very well. In the test here where I go 4.2 meters even with squared voltage the momentum takes its toll. The PID in this current design cannot help as it climbs up and eventually no voltage is applied it still moves. Fortunately it only overshoots 3 inches, but still I think it can do better.

In the print out, the 'y' is the total disance traveled, and once the threshold is reached the 'VO'' means voltage override where it sends 0 (no voltage). The 'p' shows the predicted desired speed, and the 'e' shows the encoder speed (we only have one working encoder). The 'd' shows the different between the desired speed against the actual speed, and finally the 'cs' is the calibrated scale computed by PID where the 'I' is set to 8.

The interesting thing to note on this test is how quickly the 'cs' ramps up during the deceleration. The problem is that I put in deadzone code which boosts the voltage which then causes this continuous error during the deceleration. The boost helps during acceleration to help the robot go straighter. So the solution to this will either be to only apply the deadzone during acceleration, or to get rid of it all-together once we have a second working encoder. (See below)

One other thing to note is that my torerance is not "unified". I have two difference tolerances, one which governs the voltage override and another which determines when the goal is complete. I should make both of these values use the same threshold as I did for the arm goal. As it stands, when we ran autonomous at the Texas round up scrimmage, it overshot (I have yet to see how much more it does this from the robot actually moving)... and then it missed the threshold of completing the goal, and this is why it never went backwards, and to make matters worse the calibrated scalar never reset which caused it to no longer be drivable. I have fixed resetting the calibrated scalar, but I'll need to unify the threshold and provide a paramter in the goal to control it. I'll default it to something like 4 inches, and shrink this down upon results from improved deceleration.