Quote:
Originally Posted by Oromus
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  |
Ahh, I was talking about the initial proposal for putting it into play/record
. Afaik most play-record programs will just read at a given interval and pipe it out to file. It's effective, but has a lot of room for error. I like to think of it as the autonomous last-resort if you don't have vision or motion profiling. It's still better than sitting still
That's just my opinion though, I still think record/play is very effective, especially for games like 2015. For 2016 though, I can see the defenses causing issues.