Is their a way to drive your robot in a certain way and then it automatically downloads to the code?

My friend told me that there’s a way to do that and it saves a bunch of time.Do you all know how to do that?

Could you elaborate?

Do you mean that you could save the way you drive and then play it back later?

I believe they mean something like replay - re-run, which is the honey grail for drivers not wanting to deal with programmers :slight_smile:

This is one thread that points to others.

Is it effective? I think bots that are truly autonomous @tabor473 is the way to go.

1 Like

find my thread on ‘autonomous toolkit’

it links to a couple of youtube videos that go over theory, implementation, and code samples for what you want

I just finished such a code, it will save motor positions to an sd card, and read them back, it is pretty accurate too

I’ve never had teams try this with a textural language, but If you code in Simulink you can log the data to an sd card and then generate code to replay it on the robot. (There are sample programs included with their VEX companion app.) The code is essentially just replaying the motor signals.

I had a couple of teams play around with this last year with varying success. The problem was that there was just too much chance of minor variations in the field (wheel slippage, object placement, etc.) for it to be consistent over a longer run. It worked well enough for short autonomous actions but the inconsistencies made longer tasks unreliable. For the full minute auton, using sensors proved more effective.

For my kids, it was an interesting diversion and they learned some from it, but they also invested too much time into it, thinking it was their holy grail of a shortcut. They ran out of time to fully develop their sensor based code. So my recommendation would be to absolutely explore it if you have time, but develop other options too.

5 Likes

Thanks for the advice, but the issue is not accuracy, it is how well our drivers drive, I can see the code being useful right before state, or even worlds however.

I’d encourage you both to check out our auto toolkit code. It addresses the issue of driver accuracy and data logging.

Drivers drive with 2 sticks (inducing minor variations/wobbles/micro turns/etc), but an auto routine does not. So, when capturing data, you have to address the driver also, not just the data logging.