No announcement yet.

Field lighting cnditions

  • Filter
  • Time
  • Show
Clear All
new posts

  • Field lighting cnditions

    We had a problem on one side of one of the fields at the western super regional. The light was so bright because of the use of spotlights that is corrupted our light sensors from detecting the red Vs. blue side of the beacon. We have tired to engineer around this issue, but given the lack of a lighting specifications out efforts are just guesses. Does anybody know what the filed lighting will be for worlds? Will the finals have the same lighting as the rest of the competition? I don't see how we are to have the students plan for different conditions when there are no guidelines as to the limits that our robot might encounter.


  • #2
    We encountered a similar problem at our state competition. We addressed the issue by adding an extended black 'snoot' (examples of snoots: to reduce or eliminate side lighting from reaching the sensor, and limit the 'field of view' for the sensor. This was a successful strategy at our super-regional.

    I would imagine that your code is already based on relative values of the red and blue components, and you are not dependent upon any absolute values returned from the sensor, yes?


    • #3
      We used light sensors with red filament paper in front of them. All we did was see which one was the brightest to detect the red side. We had complete covers around the sensors that actually touch the beacons. It wasn't outside light, it was the translucent white material of the beacons picking up the lights and sending it back at our sensors.These were real stage spotlights that were used. When we got back from the tournament we found out that stage lighting has a heavy red bias to it's color. We used a halogen light to simulate the lighting and found that the sensors would end up reading the same intensity on either side of the beacon even with the red element trying to block blue light from the beacon. We've switched to using the Adafruit color sensor which can differentiate with the bright light closer by 3 times, but eventually when the beacon is blue, the blue intensity equals the red. If the beacon is red, then it will still read more red than blue as the lamp gets close to the beacons. So this leaves a way to code around this if we have to. If the levels of the blue and red outputs are high, then you know you're in bright light. If the difference between blue and red elements is small, then you are looking at the blue side of the light. This could all change if the lights are heavily blue biased like some LEDs. This is what I mean by not haveing specifications on the lighting conditions. If we're going to teach the students about lighting, we shouldn't do it by ruining their performance at a competition. There should be specifications so they can understand what those specs mean and how to deal with them upfront.