![]() |
Re: Autonomy: How Did You Guys Do It?
Playback of recorded data from one of ten driver-selected .xls files stored on the cRIO. The file is selected during Disabled mode using buttons on one of the driver joysticks. The data is recorded during early practice matches to get a "gross" autonomous play accomplished, and then edited via MS Excel for any fine-tuning needed over the next few days. The recorded data includes joystick positions, button status, and pSoc switch status. It is written to a lossless queue (FIFO) at 20ms intervals (the same rate at which it arrives from the Driver Station) and eventually written to a file in one fell swoop once the driver decides to stop recording data.
For matches, the desired autonomous play is selected by the driver. Playback data from the corresponding .xls file is then loaded into several arrays (all while in Disabled mode). At the start of Autonomous, the data is "played" out from those arrays into the appropriate subsystem VIs (drive, arm, etc.) at the same rate at which is was collected. Of course, there is some variability in the response of the mechanical system from match to match but it is minimal. I guess you could call this a reasonably sophisticated open loop system. Each link in our two-jointed tube-handling arm is controlled via independent PID loops. Pre-identified angular positions of each joint are contained in a lookup table of positions (home, feeding station, floor pickup, top center, etc.) stored in a .ini file on the cRIO similarly to the autonomous play files. A state machine monitors the status of buttons on the Driver Station and loads the angular positions into the PID setpoints when a state change occurs. The same state machine runs in both Autonomous as well as Teleop since the arm control VI doesn't care if the inputs are coming from a human being or from recorded data. We had a pretty good success rate hanging ubertubes on the top peg at Pittsburgh using this system. The main problem we had was in getting our claw clear of the tube before backing away from the rack; we sometimes de-scored ourselves. There are some drawbacks to using the approach described, but as they say in math classes - the proof is left to the reader. |
Re: Autonomy: How Did You Guys Do It?
Our autonomous uses one sonar on the left and one sonar on the front. Paired with our omni directional drive, the lane divider and driver station wall allow us to know exactly where we are. We also have a gyro to keep us orientated correctly, we were hoping to use two range finders up front to orient our selves but we never got that working fully. We are hoping to get a two tube auto working Thursday at Lone Star.
|
Re: Autonomy: How Did You Guys Do It?
Our autonomous followed the line til it sensed the tee and then gunned it for the last loop of the while loop and stopped, which put us right at the wall. The "gunning" worked well except it should have been a little less energetic. Since we had holomonic drive we just controlled via strafing to keep on the line thus remaining normal to the wall. We started raising the arm to the limits at the start so that it was in position when we hit the wall. We scored 8/10 on the top middle peg in qualification runs and 100% in elimination except for one case where the arm was intentionally disabled. We could do the Y but almost all the alliances allowed us to go straight. Too bad autonomous did not offer more points.
|
Re: Autonomy: How Did You Guys Do It?
This rookie programmer wrote autonomous mode on the last day at 9 PM :)
Our arm's highest extension is at roughly the height of the highest peg, and when we release the tube we don't have to back up in order to score, which made things easier. We navigate to the scoring grid using line sensors. I didn't program for the Y because I figured 1) we should have our pick of starting positions, we can just choose the straight path and 2) it would distract us from getting the easier stuff working. Currently we are just running the elevator motor up all the time during autonomous, due to a weird problem with our limit switches in autonomous [speaking of which, would anybody like to Find the Bug that's making our limit switches work in teleop but not autonomous? :D I used C++.]. However, we recently switched our elevator motor to a more powerful one, which actually caused a belt to shear when it was run too far.....alarmed, I am now planning some careful testing and playing with the motor speed before we go out to a match and shear another belt. The idea is that if the elevator reaches the top just as we reach the scoring grid, we won't damage anything. We use the tape T to trigger scoring, which involves stopping the elevator motor and opening the gripper. We can drop the tube at just about any height and still score. All very rudimentary and I am particularly irked that the limit switches are still proving noncompliant. We didn't get very much [read: any] testing in of the whole system: at roughly 9 PM on ship night we got the line following stuff working, and then I successfully wrote and tested a switch statement to ensure that we don't just drive right over the T before it has time to stop us. So theoretically it should all work: I am anxiously looking forward to our Week 4 regional to try it all out :D |
Re: Autonomy: How Did You Guys Do It?
Quote:
and that sounds pretty awesome. im still working on getting time to work on our teams autonomous :( |
Re: Autonomy: How Did You Guys Do It?
Quote:
It's in C++...I shall update my original post. Also I posted about the limit-switch problem here. One of the best memories from this build season was running around on ship night [bag-and-tag night actually], writing code for autonomous while hardware wanted to work on the robot too, meantime our programming laptop died and we had to shuffle the robot back and forth from the shop to our high-ceiling testing area....then getting the line-following code to work. I shrieked with joy [and caffeine] and promptly laid down another duct tape line for the robot to follow....who knew that you can get cuts from duct tape? |
Re: Autonomy: How Did You Guys Do It?
Quote:
I had just seen that thread in the real time forum thing, and i immediately thought to myself "its C++ :/". I program in java, so i may not be able to find it if its a language specific problem. and for our first regional, my mom needed the laptop i use to program for a conference she went to because her mac cant make databases, so i was stuck programming on the dinky driver station computer >.< the multi purpose netbook thing. still managed to get many things working though |
Re: Autonomy: How Did You Guys Do It?
Quote:
I discovered at our scrimmage that finding a bit of fabric or other material that simulates the carpet for testing in one's pit is surprisingly hard. Also our scrimmage had very pale grey tape lines...very nice high contrast, but not really what I expect at competition. Guess who's going down on the floor with the drive team with a screwdriver on day one to calibrate the light sensors. Programming on the Classmate?! I applaud you. I don't have the patience to change default settings on that thing, lol, much less program on it...and the keys are so tiny. Try programming on a cell phone, I imagine it's about the same. We are actually planning on taking our desktop computer, my personal PC laptop, and my Macbook to regionals. The desktop is a backup in case the laptop has the fabled 64-bit incompatibility with WindRiver, and the Mac is for scouting use. We did about the same last year, and got told by some scouting team that we had the most computers they'd seen in a pit...said something about that being a scouting criteria, which makes one wonder... The original programming laptop didn't actually die....but WindRiver just...stopped compiling. It gets to 13% [on ANY program] and then just sits there indefinitely. We reinstalled and everything. It wasn't even particularly slow to begin with... |
Re: Autonomy: How Did You Guys Do It?
Quote:
we do have a small bit of carpet, but its all curled and needs weight at each end, and its only slightly larger than the robot, so its not of much use. even to sit or lie down on, its very hard to use. i usually just sit on the floor, cross legged with MY laptop that i used to program this year (an actual laptop, not DS) on my lap, right next to the chassis on a cart. and i think maybe ill suggest a mac to the scouting leader or whatever hes called, but pretty much everyone on the team is a pc. and that sucks about your original programming laptop. we have this really old laptop in our closet with no wifi, and probably about 5 MB of RAM that i was thinking of using to program one time, till i picked it up... very heavy for such a bad laptop... |
Re: Autonomy: How Did You Guys Do It?
Quote:
At one point this season I was actually writing code on my Mac...couldn't compile because of not having WPI lib stuff, but still...and I have a fond hope of someday compiling C++ for FRC on a mac, in Xcode or Code::Blocks. I tried to do that earlier this season.....after linking up most of the dozens and dozens of WPI library header files, I gave up, but I was CLOSE! Or at least I like to think so! On another note, has anyone here worked on an autonomous mode that scores more than one tube? |
Re: Autonomy: How Did You Guys Do It?
Quote:
The command functions are written in LabVIEW and perform specific tasks reliably and accurately. The primary drive functions are drive_straight and drive_gyro_turn, and both were calibrated fairly precisely (drive is accurate to about 1/2" and gyro is repeatable to about a degree, but is usually off by two degrees). There are also more command functions for elevator actions, but all of those set the getsets which are read by the elevator code elsewhere (do score, set state, etc.) The beescript system runs on top of the command functions, and reads a text file on the cRio which it interprets and calls the command functions (by ref). An example script would be: Code:
#score a tube 150 inches away 3.4 ft/sec |
Re: Autonomy: How Did You Guys Do It?
Line trackers. They work very well if you calibrate them at the beginning of each day. Once we got ours right, we scored in our last 6 matches without flaw.
|
Re: Autonomy: How Did You Guys Do It?
We use a gyro, one encoder on our drivetrain, an IR sensor on our roller claw, and a 10 turn potentiometer on our arm. All of them are used in autonomous, but only the IR sensor and the pot are used in teleop.
On the programming side of things, we've got P loops for the encoder and gyro, a PD loop for the arm, and a state machine for the roller. We push all the autonomous commands to a queue with a timeout. If the target positions for the subsystems aren't achieved within the timeout, we skip to the next command. This helps ensure that the robot doesn't get stuck in a control loop and is always doing something. |
Re: Autonomy: How Did You Guys Do It?
Quote:
|
Re: Autonomy: How Did You Guys Do It?
We're first raising our arm with two PD loops and two accelerometers (it's a two part arm) and a little bit on the wrist, then tracking the line with the rockwells, stopping at the T and then it opens the claw, lowers the arms, and runs away all at the same time.
The running away will hopefully be useful in competition, because it's been very useful scaring all the PR folks. Does anybody else find the "practice" mode very useful for the 15 second cutoff? The awesome sounds are also nice :cool: |
| All times are GMT -5. The time now is 23:41. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi