Play-Record Macro

[acastagna]

We are trying to implement the play-record macro described by teams 4009 and 2220 for our autonomous (thank you!) - see
http://www.chiefdelphi.com/forums/sh...ht=play+record

We have it programmed in Java using iterative robot, and it is mostly working except for two issues. When we shoot the ball, we send a shooter.set(1) command to the shooter motor, and then have a 1.5 second delay to wait for the shooter wheel to get up to speed. When we record this, the macro stops recording during the delay, and on playback the shooter wheels get a shooter.set(0) command immediately after getting the shooter.set(1). The shooter wheels are also used as a ball intake without a delay and that function works fine on playback.

The other issue is one that others have reported - accuracy isn't perfect with respect to the path driven. If we record driving in a loop and then play back from the original starting point the robot's final position is off by a few inches or more, and orientation also off.

I'm thinking of having the recording and playback modes run in a separate thread, that way it would keep recording during the delay and we can also increase the read frequency (and hopefully increase accuracy) which right now I believe is limited to by delay between driver station and robot. Has anyone tried this before? Any thoughts?

[Oromus]

1). The solution to the first problem is definitely moving the macro code to a separate Thread. The only other way is for the creators of the macro to add a wait function that both freezes the Thread and notifies the macro code of the delay.

2). The inaccuracy problem is due to how the macro works at it's core. The macro records the motor speed values and how long they were maintained. The problem is that at different battery voltages, motor speed values change. For example, on a fully charged battery, a motor running at 0.8 might go at "10 speed". On a slightly less charged battery, a motor running at 0.8 will go at "7 speed". This causes the Robot to drive different distances and turn to different angles based off it's current battery charge. This variance will be present even between two different fully charged batteries, just to a lesser extent. This problem isn't really solvable on your end; your options are wait for a change in the macro, write your own code that tracks more trust-able data (i.e. encoder and gyroscope values instead of motor speeds), or just write a normal autonomous that doesn't work off of recording teleop actions.

[acastagna]

We are using Talon SRX motor controllers and are going to try the voltage compensation mode this weekend to get around the supply voltage issue. As long as we don't try to drive the motor at a voltage greater than what's available we should be OK, and I don't think we want to run that fast anyway in autonomous. I'll report back on if that helps.

We'll also definitely put the macro stuff in a separate thread.