Recordable Autonomous

How would one go about coding a recordable autonomous where one could press a button to record, drive, and then press another button to play back autonomous? What type of PID is necessary for this? Are there any sample programs/tutorials to base it off of?

Any help would be greatly appreciated!
Thanks!

If you do a google search for “vex forum record” you will find a number of posts, with code, to do this.

here is probably the best one, https://vexforum.com/t/answered-what-rules-are-in-place-to-protect-robots-that-are-hanging/18114/1

here is how you do it you don’t

True, I would prefer to do it by hand, but there could be a slight place for a simple auton for something like the beginning of a season when you haven’t had a lot of time to build and write an auton.

That’s called a sabotage autonomous, it’s literally just a wait command for your drive that you aim at your opponents. And it’s more fun than pretty much any other auton in existence.

nah it would have complexity, just not refinement, plus in a game like starstruck there wasn’t much sabotage you could do.

so it would be useful so something like that, it just wouldnt have consistency.

Thanks guys! I’ll try to see if I can get this working. While this isn’t my top priority, it would be nice to be able to program a (semi-accurate at least) last-minute auton at a competition, maybe as a way to defend against some opponent’s autonomous…

I’m sad that RECF/VEX allow this. IMO, it goes against the ethos of the game as teams don’t learn or know how to program.

Yeah but like @Gold_Rush said, in a pinch this could be seriously useful.

I get it, but you could also actually code your auton - have multiple for many different situations.

Because teams can, they use this in lieu of doing the actual programming.

I agree that defeats the purpose.

It would be useful for teams where things aren’t quite working right, like if your motors aren’t equally as strong, then you could record a driver manually adjusting for that discrepancy to fix the issue, as fixing those kinds of issues purely in programming as a pain.

In order to use a recording program, a team has to do programming at some level. In the version I posted they follow a script that generates time-based code and paste it in their competition template. For a team that has never seen autonomous code, this is likely a revelation about how it looks. I hope it would be an inspiration to figure out ways to improve on the recording by editing that time-based code.

If you have gone to even one vex competition, you know that many teams never write an autonomous program because they have no clue where to start. Having recording code out in the world is one way to break down that barrier.

This may be true is some circumstances, but is not true in others.

I mentor ~20 HS teams. One of our teams did do a decent amount of work in order to get it to work. However, then it was just shared amongst the other teams. When I found out, I put a stop to it and they aren’t allowed to use it. It may (or may not) put our teams at a disadvantage in competition, but I don’t want this just being passed down every year and kids not learn how to program.

I know other organizations that use it. When one of our teams was paired with them for the elimination rounds, our team asked them to change their auton because the two autons would collide. The team said that they couldn’t because they would have to drive another and record it … fully admitted that they don’t know how to program. Our team asked them just to put something simple to drive forward … they said they didn’t know how to do that.

You can argue for or against it, but I’d feel confident that the intent of the skills or competition autonomous isn’t to have teams record driving and replay it.

Completely disagree with this. IF, big IF, huge IF, you did the programming to get it to work, that is harder than writing a simple autonomous.

On a related topic, I like this years game … however, I do think the GDC committee messed up in one aspect with regards to auton. There was no simple auton like in other years. If they would have included the park in the 15 sec auton, it would have solved that. This was only a factor in early tournaments, but, if they had done that, teams wouldn’t have been able to afford not to do some programming (drive forward/stop). That is how you would encourage programming.

@action000 tell me how you really feel

Always will. :wink:

Lol

Thanks for the feedback @action000 . I do feel more conflicted knowing it became the only method of programming in your group, and am glad you put a halt to that. Fun fact is my own teams do not use any auton recording - not because I have prohibited, but because they have no clue they exist.

I fully agree parking should have counted. Last year I observed several teams have a light turn on when they saw all they had to do was drive forward a bit to score… Much peer teaching of that simple auton. Thing is, I don’t know how many took it any further than that.