View Single Post
  #6   Spotlight this post!  
Unread 07-05-2013, 16:45
Jon Stratis's Avatar
Jon Stratis Jon Stratis is online now
Electrical/Programming Mentor
FRC #2177 (The Robettes)
Team Role: Mentor
 
Join Date: Feb 2007
Rookie Year: 2006
Location: Minnesota
Posts: 3,747
Jon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond repute
Re: Record Robot Actions

How you do it might be dependent on exactly what you hope to accomplish with it. Are you trying to duplicate your robot's movements in a previous match? Are you trying to capture certain movements in order to program an autonomous mode?

There are really three types of information that can be captured: driver input, motor/pneumatic output, and sensor input. I'll deal with each one separately.

Driver input: This can be thought through the easiest: Capture the axis values and button pushes, with timestamped values. Play those back in as input instead of actually driving the robot. This is also possibly the least informative type of recording you can do - it's highly dependent on the conditions on the field (starting position, where other robots push you, how your robot might slip or tilt when driving over a Frisbee).

Motor/pneumatic output: Where as with Drive Input you're feeding the input through the code to determine the output, here you directly capture the output. It's a little less intuitive than dealing with Driver Input, as you essentially have to ignore what the code says and provide the output directly.

Sensor input: This is perhaps the most precise, but is more difficult to get right - you're relying on sensors connected to the motors and moving parts to tell you when those items run and how far they go. This lets you precisely mimic motions.

We did this for our climbing routine this year. We had the potentiometer values from the associated axis being spit out to the console, and then we manually moved the robot through its motions. This allowed us to capture exactly how we wanted it to move, and based on that data create waypoints (critical positions the mechanism needed to hit in its motion) for the motors to move through in our PID loop, essentially recreating the manual motions we made. (go to position A, then B, then C... the exact motion from A to B may not have been identical to the manual motion, but the final positions were)

This same process could be used with an autonomous mode pretty easily. start the robot, then manually move it through what you want it to do (roll it forward to pick up disks, or turn and follow the center line, for example), capturing output from the encoders on the console. Then you know that to get to a specific waypoint in the process, you need to hit X number of encoder counts on each side of the drive train.

For capturing and playing back an entire match... I would question the use. Another robot bumping into you will completely throw off the data you gathered, and make it nearly impossible to reproduce.
__________________
2007 - Present: Mentor, 2177 The Robettes
LRI: North Star 2012-2016; Lake Superior 2013-2014; MN State Tournament 2013-2014, 2016; Galileo 2016; Iowa 2017
2015: North Star Regional Volunteer of the Year
2016: Lake Superior WFFA
Reply With Quote