Intresting Autonomous

[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

[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).

[Alan Anderson]

Originally Posted by The Lucas

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.

It's Team 1760. They're our physical neighbor in the same county, not a numeric one.

They weren't using the DS display when I saw their system. The "fancy readout" is a very nice knob with special gearing and a mechanical attachment to the shaft. They're common in applications using ten-turn pots. Here's one such device: http://parts.digikey.com/1/parts/746...-011-1-11.html

[Elgin Clock]

If anyone gets a chance to watch the NYC Regional webcast (Saturday & Sunday), check out our auto-mode.
We're very proud of it, & it's completely intergrated into the drive system of the robot using a gyro as an assist, & is very cool in my opinion, but I'll let you all decide.
Comments welcome if you see it btw!
Thanks!

[rrossbach]

Originally Posted by The Lucas

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.

Yep, we're both describing the same behavior - in LV the framework calls the Disabled.vi one time (at least) when the "derived robot state" is "stop", and at that point the DS inputs are read as zero. This is similar to that IterativeRobot race condition in C++.

I haven't looked at the DS packets to see whether the DS is actually reporting the state to be "enabed" or "disabled" when this happens, but we plan to check into it - it's a fun way to teach the kids about comm protocols and network analysis.

[EDIT: For anyone interested, after a quick glance at the LV WPI library code, it seems clear that the DS is actually reporting the state as enabled, the framework just intentionally runs the disabled vi an extra time to allow for clean up. So not a "race condition" but something to be aware of in the framework. You'll see what I'm talking about in the "Get Competition Mode.vi" which the framework uses to figure out what mode to run]

Ron
Team 2607 - software mentor

[Rick Wagner]

It seems to me that, owing to symmetry, there are only three starting positions, so that with six autonomy choices a robot could have two options for each starting position.

[Ryan_Todd]

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).

My team has been searching for analog switches of the variety you speak of, but we haven't been able to locate anything that we were certain was what we were looking for. Could you please post a link to somewhere that we could purchase those switches? Thanks!

[Joe Ross]

Originally Posted by Skywalkar

My team has been searching for analog switches of the variety you speak of, but we haven't been able to locate anything that we were certain was what we were looking for. Could you please post a link to somewhere that we could purchase those switches? Thanks!

We've used the this potentiometer with detents before.

It's also common to take a rotary switch and solder resistors in series, between each terminal, to turn it into a rotary potentiometer.

[The Lucas]

Originally Posted by Joe Ross

We've used the this potentiometer with detents before.

It's also common to take a rotary switch and solder resistors in series, between each terminal, to turn it into a rotary potentiometer.

As Joe described, we are putting resistors (like 10K or so) in series across the terminals of a rotary switch. We have used Radioshack rotary switches before, but we now use these Electroswitch ones:
http://search.digikey.com/scripts/Dk...me=451-1027-ND

They have 12 positions but we only use 6 positions and use 2 of them (6 * 6 = 36 auto selections, we rarely need more than that ).

Joe's suggestion of a pot with 10 detents is also a good idea. They are cheaper and much easier to solder. We'll stick with the rotary switches to avoid the very minor risk of setting them in between detents.

Another interesting new feature to use for auto mode selection is the Driver Station LCD. During Disabled mode, we pint a short name for the Auto routine on the LCD screen so it can be confirmed.

[Ryan_Todd]

Thanks a ton, both of you!
Expect to see 862 at the Championship, sporting a full compliment of autonomous modes.