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!

Re: 2220's Play/Record Macro for Autonomous
 

Hey, take this to worlds with ya, ok? :D

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.

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

Re: 2220's Play/Record Macro for Autonomous
 

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

Re: 2220's Play/Record Macro for Autonomous
 

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.

Re: 2220's Play/Record Macro for Autonomous
 

I'm also interested in this program as well. I requested access to view the Drive folder.

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!

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!

Re: 2220's Play/Record Macro for Autonomous
 

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

Re: 2220's Play/Record Macro for Autonomous
 

Thank you!

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?

Re: 2220's Play/Record Macro for Autonomous
 

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

Re: 2220's Play/Record Macro for Autonomous
 

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.

Re: 2220's Play/Record Macro for Autonomous
 

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.