Record Robot Actions

[sarah_storer]

Originally Posted by notmattlythgoe

Unfortunately, we did ours in Java using the command based code design. So what we did was started a command using the drive subsystem and each run through of the command we appended the values to the end of a file. Then to play it back we started a new command that read the top line off of that file and sent the values to the subsystem. Using that structure all of the timing was handled for us.

Personally text based code makes WAY more sense to me...I don't know a ton about LabVIEW but its what our robot is coded in:/....

[notmattlythgoe]

Originally Posted by thetimemachine

Personally text based code makes WAY more sense to me...I don't know a ton about LabVIEW but its what our robot is coded in:/....

Is there a specific reason that you guys used Labview? We switched to Java last year and have absolutely loved the Command Based system. We had used Labview before that, main reason for switching was the use in school and both the other mentor and I were better versed in it.

You can see the recording used in this video to hang on the lower bar. Our driver lines up under the bar and pushes a button and the robot drives backwards and drives forward. This was recorded on the practice field at the competition when we realized that our hanging mechanism was very sensitive to the speed that you hit the bar at. After the recording was done it was an extremely reliable mechanism.

http://www.youtube.com/watch?feature...NufVQ#t=12 1s

[sarah_storer]

Originally Posted by notmattlythgoe

Is there a specific reason that you guys used Labview? We switched to Java last year and have absolutely loved the Command Based system. We had used Labview before that, main reason for switching was the use in school and both the other mentor and I were better versed in it.

Because there is theoretically more support for LabVIEW and because its supposed to be "easier" because its visual.....I fail to see the easy part:/ But I don't think we can switch to anything else because I know more [even though its just a little] LabVIEW than Java or C++ or something like that...

[notmattlythgoe]

Originally Posted by thetimemachine

Because there is theoretically more support for LabVIEW and because its supposed to be "easier" because its visual.....I fail to see the easy part:/ But I don't think we can switch to anything else because I know more [even though its just a little] LabVIEW than Java or C++ or something like that...

Now would be the time to switch if you wanted to try a text based language. A great off season project if you wanted to learn one of the other languages is to reprogram the robot in another language. If you would like, once we finish the code rewrite I can send you all of our robot code so you can see what the code for a robot would look like.

[Greg McKaskle]

The first attached image shows one way to record all data from one joystick every 20ms until the Done button is pressed. It then optionally saves it to a file. This code would fit well into periodic tasks.

The second image shows how to read all of the data from file and play it back at the same rate.

You probably don't need all six axes of the joystick, and you may want to record more than one. If that is the case, modify the data that goes into the cluster.

If you want to record the motor values and solenoid/relay values instead, that is an easy alternative and can be output from the Drive Robot function, accumulated, and logged.

If you decide to store sensor values and add control loops to the playback, that is indeed harder, and I'd recommend instead that you put that code into Drive Robot and store the set points.

If you are worried about memory usage, you most likely don't need more than 50 elements per second for no more than 15 seconds, or 750 elements in the array. The full joystick data is 50 bytes per element. Even if you store lots more values, for 1KByte per record, you still haven't used a megabyte, so you shouldn't have any memory issues. If you want to optimize for memory, you can move the file I/O inside the loop to avoid the largish array, scale the values from doubles to smaller values, use timestamps to compress the data, or do all sorts of other fun things.

As for switching to a different language, or practicing the language your team used this year, the off season is a great time to do it. I don't know of anything in command based programming that would make this any easier. Personally, I'd encourage you to become familiar with several of the languages as they each have unique features and values.

Greg McKaskle

[notmattlythgoe]

Originally Posted by Greg McKaskle

The first attached image shows one way to record all data from one joystick every 20ms until the Done button is pressed. It then optionally saves it to a file. This code would fit well into periodic tasks.

The second image shows how to read all of the data from file and play it back at the same rate.

You probably don't need all six axes of the joystick, and you may want to record more than one. If that is the case, modify the data that goes into the cluster.

If you want to record the motor values and solenoid/relay values instead, that is an easy alternative and can be output from the Drive Robot function, accumulated, and logged.

If you decide to store sensor values and add control loops to the playback, that is indeed harder, and I'd recommend instead that you put that code into Drive Robot and store the set points.

If you are worried about memory usage, you most likely don't need more than 50 elements per second for no more than 15 seconds, or 750 elements in the array. The full joystick data is 50 bytes per element. Even if you store lots more values, for 1KByte per record, you still haven't used a megabyte, so you shouldn't have any memory issues. If you want to optimize for memory, you can move the file I/O inside the loop to avoid the largish array, scale the values from doubles to smaller values, use timestamps to compress the data, or do all sorts of other fun things.

As for switching to a different language, or practicing the language your team used this year, the off season is a great time to do it. I don't know of anything in command based programming that would make this any easier. Personally, I'd encourage you to become familiar with several of the languages as they each have unique features and values.

Greg McKaskle

I agree completely Greg. No one language is better than another, and it is a great tool to have knowledge of several different languages.

[sarah_storer]

Thank you so much for the pictures that should help a lot!

I will probably look into C++ in the off season..but this and vision processing in LabVIEW will come first... [Our team is also working on making an encyclopedia for everything in FRC so that'll take some time too...]

I'll bring this up to our coach and we'll try it out

[Greg McKaskle]

Be sure to fix my misspelling in the path.

Greg McKaskle