The RGB value of this year's cargo

Our team wants to use a REV Color Sensor V3 to detect this year’s cargo. And what is the official RGB value of these two cargos? Can any team who has tested it share these two value?

Because of lighting, I am going to assume this is not a constant, but a range. I could be wrong about that though.

If this is true, my recommendation would be to test a few of each color and develop a range to look for.

8 Likes

If you are just using it to sort between red and blue, it should be fairly easy to set a threshold of R that differentiates between Red and Not Red and a threshold of B that differentiates between Blue and Not Blue. If you are only using the color sensor to sort balls that are already in the robot, then in theory, since you are only ever expecting to see either a red ball or a blue ball, you really only need one of those tests (i.e. any balls that are Not Red would be Blue).

If you are using it to identify the balls on the field or using it to detect whether or not you have a ball in the robot or not and therefore need to be able to also differentiate between the balls and other objects in the field of view, then you may need both tests. But unless you have a lot o other objects in the field of view that are a similar color to either the red of blue balls, the thresholds can still be pretty generous.

Nah, no bumpers or anything :roll_eyes:.

Fair point, and this needs to be considered in terms of where you place the color sensor and what objects are in the field of view. If the color sensor is inside the conveyor system of the robot and cannot see anything outside the conveyor system, the red or blue bumpers are not a factor.

If the color sensor is mounted in an over the bumper intake system, looking right down on the bumpers, then you are going to have a much harder time detecting balls vs bumpers. But if all you care about is rejecting the balls of the opposing alliance, then the job gets a bit easier. You can set up the logic so that if you are blue alliance, you detect Blue and Not Blue, and if you are on red alliance, you detect Red and Not Red. In the normal (Red or Blue, depending on alliance) state then you are either looking at your alliances ball or your own bumper in which case, you run your intake in. If it is in the “Not” state, that indicates that you are detecting the opposing alliances ball (or maybe an opposing alliances robot’s bumper), then you reverse your intake to spit out the opposing alliances ball.

If you are looking outside the robot to try to find balls, you should probably be using something other than the color sensor as there are plenty of other red and blue things out there (bumpers, tape, etc).

Yeah , we only want ti use a color sensor in the robot, and it seems that l should set the Red value to a normal red one and it can works well. For example, red is (0.561, 0.232, 0.114) and the blue is (0.143, 0.427, 0.429). Is that Okay?

Besides, when should l open the color sensor, l think getting color in period automatically is not a good method since it may misrecognize . And cause this needless trouble. So , what is the common solution of the team which has used a color sensor ?

I’ll echo what @wgorgen suggested. Don’t look for absolute/specific RGB values. Instead compare relative to red vs blue. I saw similar suggestion in another thread about RGB values for cargo. We hooked up the sensor and then added some code that would display values to Shuffleboard. We tested moving the sensor/cargo around in different ways, observing the changes in RGB and tuning our code/constants until we could reliably detect blue vs red. We used code from REV as a starting point. You can see our test code/branch here, specifically the comparison logic: https://github.com/BHSRobotix/RapidReact2022/blob/bdb4ec857afa2109cc3f2417fe96fc01a6f7044d/src/main/java/bhs/devilbotz/subsystems/Intake.java#L104

I don’t think it is a problem to get the color in a periodic method. If you are worried about detecting the wrong color, you can try to make sure to position the sensor in a place that will minimize bad readings. You can try to read a few times in a row to ensure correct color is being detected. Also use the proximity reading to detect if there is any cargo in front of the sensor at all.

The colors were different for some reason than the example for the color sensor. I just opened the color values in glass and graphed while moving around the cargo and picked an average value.

  private final Color kBlueTarget = new Color(0.16, 0.427, 0.419);
  private final Color kRedTarget = new Color(0.561, 0.114, 0.34);
  private final Color kGreenTarget = new Color(0.197, 0.22, 0.59);
  private final Color kYellowTarget = new Color(0.33, 0.113, 0.55);

This was connected to the pi pico and using then the color match.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.