ok so my teacher told us that he saw somebody at a conference and they had programed the vex robot by using the remote control. meaning somebody would drive the robot and the robot would make it into a program. were trying to get the robot to travel through a selected route. kinda confusing but would be very helpful if anybody knew anything about what im talking about.
You never told us what programming language it is that you are using so I’m assuming RobotC. This program will not compile and it simply meant to be an example for what you could attempt. There is probably a much better way to do it and I’ve never actually tried it myself so I wouldn’t know. If you do try this, it probably won’t work. If it does, you’ll need to get the array out of the robot’s memory and record it somehow. Once you have that array recorded, run through it and drive until each encoder reaches the one that you have specified in the array. Each time that you press Btn5U it records a new value for each encoder and then resets them to 0 so that you can do the same thing again. If you need further explanation feel free to contact me.
task main()
{
// Create an int array to store the encoder values at each point
int leftEncoderValues[100] = {0};
int rightEncoderValues[100] = {0};
bool finished = false;
// Zero your encoders
while(finished != true)
{
for(int i = 1; i <= 100; i++)
{
while(vexRT[Btn5U != 1)
{
// Drive around
motor[left] = vexRT[Ch3];
motor[right] = vexRT[Ch2];
}
// Record the current encoder value
leftEncoderValues* = SensorValue[leftEncoder];
rightEncoderValues* = SensorValue[rightEncoder];
// Zero both encoders and go through again
SensorValue[leftEncoder] = 0;
SensorValue[rightEncoder] = 0;
}
finished = true;
}
}(Please note that this will not work out of the box and that you will have to work on it yourself, too. I wrote this in Notepad so I have no clue what about it does or doesn’t work.)**
It is theoretically possible but there are a number of problems that make it difficult. eddie12390’s approach is to record encoder values in a tight loop and then, presumably, use them in a “playback” routine. If the encoders are sampled every 50mS (the code needs a wait in the recording loop) then 20 values every second will be recorded. The code below (and I realize it’s only an example) will therefore only be able to record 5 seconds of data. RobotC puts a limitation on the amount of memory available, it’s currently 12000 bytes so the maximum size of each array would be around 2900 (2 bytes per int * 2 encoders * 2900 = 11600 ) enough for about 2.5 minutes of recording but not much memory available for anything else. If more than 2 encoders needed to be recorded then the recording time would decrease accordingly. The sampling rate could be reduced or the data could be compressed (record the delta between encoder values for example) but code complexity will increase. After recording is finished there is no simple way of permanently storing this information, there is currently no access to the flash file system which would be the preferred way of saving it.
An alternative to recording encoder data would be to record joystick data and then use this to drive the motors during playback. This approach suffers from the same problems regarding memory use and saving data as the above but is simpler to implement in terms of playback, however, it’s probably less accurate.
A further approach would be to record robot position and orientation in a piecewise manner. Drive the robot to a position and hit a button to store data. Playback would then drive to each position (perhaps in a known amount of time) before proceeding to the next. An accelerometer and gyro could be used to provide data in an absolute way rather than relying on encoder or other feedback. Even with this approach the problems of saving the data is still present but it may now be practical to send via the debug stream to be saved as text.
Perhaps later in the year I will create a tutorial showing how to implement this approach.
I have used this when teaching new members of our robotics team, and it works quite well. It takes up much less room on the microcontroller than the continuous polling method, as you can interpolate between data points without having to record every 50 ms or so.
ok sorry everybody… im using easyC V2 for VEX.
Last year we used this technique (stop motion encoder recording) to great effect. we also used a potentiometer to select the autonomous routine to be played back. we came up with a method to display the autonomous pattern and start location information on the LCD so the drivers could select knowing they were red or blue location red1 or red2 which pattern to play based upon starting location. We used the approach jpearman outlines to record encoder values at various locations. We used Easy C text print strings and log to file capability to print the ‘code’ representing each recording. This ‘code’ could be copied into the Robot program and downloaded to the robot. It worked fairly well but there appears there may have been a bug in EasyC which resulted in inaccurate encoder values. (This seems to have been remedied in the current release) we didn’t know about the problem at the time and kept wondering why the longer sequences were not repeatable.
Another challenge was coordinating all the motions to occur together. in roundup we had to move the robot (2 encoders) and the Arm (1 encoder) and Claw (1 encoder). We came up with an approach to ensure each component was complete before moving to the next step. This was challenging as the arm drive (a simple Proportional control loop) would sometime become unstable resulting in wasted time till the arm settled into the correct spot.
At the nationals competition our team would literally interview their alliance partners and if they needed a new pattern would go to the practice fields and record a new autonomous. The fields at worlds were far to crowded to allow this type of near real time updating.
It can be done but it requires a lot of work and tuning of the control loops.
You can have a lot of fun working out the method that works best for your robot. I wish you luck.
Cheers Kb
PS We chose stop motion because we were running out of time and couldn’t work out all the details to get continuous recording to work. on the robot field moving straight, stopping and turning is probably fast enough and much simpler to code. As an added bonus you can switch between driving on programmed encoders to driving based upon sensor input (Line Followers and Ultrasonic Sensors should be very important this year) Titan used that to great effect in his code (Easy C by the way) last year and it is posted on the forum. I’d like to note Easy C has the ability for you to write code in textual format and drag it into the program via user calls to subroutines. We had to define the array’s which held the encoder values in the text functions. I don’t know how to create user defined structures any other way. also the code to initialize the arrays of encoder values (for playback) which we had printed using ‘debug’ were pasted into text files using the same capability.
Oh yeah! You guys really had that system down 
When I first saw this thread I thought, you know, the Mountain Dewds had a really good system for recording and storing autonomous runs on the fly; they should write a post here. 
Sweet deal! Will you guys be using it this year again?