Anyway to record driver run for autonomous

  1. 7 months ago

    Juster

    12 Nov 2017 Edmonton Alberta
    Edited 7 months ago by Juster

    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

    @Barin 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.

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

  2. Barin

    13 Nov 2017 Arizona

    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.

  3. kypyro

    13 Nov 2017 V5 Beta Tester Central Kentucky

    Forum search works. Or use google.

    https://www.vexforum.com/index.php/26908-rerun-mk1/p1#p218659

  4. 1961Uranium

    13 Nov 2017 Answer Georgia, United States Blitz Alliance 1961U

    @Barin 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.

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

  5. MayorMonty

    13 Nov 2017 Greenville, SC 3796B

    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

  6. 1961Uranium

    13 Nov 2017 Georgia, United States Blitz Alliance 1961U

    @MayorMonty 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?

  7. AppleDavidJeans

    13 Nov 2017 Collierville, Tennessee 3631A (Retired)

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

  8. Juster

    14 Nov 2017 Edmonton Alberta

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

  9. MayorMonty

    14 Nov 2017 Greenville, SC 3796B

    @Juster ; 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

  10. 9065_Parker

    14 Nov 2017 Platte City Missouri 9065C

    @MayorMonty 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?

  11. MayorMonty

    14 Nov 2017 Greenville, SC 3796B

    @Parker Ive been working on this recently, I've 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 usercontrol() function:

    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
            }
    
            wait1Msec(20);
        }
    }

    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)!

  12. kypyro

    14 Nov 2017 V5 Beta Tester Central Kentucky

    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.

  13. MayorMonty

    14 Nov 2017 Greenville, SC 3796B

    @kypyro 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! ;)

  14. briancole

    14 Nov 2017 Utah 4270C

    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.

 

or Sign Up to reply!