Answers.Body: <p>Perhaps you need to add some hysteresis in your sensor loops. Each loop waits for a condition to be met, but then repeats infinity as long as that condition is met. Hysteresis means waiting for another condition to indicate that the sensor has returned to the original state and usually includes a deadband (meaning the positive trigger is not the same as the negative trigger) to filter out noise.</p>
  
  <p>For example, wait for the color sensor to detect black again before repeating the loop with a deadband of 10%:</p>
  
  <p><a href="https://i.sstatic.net/Nn2gL.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Nn2gL.png" alt="enter image description here"></a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-08T16:35:27.120Z
Answers.LastActivityDate: 2020-01-08T16:35:27.120Z
Answers.UserDisplayName: David Lechner
Body: <p>I've run across something very strange with my color sensor when using multiple sensors and multiple nested loops for a sumobot. I have 4 separate loops continuously monitoring the "optical", "ultrasonic" and two touch sensors ("touch1" and "touch4"). The main program of nested loops controls the motors in response to the sensors breaking different nested loops. I have attached a simple version that I removed the motor blocks from so you can follow it easier. <a href="https://i.sstatic.net/p41Cb.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/p41Cb.jpg" alt="Simple sumo"></a> When the program starts, it defaults to the "search" loop (innermost loop in main program). The optical sensor is looking for reflected light greater than 20 (white color). The first time I put a white paper over the optical sensor, it breaks the "search" and "charge" loops and proceeds to the "color" loop, as it should. However, it only works the first time! All the other sensors work as they should, all the time. Sometimes after multiple attempts, the color sensor will work again. Mostly it doesn't. </p>
  
  <p>Here is where things get strange. If I remove <em>any</em> of the other 3 sensor loops, the optical sensor works perfectly. Another thing- If I change the color sensor in the "optical" loop from "compare reflected" to "change reflected-either direction" (keeping the value it is looking for the same), it works perfectly with all of the other sensor loops running. Also, using "change reflected- increase" or "decrease" doesn't fix it, only the "both directions" setting fixes the problem. Does anyone have an explanation of why this is happening? My only thought is that the multiple instances of the "wait for-color sensor" blocks are conflicting... but that should happen no matter how many other sensor loops I have running. It's driving me crazy helping kids troubleshoot why the optical sensor craps out. Any input greatly appreciated.</p>
  
Tags: <ev3><mindstorms><sensor-colour>
Title: EV3 color sensor strangeness
UserDisplayName: Dave Gillespie
ThreadText: # EV3 color sensor strangeness
  
  (Asked by: username_0 on 2020-01-08)
  
  I've run across something very strange with my color sensor when using multiple sensors and multiple nested loops for a sumobot. I have 4 separate loops continuously monitoring the "optical", "ultrasonic" and two touch sensors ("touch1" and "touch4"). The main program of nested loops controls the motors in response to the sensors breaking different nested loops. I have attached a simple version that I removed the motor blocks from so you can follow it easier. [![Simple sumo](https://i.sstatic.net/p41Cb.jpg)](https://i.sstatic.net/p41Cb.jpg) When the program starts, it defaults to the "search" loop (innermost loop in main program). The optical sensor is looking for reflected light greater than 20 (white color). The first time I put a white paper over the optical sensor, it breaks the "search" and "charge" loops and proceeds to the "color" loop, as it should. However, it only works the first time! All the other sensors work as they should, all the time. Sometimes after multiple attempts, the color sensor will work again. Mostly it doesn't.
  
  Here is where things get strange. If I remove *any* of the other 3 sensor loops, the optical sensor works perfectly. Another thing- If I change the color sensor in the "optical" loop from "compare reflected" to "change reflected-either direction" (keeping the value it is looking for the same), it works perfectly with all of the other sensor loops running. Also, using "change reflected- increase" or "decrease" doesn't fix it, only the "both directions" setting fixes the problem. Does anyone have an explanation of why this is happening? My only thought is that the multiple instances of the "wait for-color sensor" blocks are conflicting... but that should happen no matter how many other sensor loops I have running. It's driving me crazy helping kids troubleshoot why the optical sensor craps out. Any input greatly appreciated.
  
  **Tags:** ev3, mindstorms, sensor-colour
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-01-08. Score: 2
  
  Perhaps you need to add some hysteresis in your sensor loops. Each loop waits for a condition to be met, but then repeats infinity as long as that condition is met. Hysteresis means waiting for another condition to indicate that the sensor has returned to the original state and usually includes a deadband (meaning the positive trigger is not the same as the negative trigger) to filter out noise.
  
  For example, wait for the color sensor to detect black again before repeating the loop with a deadband of 10%:
  
  [![enter image description here](https://i.sstatic.net/Nn2gL.png)](https://i.sstatic.net/Nn2gL.png)
  
  
  ---
  
  