You said to answer one last question, which I did.
Beside, I don’t understand what you mean by “at10 sec in” and “20 Days”.
If you mean what happens if you run the program for 10 seconds and then inserted microsd, then it will keep adding new lines without wiping the file clean. That happens only if you inserted card before starting your program. It wipes it clean only once at the beginning of your program.
What happens if you run program for 20 days with card inserted?
150 characters every 10 milliseconds times 60 seconds times 60 minutes times 24 hours times 20 days
That is 25,920,000,000 bytes!
You better have 32Gb sd card and super duper gaming laptop to copy & paste so much Rerun Stuffz.
actually, brute force is an acceptable first start. I did more looking vs my “know it all” attitude and the approach is honest and straightforward. It also represents what most go for with time based solutions - then they realize EPs are spraying fields with goop designed to slow robots down… and don;'t forget robots who get smashed up a bit and have no parallel drive structure.
Look, I was wrong about my early critique. We should not make it “here is a play loop so you do not code” but this is a nice way to show what happens when you record motion and try to make it an autonomous. It might not be pretty to look at, but it is a start as others have said. By exposing the code it hopefully encourages new teams to think “I get this” and, hopefully, “there is a better way”.
The tutorial is honest and a good teaching tool.
Thank you @TaranMayer for providing the catalyst for a great discussion!
Also here, unlike with Cortex which would use power output, my rerun records actual velocity. Not voltage, not velocity set to, but the ACTUAL velocity the motors are moving at. So in theory, I could push the bot around and it would record the movement.
That is not the biggest reason (pun intended) to be cautious about this approach.
As @lacsap pointed out, the more important reasons are variability of the fields on which you test and compete due to anti-static application, field setup tolerances, robots starting to fall apart after collisions, etc… which time based reruns may not handle well.
That is a very simple yet effective way of improving accuracy without starting to make code more complicated. Special handling of the claw motor was also a nice touch.
Simple reliable time based autonomous could work better than the poorly configured PID based code. However, well written code that relies on the feedback from various sensors to do odometry and PID control, will undoubtedly work better in all circumstances.
The best part of @TaranMayer’s tutorial is that it demystifies “rerun” capability and shows how little you need to get started. It is also shows how you can streamline your workflow to the point when you can come to the untested field and walk away with working autonomous in less than 5 minutes of the field time.
Another “best” part, is how ridiculously large and inefficient is the auto-generated code. I hope that every team that tries it, will start researching ways of improving on it, thus the benefits of active learning.
You did very well answering tough questions and explaining how this method works. It looks like @TaranMayer’s tutorial did great job at helping you and everyone else learn something new today.
And finally, to be pedantic, V5 only supports SD Cards with FAT32 file systems tested up to 16Gb and with 4Gb max file size, so no 20 day runs. Sorry to ruin your expectations.
Just want to point out that teams have been using replay/rerun programs for as long as I can remember. I can’t find the one I posted perhaps 6 or 7 years ago, but here is an example from one of our former competitors who did quite well
I’m currently trying to combine the delay()'s when I can, to further reduce the file size. If anyone has any ideas for that please reply to this with said ideas. I have thought, but it seems to be a little finicky.
You could just only save the velocityUnits in the text file and run a loop that loads all of the data from the file on the sdcard, at least that’s what we did so we don’t need to bring out the dongle, load the sdcard, and fire up VEXcode after every recording session.
Heh, it’s been a while since I’ve been tagged on this forum. This was one of my more fun pieces of programming I did during my vex ‘career’. I also think we may have been the only team to use rerun at the world champs so far (although, I have been out of the loop for a couple of years now). Off memory we seeded first with it and won pretty much all of the auton bonuses - until we changed the drive motors for eliminations and everything fell apart!
Rerun has always tickled me a little bit so I love seeing people give it another go.
Some tips we found:
Some sort of control loop is a must
We tried a positional PID loop to start with (at x time, we should be at x encoder position), but found that error just built up on itself and got exponentially worse
The best solution we found was a velocity PID loop, where at a given point of time we knew the velocity the wheels should be at - you can then determine the motor power given a baseline of the controller value, and a PID loop
Because you have one big continuous control loop essentially, you can tune your constants as the autonomous runs based on the error from the last iteration - we found that the longer the auton ran for, the more accurate it go becuase of this (ie, the last 55s of a 1min auton skills was more repeatable than the first 5s).
The point above can help you quickly tune your loop before a match if you are allowed 5 seconds or so to run a forward/back/turn program and autotune to the current field/robot condition/battery levels
Also, this was all before V5 - I have only used V5 a little bit in the beta program so there may be fun features you can use now!
Thank you Jack. I am currently recording the velocities of the motors, in terms of what they’re actually doing, not what they want to be doing. I believe that this is similar to what you did. Is.it not?