Quote:
Originally Posted by Al Skierkiewicz
Greg,
In looking at the data I am guessing the 250 ms is the delay between the transition of the PWM and the first change in the gyro output centered on 3000ms in the top graph? I think we need a little more info. Are you feeding the gyro directly to the RC or are you using a sub processor to interpret data from the gyro? Are you using someone's code or your own?
|
Yes, the 250ms is about the time it seems to take the measured gyro heading to start to change and the additional 175ms is when the robot stops (or at least the gyro says it stops) and reverses direction. I am basically using Kevin Watson's adc and gyro code. We are sampling 5 analog inputs, each input each ms (1000Hz) so each channel has a 200Hz sample rate and every two samples are averaged so the effective gyro sample and processing (integration for position is 100Hz) Last year the KOP gyro data sheet said its analog output bandwidth was about 40Hz so I think we are OK sampling at 100Hz. I have not noticed any delay in the gyro output but maybe PhilBot is right. It seems like a good test would be to rotate the gyro into a limit switch and stop and look at the timing of the gyro output along with the digital I/O timing and see if there is significant delay. In this test it took about 2 seconds to rotate 90 degrees or 1571mr (we use mr for angles and cm for distance to make integer math reasonable) so I don't think we are coming close to saturating the gyro rate output.
Quote:
Originally Posted by Al Skierkiewicz
I am not a software guy here so I am working from memory on what I think our software team has discussed in the past. Their thought had been to look at several samples from a gyro to determine if the data was in error or that an actual trend was in effect. It was only then that they used the data to effect a change.
|
It is interesting you mention it because we were looking at the Get_Gyro_Rate() numbers last night and they were bouncing around quite a bit. The gyro angle - what I plotted is nothing more than the integrated rate outputs (100 times per second) so sampling the angle every 26.2ms is kind of like averaging 2.6 rate readings which are already the average of 2 A/D readings. To get the rate we actually take the difference between the previous and present angle because it gives us better results. Besides we are trying to use the same approach to rotate the robot to a target or between two targets and when the camera is giving us angle info we only have the heading to the target. - In summary, from what we have seen Kevin's gyro code with 200Hz sampling and two sample averaging along with the KOP gyro is good with the angle output.
Quote:
Originally Posted by Al Skierkiewicz
In reaction to the drive spinning backward while the robot is trying to stop is an indication of fairly high loop gain which also appears in the graph. If you are attempting directional control, I would expect smaller changes in the PWM data. The gyro graph does show some damping but I think it should be even greater which may occur with a lower gain. I would also expect that the PWM values would decrease as the gyro output decreases.
|
What you are seeing is our first attempt to try to use the angular rate as a D term and to only finish a turn when the gyro angle was within a 1 degree tolerance and the angular rate was small. Previously we just had a P loop with an error input of mr and a gain of 1/8 or some other power of 2 and simply declared the rotation complete when the gyro angle fell within the tolerance window. So for instance, if the turn was 90 degrees the initial error was 1571/8 or about 196. This number was added to 127 for one motor and subtracted from 127 for the other motor and the result was clipped at MAX_ROTATION_SPEED which is currently set at 50. At 10 degrees away the PWM values were 127 +/- 21 and so on. The problem with this approach, especially for small rotations was that the PWM differential was not big enough to get the rotation going and we still overshot our target a little.
So the first attempt for the new design - "pictured" was
PWM = 127+/- (P*error in mr + I * sum of error in mr - D * angular rate(mr/sec))
The I term is set to zero if the robot is moving so it only helps to get the robot moving whe the P term is too small. Of course it also comes into play when the angular rate is near zero at the end of the rotation and that is probably needs to be fixed. I think for the data I posted P, I , and D were all 1 because we were just trying to figure out if we had the logic right. Because the magnitude of the P and D terms were too big the result was kind of an all on/all off situation. What caught my eye of course was the apparent delay in the system. As far as the loop bandwidth is concernded.
when the gyro is being used the loop runs every 26.2ms when the camera is being used and only one target is detected the loop runs at about 1/3 that rate and when two targets are detected it runs at about 1/6 of that rate since it takes the whole, left, and right virtual windows to get a two target solution.
Quote:
Originally Posted by Al Skierkiewicz
Does any of this make sense? It was a long day preceded by a short night.
BTW, the view in your photo looks familiar, where in NM was the pic taken?
|
Yes, it does make sense and thankyou for taking the time to help. As for the picture, to be honest it was such a wirlwind spring break trip I don't remember now - I'll look through the pictures and figure that out!
- Greg