Quote:
Originally Posted by Uberbots
Abwehr: I understand your code, but in essence it is only correcting for a rate. Sure, it will get the 'drive straight' stuff done, but if the robot gets knocked off course it wont know where to go to.
Given the depth of your post though, i think you already know this d=
We had something similar implemented in our code for the purpose of having the robot 'turn' or 'arc' at a predictable rate... it was good except for the jitter.
|
Actually, it will return to the same position (assuming that the rate signal is not jittery
).
Try it out in excel, and you'll see that you are actually performing integration implicitly.
Make one column a time index (n) 1, 2, 3,... (A)
Make one column a detected gyro rate (random numbers if you want). (B)
Make one column the gyro heading (i.e. =SUM(B[1]:B[N])). (C)
Make two columns for the outputs under the different algorithms (D and E)
D, the original algorithm, would be =D[N-1] (or 0 for the first cell) + Gain*C[N].
E, the non-integrating algorithm, would be =2*E[N-1] - E[N-2] + Gain*B[N].
Fill in 0 for E[N-1] and E[N-2] where those values would be outside the bounds.
Columns D and E will be identical.
The problem with this simplification is it essentially assumes that a 38Hz integration gives valid data. Like I said in the above post, this method is a sort of numerical curiosity - it would throw out all of Kevin's oversampling and timer-based ADC code and the benefits that that brings.