Have the robot read the colors, then display it on an LED strip. Of course that depends on when the plates are decided and communicated to the robot, but if it’s as the FMS changes over to the new match you should be connected in time to know before you finish placing robots on the field.
Well the javadocs were published before the game, so even us at wpilib had no idea what the game specific message would contain, just that it returns a string. The screen step page is where to actually look. The docs are generic, since it is a generic function that can be used from year to year.
The javadoc was part of the code written before kickoff, so nobody actually knew what the game specific data was. Here’s a tutorial on this year’s game specific data.
First off I am not a programmer but I am the lead mentor. Are there directions for how to determine plate color using LabView to program your robot? I just want to point my programmers in the right direction.
Is there any speculation to when the information will be sent to the drivers stations? I understand it will be prior to the match but “how prior”? Like as soon as it’s ready…or 1 second before auto starts…?
It might make programming one robot to get to either side of the scale in auto tough. That middle starting point on the end wall may be highly desirable.
https://wpilib.screenstepslive.com/s/currentCS/m/getting_started/l/826278-2018-game-data-details has some example LabView code to get you started (I’m not a LabView programmer, but I’d assume this will help. It grabs the first part of the string, aka what side the ownership for your switch is on, and then uses a switch statement to determine what to do.
Thank you guys very much!
It’s a good thing the future of our team’s season doesn’t rest on my shoulders to help with programming cause we would be lost! I have a good group of kids that will know what to do with this information. Thanks again and good luck to all this season!
Ok, major questions here that need to be answered…those directions and examples are fantastic…are they complete? ARE THEY THE ONLY CHOICES FMS HAS TO RANDOMIZE THE PLATE COLOR ORDERS, What I mean by that is…Did anyone else notice that RRR, and LLL are missing?
Have you ever tried to order materials, create, cut, or build the team elements and noticed missing measurements on the docs/plans? Made you stop and use a bit of math and mind brainpower there didn’t it? (FIRST GDC IS FAMOUS FOR THAT).
QUESTION: ARE THE FEW LIMITED EXAMPLES GIVEN in that document the end all, or are more randomized choices available to the FMS up to the total possible available choices.
I am not a student…I do not post questions in the Q & A (The only official source, when questions are posed in the correct manner of course, to receive a clarification on any rules / game issue!) I WILL SUGGEST SOMEONE POSE A FORM OF THE ABOVE QUESTION ASAP, worded correctly of course on Wednesday.
Interested curious minds are salivating over the answer here. JUST HOW MANY TOTAL PLATE COLOR RANDOMIZATIONS ARE THERE IN REALITY. Just those shown in the above linked docs, and published examples or are there more?
A reality I won’t face personally…but you certainly will. 2018 plate color randomization is an auto coders programming nightmare come to life (at least for auto programming). THIS GAME IS GOING TO BE the FRC community’s biggest challenge yet. Making a frisbee fly, launching a ball, hanging tubes, and stacking crates was easy.
There is another way, looking at the testing portion of the docs, To test, It says you must enter the game data into the box (IE: LLR)…So, is there a drop down window to make a choice from, and if so, are LLL and RRR listed choices there? OR do you (blindly), enter the data? And later maybe find out when under the gun, THAT you didn’t cover all your bases by programming every auto choice.
IF it is a dropdown window, and LLL and RRR are there, then further randomization choices are available to the FMS than are shown in the limited examples, diagrams, and info listed in the docs. IF it is not a drop down, then further clarification is still necessary. And fast.
How many so far think I’m just barking at the moon?
They just went through a few examples. I cannot believe those are all of the possiblities and I don’t think they should go through each and every possibility. The rules explicitly state “Prior to the start of AUTO the assignments of ALLIANCE colors for SWITCH and SCALE PLATES are
randomized and transmitted to the OPERATOR CONSOLE by the Field Management System (FMS).” this means that LLL and RRR are certainly possible.
I believe there are 8 possible outcomes: LLL, RRR, LLR, LRR, LRL, RLR, RLL, RRL. I don’t think you should program your auto for all 8. Honestly I think the first 2 are the only ones that matter for you and in many teams just the first letter.
The entry field on the driverstation is a simple text box. It has no limitations on it. It is not a dropdown.
I strongly disagree that this is an auto coders nightmare. In fact I think this game has some of the easiest autocoding in recent memory. The positions are given to you which is easy, I honestly expected to have to use vision to figure these things out. The relative lack of vision software being required and the giant targets (3’x4’ platform is super easy compared to a tiny spring) make this a challenge that I feel all teams should be able to accomplish.
I agree. I don’t see this as a “nightmare” as much as I see it as a regular challenge. To put it in perspective, I’m going to spend some time figuring out if the cubes are trackable with vision, so I’m not too worried about having to spend all my time on the different auton modes. The (ideal) system I have worked out in my head is a selectable chooser on the dashboard depending on which driver station we are starting on. Then a switch statement in the disabled method will choose the auton mode depending on where we start/which side switch/scale we own. If possible, multiple paths for each choice as well, depending on what our alliances will do (will have to be selected before the match). We also have to remember that, the third letter in the string will never matter in auton! That automatically eliminates creating new paths for a couple of the options.
I disagree to a certain extent. The challenges seem to be pretty easy… If you’re the only robot on the field. In both Steamworks and Stronghold, the challenges of autonomous were separate but more difficult. This year the challenge is easier, but each team is aiming for one or more of the same three objectives (cross line, switch, scale), which can make things problematic, as you won’t always be able to simply take the shortest path, and you will have to account for a number of situations based upon the skill level of your alliance members.
This would be easier in playoff matches when things are more predictable, but very hard in elimination matches in my opinion. Collaboration will be difficult, especially in qualifications, and I definitely can’t recommend promoting untested code as a form of cheesecaking your teammates.
Let us just take 8 as the answer…AND…Now add going first no delay, going second, add a delay based on a guess of how long it will take first movers robot to clear your possible intended path (or the actual time data from first leaving alliance member), and if going third the guess or actual data provided by alliance member two, to program a delay to make sure both preceeding 2 robots are clear of your newly intended path given from the FMS data provided.
Are you sure you will never use that 3rd. Dataset Value? Can you please point to the rule mentioned here by another in another or this thread mentioning anything about no crossing the field centerline, as if it is there in the 2018 rules I totally missed it on my 1 and only read through this year so far. IF it does exist, I missed it and would be highly relieved to go look it up. It reduces the auto possibillities a bit. But, it then makes you having 3 robots going for only 2 targets not 3. Reading through more than once is a wasted thing in my opinion until after Q&A opens and the first changes are made and some questions are answered, and I just have not found the time yet to do so.
If you are blue and you deposit your on robot auto cube into the red side of your own switch…figure out the missed points possible there folks, and what you need to do to make up for it, and you will wish all three of your robots ended up in a heap or never moved at all. Making up those lost points will be costly.
The real successful teams will have the bases fully covered. We just need to know exactly how many bases exist in the ballgame. My stupid bet money is on many more than 2!
And, I wasn’t speaking about the actual coding / programming, but the collaboration both on and off the field it is going to take to be a success with this newly added auto element. DATA IS FMS PROVIDED TO EACH ROBOT DRIVER STATION BEFORE THE START OF EACH MATCH, POLL IT FAST LOOP (tilde or about 20ms), or retrieve the data after auto period starts), tells me that drivers are Behind The Line when randomization takes place. YOU will know nothing except the data will be delivered, your prechosen code will make all the choices.
I fully agree that “do not promote unproven and untested code enter the field of play.”
This randomization with 1 robot is easy, two robots much harder, 3 is a nightmare scenario. Starting teleop in a heap, 1,2, or 3 robots colliding and some possibly disabled as a result at a regional, could and would be devestating.
Nothing before has ever tested Woodie’s favorite phrase as this 1 element will. Just my 2 cents, so I will stop beating a dead horse and see how it will all play out. And pray that more than many are up to the task, and it is really easier than I think.
A04 is what disallows this:
A04. Stay out of your opponent’s side of the FIELD. During AUTO, no part of a ROBOT’S BUMPERS may pass from the NULL TERRITORY to the opponent’s side of the FIELD.
Edit: As Eric points out, this doesn’t technically prohibit you from crossing the center line, but does not allow you to use the third value, which I think was the purpose of OP’s question.
Doesn’t disallow going over the centerline, though. Centerline is in the middle of the Null Territory.
$$ says there’ll be some auto hits in Null Territory this year, somewhere. (For the first time since 2010, or even 2009…)
But it does keep red from going after blue’s switch and vice versa.
I replaced elimination with qualifying, as I think the OP meant that instead. Sry, do not know how to strike text out on my pad.
Now add in practice matches…at least with Q and P matches the schedules were released hours ago, you had time to collaborate and plan ahead of time…You do so, but know in advance robot 2 has not even been preinspected, that bot won’t be onfield this match, so your plan is set with robot 3…and as you reach the front of the queing line you are now paired really late with an unknown robot from the filler line…better get really busy! OOOPS, you are now breaking that cardinal rule…Asking, no…encouraging a coding change.
Ty, A04 says it all and now I do remember reading it. STAY OUT OF THE OTHER SIDE OF THE FIELD, areas beyond the far null zone line during auto. Foul -5 points, that could easily be elevated to a Tech Foul -25 points or even further to a Yellow or Red Card.
Before reading that last part of A04 again, it almost seemed like it could be beneficial to occasionally target the opposing alliances switch under auto if you knew they would only be depositing 1 cube and you knew 2 would also be targetting your own switch, to just simply attack and attempt to balance the switch cancelling out possesion. As taking away simple ownership could cancel out many points being gained, (maybe not the original 2 points, maybe so, but.2 points per second for an extended period of time where absolutely nothing is happening and it really could not be defended against easily).
While taking the Foul loss of 5 points you could still be possibly net positive, the other much higher risks Tech Foul or any elevation to any card puts it net positive Way Out Of Bounds.
Ok, that just made the possible combinations of auto a little bit better, thank you for the A04 direction.
I’ve repeatedly read that the “color” of the plate is supplied in the game specific data, but its not. The “position” (L/R) is supplied. Easy enough.
But is there a way to know which “color” you are from the FMS? Or is this something we need the drive team to supply in smart dashboard or something to know the actual “color”?
Never mind… I found it:
C++
DriverStation::Alliance color;
color = DriverStation::GetInstance().GetAlliance();
if(color == DriverStation::Alliance::kBlue){
}
Java
DriverStation.Alliance color;
color = DriverStation.getInstance().getAlliance();
if(color == DriverStation.Alliance.kBlue){
}
The DriverStation class can provide information on what alliance color the robot is. When connected to FMS this is the alliance color communicated to the DS by the field. When not connected, the alliance color is determined by the Team Station dropdown box on the Operation tab of the DS software.
While I’m not sure why your code will care about actual colors (I suppose you could set robot LEDs to your Alliance colors), your color Alliance is indeed available from a system call.
For example, in LabVIEW it’s obtained from: Driver Station|Match & Alliance Info
Alliance returns the team alliance of the robot. Alliance can return a value of Red or Blue. If Alliance returns a value of Invalid, the robot did not receive an alliance assignment.