Quote:
Originally Posted by Jaci
I don't think it's viable. If the play/record is recording actual motor output, that would depend on the voltage of the battery at time of recording. If it's recording desired output, PID wouldn't be viable as the actual output is updated every tick, meaning the PID has no effect. Unless you've got a master control loop running at ~100-150Hz, it wouldn't do much, and even then, you'd see a lot of jitter.
|
Oh, I didn't mean to imply we were using PID loops to replay our recordings this year. We've just opted for a mapping program and just straight programming it. Last year we did PID loops assisting with recording, and it worked well (but wound up not being used). We recorded the encoder position/gyro angle constantly, then reduced them to a smaller set of targets and commands. For example, if the encoder values increased steadily for 4 seconds then stopped, that got reduced to a single PID drive command telling the Robot to drive to the encoder position that was at the end of those 4 seconds. We got it working fully, but then realized it was less work on the robot (and more accurate) to have a few pre-programmed instructions instead of trying to mimic a human driver.
EDIT: The battery voltage problem was something we noticed in the first day, which is why we switched to PID. This is what I'm warning the creators of this macro about
