Autonomous and Randomizing

[EricH]

@Dan Waxman

A04 is what disallows this:

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.

[cglrcng]

@Dan Waxman

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 of the same three objectives, 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) qualifying matches in my opinion.

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.

[cglrcng]

@EricH

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.

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.

[brk]

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.

[Mark_McLeod]

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.

[dawonn]

I guess I’ll toss my 2cents into the hat… No bad game data so far. /knock on wood

My teams (Java & CPP) are polling the game data in robotPeriodic() so that if the data is late or changes after the start of the match, the robot will use the latest. I also force upper case, just for safety. I also write the value out to the dashboard, so if something goes wrong, the drive team can look at the value. (Although, I’m not sure they are aware of it’s presence…)

We don’t start along a path until a valid string is received, so we are vulnerable to not receiving a string (We probably should time-out and run a line program).

JAVA:

gameData = DriverStation.getInstance().getGameSpecificMessage().toUpperCase();
SmartDashboard.putString("Game Data", gameData);

CPP:

autoGameData = frc::DriverStation::GetInstance().GetGameSpecificMessage();
std::transform(autoGameData.begin(), autoGameData.end(), autoGameData.begin(), ::toupper);
SmartDashboard::PutString("Game Data", autoGameData);

AutoPeriodic():

if (autoStartPosition == sAutoCenter) {
	if (autoTarget == sAutoSwitch) {
		if (autoGameData[0] == 'L')
			autoCenterFast(false);
		if (autoGameData[0] == 'R')
			autoCenterFast(true);
	}
}