Chief Delphi

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)

2220Dennis 27-03-2015 14:32
2220's Play/Record Macro for Autonomous
 
Hey all-

Team 2220 implemented this at the Central Illinois Regional when Team 4009 DNA told us about a super useful tool they wrote to code autonomous programs. They had their robot programmed in Python, so we spent the night transferring the code into Java and making it work with our setup.

https://github.com/DennisMelamed/FRC-Play-Record-Macro

Here's the gist: you press a button in teleop while you're practicing that records any motions you make into a .csv file stored on the roboRio. Then during autonomous, you have it read back that file, outputting the exact same values to your motors/other things. Easy to setup, create, and change autonomous programs quickly and without a lot of planning.

Thoughts/improvements? Big thanks to Team 4009 for the idea and their code in python (you can find the link to their code in the github readme)

Fields 27-03-2015 14:48
Re: 2220's Play/Record Macro for Autonomous
 
Sounds cool.

Question:
Is it easy to go back and clean up some of the commands?

Say the driver didn't go forward enough on the first try and had to bump it a little. Is it easy to adjust for one smooth motion instead of two?

Ozuru 27-03-2015 14:54
Re: 2220's Play/Record Macro for Autonomous
 
This sounds pretty neat and would be very useful. Nice work. Have you used this in competition? How has it gone?

Poseidon5817 27-03-2015 14:58
Re: 2220's Play/Record Macro for Autonomous
 
We attempted this also, but could not get playback to work.

2220Dennis 27-03-2015 16:04
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Fields (Post 1462763)
Sounds cool.

Question:
Is it easy to go back and clean up some of the commands?

Say the driver didn't go forward enough on the first try and had to bump it a little. Is it easy to adjust for one smooth motion instead of two?
That would require accessing the csv file in the roboRio, which you can do by sshing into the roborio to the file you want. It would be kind of difficult, as the motor values are recorded multiple times a second, so there would be a whole lot of entries to sort through. It is possible though, and you could adjust them individually one by one using something like excel. The easier option would be to just re-record the auto program.

2220Dennis 27-03-2015 16:06
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Ozuru (Post 1462767)
This sounds pretty neat and would be very useful. Nice work. Have you used this in competition? How has it gone?
We have used this in competition, it works much better than trying to get the timing of all the motions down in the code :) It ended up being one of the few times our auto program did what we wanted it to.

techplex 28-03-2015 16:27
Re: 2220's Play/Record Macro for Autonomous
 
What does the BTStorage class do? Is it important? It isn't in the repository.

Ichlieberoboter 28-03-2015 17:34
Re: 2220's Play/Record Macro for Autonomous
 
Is there a version in labview?

slickvic2252 28-03-2015 19:11
Re: 2220's Play/Record Macro for Autonomous
 
Yes 2252 made a 3 tote auto using the same system in labview and was successful 11 out of 14 times

Jacob Bendicksen 28-03-2015 19:21
Re: 2220's Play/Record Macro for Autonomous
 
That's amazing!

Funny coincidence, too - the FLL team that I coached last year built pretty much exactly this, but it ran on an EV3 that was controlled via Bluetooth by another EV3. They ended up winning the Software Award at the Oregon State Championship, and you guys deserve to win something for this - it's a great piece of work.

orangemoore 28-03-2015 19:54
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by slickvic2252 (Post 1463074)
Yes 2252 made a 3 tote auto using the same system in labview and was successful 11 out of 14 times
Is it possible to get that program?

2220Dennis 28-03-2015 20:10
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Techwiz (Post 1463023)
What does the BTStorage class do? Is it important? It isn't in the repository.
A BTStorage object has a bunch of motor constant values, port numbers, etc. We need access to it in our play/record classes because we are setting values to motors. If your code is set up differently, you won't need to pass it in.

2220Dennis 28-03-2015 20:26
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Jacob Bendicksen (Post 1463077)
That's amazing!

Funny coincidence, too - the FLL team that I coached last year built pretty much exactly this, but it ran on an EV3 that was controlled via Bluetooth by another EV3. They ended up winning the Software Award at the Oregon State Championship, and you guys deserve to win something for this - it's a great piece of work.
Thanks! Team 4009 DNA really deserves the credit, those guys wrote some really awesome code.

Sperkowsky 28-03-2015 20:32
Going to talk to our lead programmer about this. Being programming is our strong suit and next year we are losing him we need to explore different things before we lose him.

AlexC 28-03-2015 21:24
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by orangemoore (Post 1463082)
Is it possible to get that program?
Yes it is. Here is the latest version of our 2015 code along with our 3 tote auto file. The file type that windows assigns the auto recording seems to be rather random but just open the file with a excel or an equivalent program with tab seperation and it should open fine.

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


Using recording and open office to edit the file we were able to develop our 3 tote auto in just a little over two hours.

virtuald 28-03-2015 21:35
Re: 2220's Play/Record Macro for Autonomous
 
Cool stuff, glad to hear a python team did it first.. :D

In 2003, the first year that FIRST had autonomous modes, I was a senior in high school and I implemented this exact same type of thing that year in PBASIC. Only had 22k of flash memory to write to though... but it worked like a champ!

auxchar 12-04-2015 04:26
Re: 2220's Play/Record Macro for Autonomous
 
Hey, take this to worlds with ya, ok? :D

2220Dennis 21-04-2015 18:43
Re: 2220's Play/Record Macro for Autonomous
 
Just an update for those still interested in this- after some debugging, the entire setup should be much more stable now, hope that the changes will help.

Cyborg Mustang 21-04-2015 22:08
Thank you and Team DNA for this awesomeness. Do you mind if i work on making a universal version of this?

jtrv 11-05-2015 08:14
Re: 2220's Play/Record Macro for Autonomous
 
One of the most clever things I've seen yet. Nice work.

doctorflems 05-02-2016 22:46
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by AlexC (Post 1463114)
Could you take some screenshots of the block diagrams and describe how you did this?
In most cases, I am terrible at writing an autonomous sequence, but it is in this case that I believe I can get a firm grasp of the concept.

jojoguy10 04-03-2016 09:54
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by doctorflems (Post 1535798)
Could you take some screenshots of the block diagrams and describe how you did this?
In most cases, I am terrible at writing an autonomous sequence, but it is in this case that I believe I can get a firm grasp of the concept.
I'm also interested in this program as well. I requested access to view the Drive folder.

Jaci 04-03-2016 10:00
Re: 2220's Play/Record Macro for Autonomous
 
I wrote something like this a while ago, and I've got a little bit of advice.

During a competition, any periodic functions aren't exactly constant. Their timing may change, especially on a field, as it waits for data from the Driver Station. To remedy this, use something like a 'heartbeat' thread, that triggers on a constant rate, all the time (for us, we use 50hz). This means you don't get the next data point at an inconsistent rate, which causes jerking in driving and/or any other mechanisms.

Other than that, it looks good :). Good luck in Autonomous!

acastagna 04-03-2016 10:09
Re: 2220's Play/Record Macro for Autonomous
 
Jaci - Did you just use a timer in your thread to pace the reads and writes, or some other triggering mechanism? Thanks!

Jaci 04-03-2016 10:11
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by acastagna (Post 1551228)
Jaci - Did you just use a timer in your thread to pace the reads and writes, or some other triggering mechanism? Thanks!
We use a heartbeat it times the 'error' in time between the last trigger and the conclusion of the heartbeat. (i.e. if your code takes 25ms and your heartbeat is 100ms, it will wait 75ms). We're using Thread.sleep since the Java library is still using Thread.sleep instead of an actual hardware timer

EDIT: Whoops, i misunderstood. We do reads and writes as we go along. Since the RIO non-volatile storage is flash, we've tested that just reading from a BufferedReader is fast enough to not cause hickups

acastagna 04-03-2016 10:34
Re: 2220's Play/Record Macro for Autonomous
 
Thank you!

Oromus 04-03-2016 10:46
Re: 2220's Play/Record Macro for Autonomous
 
We did this last year, but wound up not using it due to inconsistency of the motor values due to battery charge. Since a motor running at a speed of, lets say, 0.8 runs at different speeds depending on the charge of the battery. This causes the autonomous, depending on the battery charge, to look right, but wind up not driving/turning the correct distance. How did you guys tackle this problem? Do you incorporate encoders and/or a gyroscope?

Jaci 04-03-2016 10:50
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Oromus (Post 1551255)
We did this last year, but wound up not using it due to inconsistency of the motor values due to battery charge. Since a motor running at a speed of, lets say, 0.8 runs at different speeds depending on the charge of the battery. This causes the autonomous, depending on the battery charge, to look right, but wind up not driving/turning the correct distance. How did you guys tackle this problem? Do you incorporate encoders and/or a gyroscope?
For my team, we're using a different tactic of Motion Profiling to overcome this. It's not really play/record, but it's certainly worth it, especially with the inconsistency this year of where you'll end up after crossing a defense. Just my $0.02

Oromus 04-03-2016 10:53
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Jaci (Post 1551258)
For my team, we're using a different tactic of Motion Profiling to overcome this. It's not really play/record, but it's certainly worth it, especially with the inconsistency this year of where you'll end up after crossing a defense. Just my $0.02
Oh yeah, we're something similar this year (sensor data PIDs with an autonomous mapping/design program). I'm just curious to see if the play/record macro did something to fix the inaccuracy of using motor speed values, since it would wind up being quite annoying to deal with for the teams using it.

Jaci 04-03-2016 11:10
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Oromus (Post 1551259)
Oh yeah, we're something similar this year (sensor data PIDs with an autonomous mapping/design program). I'm just curious to see if the play/record macro did something to fix the inaccuracy of using motor speed values, since it would wind up being quite annoying to deal with for the teams using it.
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.

414cnewq 04-03-2016 11:10
Re: 2220's Play/Record Macro for Autonomous
 
Has anyone done this for C++?

Oromus 04-03-2016 11:14
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

Jaci 04-03-2016 11:20
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by Oromus (Post 1551273)
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
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.

3072Cap 06-03-2016 09:06
Re: 2220's Play/Record Macro for Autonomous
 
Quote:
Originally Posted by AlexC (Post 1463114)
I requested access, can I please get this?

Hsifeulbhsifder 07-03-2016 18:35
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.


All times are GMT -5. The time now is 01:36.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi