Chief Delphi - 2220's Play/Record Macro for Autonomous

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - 2220's Play/Record Macro for Autonomous (http://www.chiefdelphi.com/forums/showthread.php?t=136151)

Re: 2220's Play/Record Macro for Autonomous

Has anyone done this for C++?

Re: 2220's Play/Record Macro for Autonomous

Quote:

Originally Posted by Jaci (Post 1551269)

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 :P

Re: 2220's Play/Record Macro for Autonomous

Quote:

Originally Posted by Oromus (Post 1551273)

Ahh, I was talking about the initial proposal for putting it into play/record :P. 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 :P

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.

Re: 2220's Play/Record Macro for Autonomous

Quote:

Originally Posted by AlexC (Post 1463114)

https://drive.google.com/file/d/0B-Q...ew?usp=sharing.

I requested access, can I please get this?

Re: 2220's Play/Record Macro for Autonomous

We were able to accomplish this in C++ by representing the input in a struct:

Code:



typedef struct{

        float analog[NUM_ANALOG];

        bool digital[NUM_DIGITAL];

} Gamepad;



typedef struct{

        Gamepad gamepads[2];

} Input;

Then we wrote the input struct to a file:

Code:



Input input = {0};

int file = open(filename, O_RDWR, S_IWRITE | S_IREAD);



//start of control loop (eg. TeleopPeriodic)



//do stuff with the input for that loop (get input from driver station)

input = GetInputOrSomethingSimilar();



write(file, &input, sizeof(input));



//end loop



close(file);

Now essentially we flushed the data of the input struct to the file once per loop, so the state of the input is recorded in the order it appears. To playback, we just read the file once per loop, moving the read cursor of the file by the size of the input, and gave the data to the functions that required input instead of directly from the controller:

Code:



Input input = {0};

int file = open(filename, O_RDWR, S_IWRITE | S_IREAD);



//start of control loop (eg. AutonomousPeriodic)



read(file, &input, sizeof(input));



//Give the input to whatever controls it

ControlRobotOrSomethingSimilar(&input);



//end loop



close(file);

Thats how we did it, by storing the files on the roborio, and accessing them when we needed it. But wait! You may be wondering why we would record the input of some buttons if we haven't pressed the buttons? Well the answer is simple; If your loop time is constant (which it is if you are using iterative), then the recording of inactive buttons as well as active buttons preserves the time for which those buttons are inactive or active exactly as the driver had done so the first time.

This feature has helped our team for more than just autonomous. For example: since we store the recording in a buffer (and a file), we can use it as a circular buffer, allowing us to loop over driver input while we PID tune without having to touch the controller.