detecting your own alliance(C++)

[nathanww]

This is something I was wondering about the other day--is there a way for robots to determine what alliance they are on from the field control? This seems like it would be rather necessary if you wanted to hunt down opposing robots during the autonomous period.

[Daniel_LaFleur]

Originally Posted by nathanww

This is something I was wondering about the other day--is there a way for robots to determine what alliance they are on from the field control? This seems like it would be rather necessary if you wanted to hunt down opposing robots during the autonomous period.

Orientation of the target on the trailer will tell you alliance. The animation also shows different color trailers, but I didn't see that in the rules anywhere.

[rogerlsmith]

I was wondering that too, and since you asked the question, I thought I'd look. If you're using WPILib, the DriverStation class will tell you your alliance, at least it looks that way at first glance.

[paulcd2000]

Originally Posted by Daniel_LaFleur

Orientation of the target on the trailer will tell you alliance. The animation also shows different color trailers, but I didn't see that in the rules anywhere.

he's wondering whether there's a way to tell what alliance YOU are.
That's <R18> F.
I think you could put a switch on your robot which indicates alliance, and there may be something in code as well.

[dpeterson3]

The easy way is to put a switch on your bot. Program it in so that it tells what alliance you are on at startup. Example. You have a single position switch on the side of the bot. The people putting the bot in the crater set the switch for the blue alliance (switch closes the circuit on a digital I/O) the initialization code reads the state of that I/O and stores it in a variable called bool alliance (1 for blue, 0 for red). I hope this helps.

[jtdowney]

Originally Posted by nathanww

This is something I was wondering about the other day--is there a way for robots to determine what alliance they are on from the field control? This seems like it would be rather necessary if you wanted to hunt down opposing robots during the autonomous period.

This is written from memory but you should get the idea.

switch (DriverStation::GetInstance()->GetAlliance()) {
    case DriverStation::kRed:
        // red
        break;
    case DriverStation::kBlue:
        // blue
        break;
    case DriverStation::kInvalid:
    default:
        // unknown
        break;
}

[Red Mage]

Weren't the '::' used for defining a function, not calling it? Like 'DriverStation::kRed' should be 'DriverStation.kRed'.

[aaeamdar]

The double colon ("::") is a namespace operator. For example, one of the namespaces in C++ is the standard namespace, "std". So you could say,

"std::cout" etc

since cout is in the std namespace.

You could also say at the beginning of your program:

"using namespace std;"

This would allow you to implicitly refer to the std namespace.

The dot operator is different. It allows you direct (non-pointer) access to data members of a class. For example, if you had some class Apple, you might have a call such as...

"myApple.color" which could be red, yellow, greeen, etc. I don't fully understand jtdowney's code, since I am not at all familiar with the new interface, but this is the meaning of the dot operator versus double colon.

[Red Mage]

Okay, thanks. Also, how do you distinguish between the light of each alliance. I always thought they were identical. If that's true, make sure your camera is pointed forward at the beginning of the match and lock onto the first thing you see. It'll undoubtedly be an enemy robot. Then, never let it out of your sight. Autonomous is only 15s, so this should be fine.

[DanDon]

Originally Posted by Red Mage

Okay, thanks. Also, how do you distinguish between the light of each alliance. I always thought they were identical. If that's true, make sure your camera is pointed forward at the beginning of the match and lock onto the first thing you see. It'll undoubtedly be an enemy robot. Then, never let it out of your sight. Autonomous is only 15s, so this should be fine.

You would be able to tell what alliancea robot you see is on based on the orientation of the color targets at the top of the trailer. Pink over green would be red alliance, green over pink would be blue alliance.

[XXShadowXX]

Couldn't you dect the other robot by the fact you you recieve there instructions but just ignore them since they arn't coded for IP
(that should work right, or it will let you know who is on the field with you)

[jtdowney]

Originally Posted by Red Mage

Weren't the '::' used for defining a function, not calling it? Like 'DriverStation::kRed' should be 'DriverStation.kRed'.

As aaeamdar pointed out the :: is looking into the DriverStation namespace. kRed, kBlue, and kInvalid are constants in the class that are part of an enumeration.

[Red Mage]

Yeah, I initially missed that because it's not in the Reference Manual. At all. That's right folks, you can only find it in the Users Guide. Check page 78 for useful functions for autonomous. You can also check the battery voltage! That's useful...I guess...They really need to finish those manuals.

[keehun]

Originally Posted by Red Mage

They really need to finish those manuals.

They also need to make manuals that are accurate. Their FRC Control System pdf #5 on their FRC Control System page has so many errors it wasted a lot of my winter break

[daltore]

Before the match, you have what's called a "constructor" period in the SimpleRobot.cpp template which MIGHT be able to be used to run code in disabled, but my sources haven't tried it yet. If you use the BuiltinDefaultCode.cpp template (iterative template), there's a class for disabled mode. Basically, constructor is the equivalent of Initialize() or IO_Initialization() of the PIC version of WPILib, except I think it runs more than once. Using the disabled mode period, you can run code whenever the robot is disabled, the controller is just introverted; you can read inputs and run code, but you cannot run motors or set outputs until you're enabled.

That being said, that period is the perfect time to figure out where you are and what you're doing with the camera right after the cRIO boots up. With the complexity of the control system this year, there is no reason for your processor to have downtime. You can always be reading a sensor or analyzing visual data to find out where your opponents are and where your alliance members are. That way you know where those robots are already, and can track them when they dart off at the beginning of autonomous and plot a projected course for their trailers to meet very nicely with your moon rocks flying through the air But seriously, do use the camera.