Announcement

Collapse
No announcement yet.

Color sensor unexpectedly switching off

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Have seen it too. Sometimes my EV3 misrecognises sensor type and reports... touch sensor (seen through port view)! Probably, port contacts got dirty or worn out.
    2016 WRO Regular Junior
    2017 WRO Regular Senior
    2018 WRO Regular Senior

    Comment


    • #17
      I have been competing in wro for 5 years now and have seen this happening many times.For at least 3 years we couldn't figure out why the sensors where switching off.After a lot of testing we managed to find why.The bluetooth module ,when it is being used, drains voltage from the ev3 batteries causing the ev3 to have to power down one of it's ports for a short amount of time.

      Comment


      • #18
        Proof?

        If this was related to something as common as having BT enabled we would hear a lot more reports. I've been on the lookout for this problem since it was first reported and I've never seen it happen. I've never heard anyone else mentioning a correlation between the light sensor turning off and the batteries being low. Since the EV3 has a visual notification of low battery I think this would have been noticeable. I myself run many experiments where I drain the batteries down to the point that the EV3 shuts down, and I've never seen the light sensor turn off.

        I'm really interested to hear about how you came to this conclusion. I'd be happy to run your experiments on my equipment to see if I can duplicate your results. I'm sure others, especially those who've had this problem, would also like to do so.
        Last edited by Dean Hystad; 03-10-2019, 12:34 PM.

        Comment


        • #19
          We're having this same problem with the color sensors shutting off unexpectedly. We are using two color sensors. We have two bots running 1.09e and two bots running 1.09h. We'll run an experiment today to see if we notice a difference in occurrence due to the firmware.

          We've considered the battery being the problem; but we don't think the problems stems from a low battery, as the problem sometimes presents itself when the batteries are fully charged.

          I think we're noticing this problem because the particular robot game that we're working on is heavily dependent on the color sensors.

          Comment


          • #20
            We ran the bots to compare firmware versions 1.09e and 1.09 h. The color sensors' LED lights switch off with both robots. We do not think the firmware has anything to do with this problem.

            We've observed this peculiar coincidence: During certain critical moments when we need the color sensors to work, the LED lights switch off.

            But, when we run a PID line following program, the color sensors are reliable. The LEDs do not shut off (knock on wood).
            This leads me to hypothesize that the problem is with the programming and/or power consumption immediately prior to the color sensing block.

            Disclaimer: I'm a coach who is an accountant. I know little about robotics and engineering. I'm sorry if I'm not using accurate terminology.

            We were curious to know if the complexity of the programming prior to the color sensing or power consumption had anything to do with the LEDs shutting off.

            To test, we placed a bot with two color sensors on the table and had it move forward across a black line; when it sensed the line, the bot moved backwards; the bot repeated the loop until manually stopped.

            During the test, we introduced the following variables.
            1.Using unregulated motors, we ran a "GyroGoStraight" MyBlock followed by a color sensing block (forward; then backwards; repeat)
            2. Using regulated motors, we ran a "GyroGoStraight" MyBlock followed by a color sensing block(forward; then backwards; repeat)
            3.Using unregulated motors, we ran a Move Tank forward followed by a color sensing block; then Move Tank backwards followed by color sensing block (repeat)
            4.Using regulated motors, we ran a Move Tank forward followed by a color sensing block; then Move Tank backwards followed by a color sensing block (repeat)

            Our anecdotal observations indicate that there is less LED shut off with regulated motors. There didn't seem to be a huge difference with complex or simple programming. However, we did not meticulously record our results because we're in a time crunch for a competition this weekend. We'll run some better experiments over the summer unless someone solves this problem before we do.

            Or maybe someone has already resolved this issue? If so, please post....thank you...

            Last edited by C3SD; 03-13-2019, 03:21 AM.

            Comment


            • #21
              Originally posted by C3SD View Post
              We ran the bots to compare firmware versions 1.09e and 1.09 h. The color sensors' LED lights switch off with both robots. We do not think the firmware has anything to do with this problem.

              We've observed this peculiar coincidence: During certain critical moments when we need the color sensors to work, the LED lights switch off.

              But, when we run a PID line following program, the color sensors are reliable. The LEDs do not shut off (knock on wood).
              This leads me to hypothesize that the problem is with the programming and/or power consumption immediately prior to the color sensing block.

              Disclaimer: I'm a coach who is an accountant. I know little about robotics and engineering. I'm sorry if I'm not using accurate terminology.

              We were curious to know if the complexity of the programming prior to the color sensing or power consumption had anything to do with the LEDs shutting off.

              To test, we placed a bot with two color sensors on the table and had it move forward across a black line; when it sensed the line, the bot moved backwards; the bot repeated the loop until manually stopped.

              During the test, we introduced the following variables.
              1.Using unregulated motors, we ran a "GyroGoStraight" MyBlock followed by a color sensing block (forward; then backwards; repeat)
              2. Using regulated motors, we ran a "GyroGoStraight" MyBlock followed by a color sensing block(forward; then backwards; repeat)
              3.Using unregulated motors, we ran a Move Tank forward followed by a color sensing block; then Move Tank backwards followed by color sensing block (repeat)
              4.Using regulated motors, we ran a Move Tank forward followed by a color sensing block; then Move Tank backwards followed by a color sensing block (repeat)

              Our anecdotal observations indicate that there is less LED shut off with regulated motors. There didn't seem to be a huge difference with complex or simple programming. However, we did not meticulously record our results because we're in a time crunch for a competition this weekend. We'll run some better experiments over the summer unless someone solves this problem before we do.

              Or maybe someone has already resolved this issue? If so, please post....thank you...
              Was it repeatable in a predictive pattern when running your tests over and over?
              This year my team ran the wires for the robot a lot tighter than in previous years. When one (careless) team member would take out the robot's charging cable, he somehow would often dislodge a color sensor. He wouldnt notice it until after he rand the robot and it looked for a line and it would go right past it.

              I'm not saying your problem is caused by a sloppy kid. It could be that, or a slightly damaged wire, or something else entirely.
              We have seen the robot do weird things when it is first booted up, but those times were few and far between.

              Comment


              • #22
                Thank you cschaffer. Your point about the battery cable is well taken. I will mention what you've said to my team. I hope it's as simple as what you've suggested.

                To answer your question, no, there was no predictive pattern. The problem was not repeatable. It's random. Sometimes Port 1 color sensor; sometimes Port 4 color sensor. Sometimes a shutoff would occur "back to back" (fairly rapid succession); sometimes the robot would run the back/forward loop twenty times without a shutoff.

                I will post again if our problem seems to stop after being more conscientious during the handling of our charging cable.

                Comment


                • #23
                  Two advices:
                  1. Turn Bluetooth off when possible. Brick communicating with PC all the way and sometimes this leading to sensor/port reset.
                  2. Use stable firmware (v1.06) if possible.
                  2016 WRO Regular Junior
                  2017 WRO Regular Senior
                  2018 WRO Regular Senior

                  Comment

                  Working...
                  X