Quote:
Originally Posted by markmcgary
I think this is a great idea. It's so good, it's been done. There have been a couple of additional attempts to use this method in the past as well. I searched threads for 'autonomous record playback'. |
Figured I should chime in, as one of the writers of that code.
It worked by writing the joystick axes and buttons to a file on the CRIO 10 ms increments (it doesn't actually write every 10 ms, it stores the values in an array until the recording finishes and then performs the write). The values are then played back one by one at the same 10 ms intervals.
We never used it in competition, nor did we expect this version to be good enough for competition. There are too many unknown factors (battery, mechanical wear, etc.) for open loop control to meet our expectations. But it did perform fairly well: our robot could consistently drive ~10 feet and end up within a foot of the destination. This is "good enough" for some applications.
Some teams only use open loop control in auto. Sensors are often expensive or tricky to implement, and a 90-100% consistent auto just isn't a big enough priority for these teams to use them. For these teams, a playback auto should be just as good as their normal autonomous, and may be easier to implement. It also may give them more options than they would have had previously.
The further step we wanted to make was to implement closed-loop playback. The setpoint would be inferred from the sensor values during recording (maybe the gains for the control loop could also be inferred from the joystick values). This would hopefully give the reliability of a hand-tuned closed-loop autonomous, but allow the quick implementation of new auto modes.
Unfortunately, our documentation and instructions for the existing code is quite poor. This is a large impediment to its use, as the "target audience" is teams that struggle to implement autonomous at all, or who only do the bare minimum. If we do further work, I would want to rewrite the code using the Motor Get Values vi instead of requiring the user to manually wire the values into a vi. This would hopefully allow the creation of two standalone vi's: one that gets placed in timed tasks and just runs and records on demand, and the other that gets placed in auto. Maybe with this rewrite and better documentation it would be more accessible to teams.
TL;DR We targetted this towards teams that otherwise couldn't do auto, and we need to improve documentation/ease of use to make it helpful.