Intresting Autonomous

[lynca]

Please post a link to a video you if you find an Interesting Autonomous

My favorite autonomous as of now is the 121/175 alliance pinning of their opponent.

http://www.thebluealliance.net/tbatv...?matchid=11858

Does anyone see any strategy problems with the 121/175 autonomous ?

I think most of 121's autonomous modes were excellent

[scoutmasterlord]

http://s255.photobucket.com/albums/h...City%20Videos/


this is alot of team #201 matches.

[nahstobor]

Originally Posted by bduddy

What do you mean "chose not to"? Why?

At the New Jersey regional we chose not to score during Autonomous for many reasons. First off we felt that because our Autonomous mode was not fully ready for scoring it was not worth the risk. We attempted scoring earlier but was only able to score 4 balls. Those first 7 moon rocks are very important so we choose only to line up with a trailer so when we started teleoperted we were ready to go. This gave us a greater chance of scoring those first 7. Now at the NASA/VCU Regional we will go back to trying to score in Autonomous because I think in Atlanta this will be a very important ability.

Here are some good videos of our robot tracking during the playoffs (all this video was provided from our "bot cam" that was mounted next to the actual camera)

(Quarterfinal Match 1, locked on team 136)

(Semifinal Match 1, locked on team 708)

(Semifinal Match 2, locked on team 708)

(Semifinal Match 3, locked on team 1218) (My favorite)

[Enigma's puzzle]

that bot cam is awesome, i didnt know we were allowed to do that

[nahstobor]

Originally Posted by Enigma's puzzle

that bot cam is awesome, i didnt know we were allowed to do that

From my understanding in order to do so you must have permission from the Lead Inspector at the event, which at the New Jersey regional we did.

[FRC4ME]

Our autonomous runs to our alliance's refueling station and hides. It is very difficult for human player to score on a robot that is over there.

We decided not to go forward and spin since that's what everyone else does, giving us a 50% chance of being pinned to the wall rather than getting to center.

[DtD]

That's basically what ours did.
It went forward for a few seconds then spun around. It also calibrated our ball dumper (which is kinda cool to watch btw, I might upload a video when our bot gets back.)

~DtD

[Hazmatt]

Originally Posted by GGCO

My team, 904, went with the track the trailer and score in it method. It works pretty well. It's still a little buggy, but we can fix that easily.

I did notice at Traverse City team 2645 also was tracking and shooting. I was wondering if one of their programmers could fill the rest of us in on what their secret was?!? From what I could tell the robot drove towards the target, found it, backed up when the image percent was too large, and then lobbed a cell into the trailer. Pretty impressive.

Anyone use an ultrasonic sensor for their auto mode?

We built our code from the "2 color servo tracking demo". Basically we looked at the part in the code that spit out the servo angles for the x-axis servo on the gimbal. These were an angle value and so consequently ranged from 0-170. We called angles 0-85 (85 = 170 / 2) "left turn". We made a function that linearly increased power to the drive wheels as the angle got closer to 0. angles 85-170 were considered "right turn" and were scaled the same way. additionally, we told the robot not to move if the camera wasn't currently tracking a target. After all of this, our robot would turn but not drive towards a target. Next we found the part in the code that spit out the "area %" of the target on the screen. We created a function that would add an amount to the drive speed of both motors (so that the motors would drive forward) that increased linearly based on the distance (area %) that the camera saw. Additionally, we added a switch on our robot to switch between the colors that the camera is currently tracking (green/pink or pink/green).

If you do this type of programming in Labview, I suggest that every time you make a multiplier in a function you first make a knob on the front panel so that you can "tweak" the outcome of the function. Then when you are done go to the block diagram, right click on the knob or dial and select "change to constant". Doing this will ensure that the numbers you have chosen in your functions always stay the same. If you leave them as a dial they will reset themselves.

We are currently working on getting the robot to move out on to the field 3 seconds initially, and then start tracking. Ideally we would have had a "field position switch" which would allow us 3 different autonomous modes, but unfortunately a firmware update disabled this ability for us. Also unfortunate was that we already had the control panel made with the switch mounted.

I wrote a ton, but I hope that lets you in on the "secret"

[Greg McKaskle]

and select "change to constant". Doing this will ensure that the numbers you have chosen in your functions always stay the same. If you leave them as a dial they will reset themselves.

This works fine. You can also right click on the knob or other control and go to Data Operations >> Make Current Value Default. That way they are there to tweak in the future if conditions change.

Greg McKaskle

[Vikesrock]

Originally Posted by Hazmatt

Ideally we would have had a "field position switch" which would allow us 3 different autonomous modes, but unfortunately a firmware update disabled this ability for us. Also unfortunate was that we already had the control panel made with the switch mounted.

Switches on the DS side can still be read and used to select Autonomous modes. The difference is that they now cannot be read in Autonomous/Enabled mode. Read them in Autonomous/Disabled and cache the values for use during Autonomous/Enabled. Also, there are reports that the values return incorrectly from the last cycle of Autonomous Disables, so make sure your code has a way of dealing with this.

[rrossbach]

Originally Posted by Vikesrock

Switches on the DS side can still be read and used to select Autonomous modes. The difference is that they now cannot be read in Autonomous/Enabled mode. Read them in Autonomous/Disabled and cache the values for use during Autonomous/Enabled. Also, there are reports that the values return incorrectly from the last cycle of Autonomous Disables, so make sure your code has a way of dealing with this.

Our team did some experimenting and found that at least in LabView, the last time Auto Disabled runs the DS input values are in fact zeroed out just like they are if you try to read them during Auto Enabled. I assume the C++ handling is similar but we have not checked that.

It's hard to handle this in the LabView Basic Framework, but is pretty straightforward in the Advanced Framework - attached is an example Disabled.vi for the advanced framework that shows this, hope it's useful! The AutonMode.vi also attached is just a simple "functional global" variable. Autonomous Independent just reads the cached value.

Ron
Team 2607 - software mentor

[IceStorm]

Originally Posted by TVan

we did not make this autonomous up and were scored on in autonomus,
and we were on the winning alliance. Selected by 2645 (a Great Team, thank you ) and played with 247 (The Bears rock )

The most intresting or gut wrenching was our robot taking off at a slow speed than insted of one side forward and one backward both forward full speed into the driver station on the other side of the field. who ever thought up the bumpers on the driver station wall thank you. ( did you flash it )

Tim

Team BOB! You guys have an awesome robot. It was a blast to have been picked to play in the quarter finals with you and look forward to seeing you again over at West Michigan.

[The Lucas]

Originally Posted by rrossbach

Our team did some experimenting and found that at least in LabView, the last time Auto Disabled runs the DS input values are in fact zeroed out just like they are if you try to read them during Auto Enabled. I assume the C++ handling is similar but we have not checked that.

It's hard to handle this in the LabView Basic Framework, but is pretty straightforward in the Advanced Framework - attached is an example Disabled.vi for the advanced framework that shows this, hope it's useful! The AutonMode.vi also attached is just a simple "functional global" variable. Autonomous Independent just reads the cached value.

Ron
Team 2607 - software mentor

The values should never be zeroed if the DS is in Auto Disabled state even if it is the last run (how would the DS know that anyway?). I dont have LV installed on this computer and I haven't studied the advanced framework or your code (I stopped programing in LV before the advanced framework, but I do understand LV, especially dataflow programming). However what I think is happening there (based on what I am hearing) is the Auto Disable LV state runs once while the DS is in Auto Enable (reason for the zeroing) before transitioning to Auto Enable.

In either LV or C++ if you call IsDisabled() or its LabView equivalent before testing your Auto Selection switches you should be fine.

My team has used two 6-position rotary switches to select our auto routines for the past few years. They give us 36 slots (usually enough even for our team) using only 2 analog ins as opposed to 5+ digital ins (usually need those for other controls).

[Back on topic] Dawgma (1712) camera tracked and scored 4 times (hitting all 7 balls 3 times) in auto. Even when they didn't score in auto they often scored immediately afterward[/Back on topic]

[Alan Anderson]

Originally Posted by The Lucas

My team has used two 6-position rotary switches to select our auto routines for the past few years. They give us 36 slots (usually enough even for our team) using only 2 analog ins as opposed to 5+ digital ins (usually need those for other controls).

One of our neighbor teams is using a ten-turn pot with a fancy readout on their Driver Station as a mode selector. I think their code is able to distinguish 100 different settings.

[The Lucas]

Originally Posted by Alan Anderson

One of our neighbor teams is using a ten-turn pot with a fancy readout on their Driver Station as a mode selector. I think their code is able to distinguish 100 different settings.

Cool idea, was that 007 or 53? I've only started to play with the DS display. I dont think I would ever switch to a scheme that required feedback from the cRIO. I am comfortable with being able to yell at the comp team in the queue "Run C-3!" and they can dial that in immediately w/o turning on the robot. However, maybe I will use this great idea to print out what the auto routine does on the DS so they can confirm (w/o looking at their cards). Also if I need more auto selections I can always put more resistors on the rotary switches (they can expand to 8 or 10 different positions), 6 was just chosen because there are 6 starting positions (lucky we didnt need to use it give red vs blue target to the camera else we would be out by now).