No announcement yet.

Color sensor unexpectedly switching off

  • Filter
  • Time
  • Show
Clear All
new posts

  • Color sensor unexpectedly switching off

    Hi all,

    Some two months ago, the team I coach "suddenly" noticed that sometimes, right in the middle of a run, a color sensor can turn off for 1 or 2 seconds and then resume its normal "red" light reflected intensity behavior. I have witnessed it myself quite a few times.

    It can happen on either sensor, not necessarily the one they are currently "using" to follow a line. Or even in a moment when no one is caring about the color sensor, just driving from point A to point B waiting for a touch sensor event.

    I tried replacing cables and color sensors, same result. We had a faulty brick (the middle button would not work) and had to change the brick also, same result.

    They ONLY use reflected light intensity, never another mode.

    In collective memory, this started happening:
    - either when they decided to use two color sensors (one on each side of the bot)
    - when I upgraded the firmware to 1.09E as the IDE was proposing it.

    Since both these events occurred around the same time, no one remembers for sure.

    It could of course be a combination of both.

    Has anyone wirnessed this sort of thing ?

    Last edited by jgallet; 04-27-2017, 11:34 AM. Reason: edit: word "replacing" cables and sensors instead of "switching"

  • #2
    My guess is programming. Just because you aren't using the sensor doesn't mean you aren't using the port, and in EV3 it is all about the port. Look through all your my blocks to see if anyone uses that port for some other purpose.

    I've seen a lot of really weird behavior, and almost every time the weird behavior has been programmed in.
    Last edited by Dean Hystad; 06-02-2017, 08:25 AM.


    • #3
      Thanks Dean for your answer. I am perfectly happy with a coding error, these are the easiest to solve (compared to a hardware problem)
      I actually witnessed one shutting down yesterday. It happened in their single MyBlock wich is short enough that I can publish it here. I can not see any port juggling, but maybe other people will. Already late here, I shall to that tomorrow (the team's computer has no network connection, need to do some transfers here).


      • #4
        Did you figure out what was going on with your sensors? My team has the same problem and it seems to be very random, not happening at the same point In Their programming ever, just suddenly blinking out. Would love some ideas on how to work with this.


        • #5
          Also seen this happen with our robot. We use the light sensor in a loop, which has the condition for waiting reflection value smaller than a certain value.


          • #6
            Strangely enough, we had the same issue for the first time a couple of days ago. I thought it was due to the cable going into the sensor at a weird angle causing a bad/loose contact, but I haven't taken time to re-route the cable yet.


            • #7
              Ever since this was first reported I've been trying to make it happen. The closest I've come is reading the light sensor using the IR sensor block. This turns the lamp off and the sensor disappears from the sensor view. After two seconds the red lamp comes back on regardless of what mode it was in before and what mode I use to read it. The sensor is essentially dead and I have to unplug the cable to turn it back into a color sensor. Reading the color sensor as a gyro, temperature sensor or sound sensor changes the sensor type in the sensor view and it messes up the sensor readings until you unplug the sensor. The behavior differs from reading as an IR sensor in that the lamp never goes off and changing the color sensor mode changes the color of the lamp.

              Other than that the only way I can make the color sensor go away is to unplug it. Even a tiny amount is enough to make break the connection.

              Is everyone who reported this problem using multiple color sensors?
              Last edited by Dean Hystad; 11-01-2017, 12:46 PM.


              • #8
                The OP says the LED turns off for 1 to 2 seconds and the red LED comes back on. Is that the case for others reporting a problem with the color sensor?


                • #9
                  I have also the same problem with the color sensor turning off for 1-2 seconds and turns back on again .. i was running a simple line following program .. i also have 2 color sensors conectet to the Brick but IT was only the color sensor i was using in the program that turned off and on the other one was on the Hole time... when this happens the gyro sensor also starts to drift ...
                  i also tried to change to a different Brick but the same happend to that one to ..
                  the program contains a color sensor block to math bloks and to unregulated motor blocks for the line following inside a loop block..
                  The color sensor is set to light intensity
                  i also upgraded resently to firmware 1.09e
                  I have ordered a new color sensor to se if the problem dissapear
                  its very frustraiting because the drive motors on the robot still is going forward so that it has lost the line when the color sensor turns back on again It happening very randomly sometimes after 10-15 secunds running the program and other times it takes up to 1 minutt
                  Last edited by Petter_m77; 12-20-2017, 04:05 PM.


                  • #10
                    We are using 2 ev3 color sensors and from time to time we got the same issue - both of them are switched off and on after 1-2 seconds.
                    Have anyone found any kind of solution for this problem?
                    I will be really appreciated for any answer!
                    Thanks in advance!


                    • #11
                      I am having the same issue. I am using the colour sensor in RGB raw mode. The sensor will give me the exact same RGB values for 40 plus readings before it reboots where it will come back up in reflection mode. Based on the hardware developer guide the reboot happens when the sensor misses 5 NACK calls from the brick, but before that the values all seem to be the same for the previous calls when the sensor is about to become inactive for whatever reason. In other modes it is much harder to anticipate this, since getting the exact same value is reasonable. I am pretty stumped on how to move forward.


                      • #12
                        Originally posted by Lusura View Post
                        I am pretty stumped on how to move forward.
                        What version firmware do you have installed on the robot?


                        • #13
                          We have had this problem happen for the last 2 years, but it seemed to get worse last year. I believe our robot is on 1.09e and we have 2 color sensors. We also are plagued with random gyro drift/runaway.

                          We have wondered about the cable connections in the past, but re-routing did not seem to improve.


                          • #14
                            Originally posted by View Post
                            We have had this problem happen for the last 2 years, but it seemed to get worse last year. I believe our robot is on 1.09e and we have 2 color sensors. We also are plagued with random gyro drift/runaway.

                            We have wondered about the cable connections in the past, but re-routing did not seem to improve.
                            Getting worse either means you use the sensor more, or for more critical things, or the sensor/cable is wearing out. A cable problem will get worse over time. Not too long ago I threw away all my NXT cables because they were getting unreliable.


                            • #15
                              You are correct in that they are using the sensor more for critical things. We ordered new cables to try that, but sometimes both sensors would fail at the same time. This would lead me to believe that it is a software/control brick issue.