Announcement

Collapse
No announcement yet.

The EV3 input port timing bug (related to Gyro drift)

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

  • #31
    Originally posted by Petter_m77 View Post
    I am not inn the fll world i just have a couple of ev3 sets for education USE with my daughter ...
    I have a big problem with the color sensors they they sundenly turns off and after 1-2 seconds ITS working fine again this when a program is running but when this happens the gyro also start to drift ... very strange never had this problem before i upgraded to 1.09e . It all started after the upgrade
    Sorry for this late answer but I have not visited the forum in the last weeks. I have no idea about how to solve your problem and i think that you should start a new thread with a more detailed description (with a step by step description on how to reproduce).

    Comment


    • #32
      Originally posted by mattmnelson View Post
      Frederic--

      I posted a detailed reply last weekend. Only the first two characters posted--the first two characters of your name. Apparently, the forum software does not support an "e" avec un accent aigu. I will rewrite it when I have some time, hopefully this weekend. Thanks again for your efforts.

      --Matt
      Hello Matt,

      Please, post it. Thanks for your kind words.

      Comment


      • #33
        Frederic--

        Sorry for the delayed reply.

        Last season, the team approached the refrigerator from the north after passing over the crosswalk. The team then had their robot run (ram?), repeatedly (8 times), into the back of the fridge thereby ejecting the food from the front of the fridge. However, after going over the crosswalk barrier and after repeated back-and-forth runs at the fridge (which needed to be rather fast and abrupt) the robot would often get knocked around and would no longer be heading exactly south. If this happened early in the process, the error would sometimes accumulate to the point where the robot would miss the fridge on subsequent cycles.

        After testing revealed this, the team decided to implement a check using the gyro after each run at the back of the fridge to correct the heading if off by more than a couple degrees. This usually worked quite well. Unless, of course, the gyro started to drift during the mission--at which point the robot would start turning in a circle and strand the robot. It only happened occasionally, and though frustrating to the kids, did not seem to bother them much. Besides, the team had other cats to whip. The team researched and implemented a program that would run at the start of the mission to check whether the gyro was drifting and. if so, then reset it. However, this was at the start of the mission. If the drifting starting during the mission, then their program could not catch the drift condition.

        I don't have a good sense about how often the drifting would occur during the mission, but it was not often--perhaps in the 10% range. I recognize that the team's whole approach to the mission had some flaws. However, it was their solution to the mission. And, I take a hands-off approach in such matters. I was pleased that the team identified that the gyro could offer a solution to their problem.

        Though the drifting was not a huge concern to the team members, it bothered (and still bothers) me. Initially, I thought perhaps the rapid deceleration when hitting the fridge might have exceeded the capacity of the gyro (saturation?) and caused the problem. And that might be. However, there were times when the gyro would start drifting that could not be explained by rapid deceleration (or acceleration), suggesting that there was something else occurring at least some of the time.

        Our team has their competition in two weeks. And, they are using the gyro again this year--though to a lesser extent. I've discussed with them my concerns about the gyro--based in large part on your efforts and those of the Seshan brothers, and our experiences last year. They have chosen to use it still. They understand (at least somewhat) the risks. Learning the limitations and risks of any particular solution is a good exercise. Everything in life has trade-offs.

        Thanks again for your detailed write ups on both the internals of the gyro and the timing problem. I know enough to follow most of what you have written, however I most certainly don't have the knowledge to discover and characterize what you have.

        It makes me wonder if when implementing the second generation gyro, code was reused in the firmware from the first generation without adequately accounting for the differences between the first and second-generation gyro chip. It strikes me, if I understand your report correctly, that there seems to be problems (or perhaps incompatibility or communications out-of-spec) on both the intelligent brick side (it initiates the communication reset), and on the sensor side (it sends data more rapidly under some conditions than is expected by the EV3 brick thereby causing the EV3 brick to request that the gyro reset).

        I find particularly interesting your finding that some second-generation gyro sensors are more likely than other second-generation units to create the timing error. What is likely the cause? Is it an issue with the mems component variation, gyro chip oscillator, the microcontroller oscillator, or something else?

        Comment


        • #34
          Originally posted by mattmnelson View Post

          Though the drifting was not a huge concern to the team members, it bothered (and still bothers) me. Initially, I thought perhaps the rapid deceleration when hitting the fridge might have exceeded the capacity of the gyro (saturation?) and caused the problem. And that might be. However, there were times when the gyro would start drifting that could not be explained by rapid deceleration (or acceleration), suggesting that there was something else occurring at least some of the time.
          Thanks very much for your story.
          The "something else" was probably the "EV3 input port timing bug

          Originally posted by mattmnelson View Post

          It makes me wonder if when implementing the second generation gyro, code was reused in the firmware from the first generation without adequately accounting for the differences between the first and second-generation gyro chip.
          I really think that it is the firmware of the first generation gyro that has been adapted to the second one, but I might be wrong. I do not think that they have done it "without adequately accounting for the differences between the first and second-generation gyro chip". If I would have written those firmwares, I would have only sent the data only when they have changed or after a request. But anyway, you must never forget that the bug is in the EV3 firmware and that the Gyrosensor is probably respecting the specification of the protocol of the EV3 input port (I say probably because I do not have those specifications and I have to speculate).

          Originally posted by mattmnelson View Post
          it sends data more rapidly under some conditions than is expected by the EV3 brick thereby causing the EV3 brick to request that the gyro reset.
          This is wrong. I am pretty sure that Gyrosensor respects the specification of the protocol. Once again, the bug is in the EV3 firmware, even if a change in the Gyrosensor firmware could avoid it.

          Originally posted by mattmnelson View Post
          I find particularly interesting your finding that some second-generation gyro sensors are more likely than other second-generation units to create the timing error. What is likely the cause? Is it an issue with the mems component variation, gyro chip oscillator, the microcontroller oscillator, or something else?
          I do think that it is a mix of those three tolerances, the bigger one are the speed of the RC oscillator of the MCU of the gyrosensor and probably the tolerances of the MEMS sensor. The tolerance of the oscillator of the MCU of the EV3 should be much smaller. Please, never forget that the problem is in the EV3 firmware, not in the Gyrosensor.

          Comment


          • #35
            Originally posted by NiceCoach View Post
            The "something else" was probably the "EV3 input port timing bug."
            Yes, certainly seems so. Thanks again for describing the problem.

            Originally posted by NiceCoach View Post
            Please, never forget that the problem is in the EV3 firmware, not in the Gyrosensor.
            If the problem is in the EV3 firmware, then this strikes me as a good thing, right? LEGO already has in place a mechanism for updating the EV3 firmware. This would allow a quick and inexpensive means of solving the problem for the large existing user base--assuming of course, that a firmware fix can be implemented and will be implemented by LEGO.

            Comment


            • #36
              Originally posted by mattmnelson View Post

              If the problem is in the EV3 firmware, then this strikes me as a good thing, right? LEGO already has in place a mechanism for updating the EV3 firmware. This would allow a quick and inexpensive means of solving the problem for the large existing user base--assuming of course, that a firmware fix can be implemented and will be implemented by LEGO.
              That is right and it is my hope that it will be done...

              Comment


              • #37
                Originally posted by NiceCoach View Post

                I am sorry but I do not share your opinion. Hardware used for educational purpose should work without any flaw.

                I have some news from Lego, they sent me this (a few days ago):
                "I have reviewed your notes on troubleshooting the problem, and must say thank you very much for the detailed notes and supporting screenshots. I can easily reproduce the problem and now know exactly what to look for."
                So Lego can now reproduce the problem. A fix might come soon...
                About The EV3 input port timing bug (related to Gyro drift) Thanks for your pdf Documentation that was very helpful. Do you know when the Gyrosensor is fixed by Lego? Or is it allready fixed?

                Comment


                • #38
                  Frederic--

                  Do you know whether the new 1.10E firmware addresses the input timing bug? Thanks again for all your work.

                  --Matt

                  Comment


                  • #39
                    Hi,

                    Sorry Tommi for this late answer but I have taken some distance with the FLL.
                    The last news from Lego is that they are unable to correct this bug (two months old information)... Yes, they can reproduce it with the hardware that I have sent them, yes, they understand all my work and acknowledge that it exists but... they can not fix this because they do not really understand what the bug is really triggering into the EV3 firmware. If you are into development, you know that a bug that can be reproduce at will is (normally) easy to understand and to correct... But not at Lego...

                    Sorry Mat but I have no access to the education version. So I have no clue but I think that Lego would have sent me a mail if had corrected the bug. The last information (two months old) is that it is not corrected.

                    Comment


                    • #40
                      Thanks for your reply. The new education version of the firmware is a few months old. So, I suspect your lastest correspondence from LEGO was after the new firmware was released.

                      Thanks again for all your efforts. I'm sorry to hear LEGO has not found a solution.

                      Comment


                      • #41
                        NiceCoach Thanks for your work. Does this mean if I turn slowly I will not trigger the bug easily? I am thinking of using the gyro sensor to keep me moving straight towards an angle and use motor_steer to turn.

                        Also how do you define turning right/left? What's the orientation and reference with respect to the gyro sensor.

                        My team's robot would somethings suddenly start spinning when it wants to make a turn (using gyro sensor to measure the angle) and I wonder if we hit this bug. We have yet to do some data logging to see what's the measured angle.

                        Comment


                        • #42
                          ws1088 :

                          >Does this mean if I turn slowly I will not trigger the bug easily?
                          No. If you move the sensor,even slowly, the bug can appear.

                          >I am thinking of using the gyro sensor to keep me moving straight towards an angle and use motor_steer to turn.
                          I do not want to be nasty (I assume that you are a coach), it would be better if it was the idea of your team and not your idea...

                          >Also how do you define turning right/left? What's the orientation and reference with respect to the gyro sensor.
                          I suppose that the sensor is used with the red arrows pointing to the sky

                          >My team's robot would somethings suddenly start spinning when it wants to make a turn (using gyro sensor to measure the angle) and I wonder if we hit this bug.
                          Could be...

                          mattmnelson

                          I can now tell you that the firmware 1.10E does not correct this bug...

                          Comment

                          Working...
                          X