2220's Play/Record Macro for Autonomous

[slickvic2252]

Yes 2252 made a 3 tote auto using the same system in labview and was successful 11 out of 14 times

[Jacob Bendicksen]

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.

[2220Dennis]

Originally Posted by Jacob Bendicksen

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.

[orangemoore]

Originally Posted by slickvic2252

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?

[AlexC]

Originally Posted by orangemoore

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]

Cool stuff, glad to hear a python team did it first..

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!

[jtrv]

One of the most clever things I've seen yet. Nice work.

[doctorflems]

Originally Posted by AlexC

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

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]

Originally Posted by doctorflems

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]

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]

Jaci - Did you just use a timer in your thread to pace the reads and writes, or some other triggering mechanism? Thanks!

[Jaci]

Originally Posted by acastagna

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]

Thank you!

[Oromus]

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]

Originally Posted by Oromus

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