2220's Play/Record Macro for Autonomous

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

[auxchar]

Hey, take this to worlds with ya, ok?

[2220Dennis]

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]

Thank you and Team DNA for this awesomeness. Do you mind if i work on making a universal version of this?

[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

[Oromus]

Originally Posted by Jaci

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]

Originally Posted by Oromus

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.