Anyway to record driver run for autonomous

Wondering if its possible to record driver’s run so you can use it for autonomous. I guess like a replay or something so autonomous would be easier and maybe more accurate? Probably a program that you could copy and paste for autonomous. It would help some new teams if they don’t know to much coding but anyway any robot would need some sensors. Thanks in advance

Yes, it has been done before by a number of relatively advanced teams. No, it is not a trivial matter, and it would need to be tuned for each specific robot.

I wouldn’t advise a new team to use such a solution anyway because it can discourage learning advanced programming. If the team programmer creates the algorithm, on the other hand, I would have absolutely nothing against using it.

Forum search works. Or use google.

I agree, first learn how the language works, then get into the more advanced and complex part of programming.

This is known as a rerun system, and a number of teams have done it before. If I’m being entirely honest, we have found that it’s not really worth it because the time you would spending (1) tuning it, and (2) practicing your run makes it more efficient to merely just write the autonomous yourself

I dont think its a 100 percent consistent everytime either?

My team last year developed code that allows just exactly this. I’ll see if the programmer is willing to release it here.

Thanks @AppleDavidJeans hoping you could release, eager to see how it works

The mechanics of it is actually pretty simple. Just record “frames” of the controller state every 20ms or so, store them on the cortex (which is a little difficult to do with RobotC) and then simulate that control state. Doing it this way, of course, means that you have to PID everything, and get it tuned well

Ive been working on this recently, Ive been trying to get it into an array for the debug output, how would one go about using arrays?

I assuming RobotC here. Since RobotC doesn’t really have permanent data storage (grr, PROS does, however), the best way to store reruns is to merely output the saved data via the debug stream and pass that file into runs in the future using the RobotC filesystem. For example, take you might add this bit of code to your



controllerState controller; // Holds all the information in the controller, implementation is up to you ;)
void usercontrol() {
    while(true) {
        updateController(controller); // Update the controller data object

        // Robot Control Stuff
        // ...
        // ...

        if (run.recording) {
            writeDebugStreamLine( encodeController(controller) ); // Convert the struct to text in some way


Then, once the run has been completed, you’d save the file using the debug stream utility in RobotC (File > Save)

Once you have the file that measures controller state, it’s a simple matter of uploading to your cortex (Robot > Advanced Tools > File Management)


Once you have the file uploaded to your cortex, you’re gonna want to take advantage of this post by @jpearman which goes into more detail about reading files, in the context of rerun systems.

Then when you have the text file loaded into memory, you can “hydrate” the state (taking a term from web development here) and turn that text file into your instructions for each frame.

It’s important to remember that if you don’t have a control loop for everything (drive, lift, claw, etc.) this is not going to be very effective; you’ll have to be sure to correctly tune your PIDs before you record any runs! Good Luck (and congratulations on your StarStruck season)!

Really, before going down the path of inventing all this again, you should search the forum. Multiple systems already exist, and the code is freely downloadable. Click on the link I put in my previous post.

But inventing it is half the fun! :wink:

We considered using a program that took the speed of each motor each 10 milliseconds or so in the driver match and then used variables to copy it into an autonomous. Then we found out RobotC doesn’t have enough memory to do 1000 or so variables. Probably should have figured that from the start.