Announcement

Collapse
No announcement yet.

Odd problem with Core Device Interface (seems to impact both Color Sensor and ODS)

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by gof View Post
    Since it would appear that these don't include on-board integration, you'll have to handle that yourself in software. Ensuring timing and signal delays will be "interesting"...
    That's correct. We already have gyro integration support in our library so it's a matter of creating a new class and tie into that code, about 50 lines of code.

    Comment


    • #47
      One more issue with the analog RB-Cyt-141 gyro from RobotShop is that the datasheet recommends both a high-pass and low-pass filter be used. The AndyMark / Analog Devices gyro had these already. A low-pass and high-pass filter with only passive components such as resistors and capacitors should be legal under RE11.b.
      John McDonnell
      Volunteer, former mentor

      Comment


      • #48
        Originally posted by JohnMcDonnell View Post
        One more issue with the analog RB-Cyt-141 gyro from RobotShop is that the datasheet recommends both a high-pass and low-pass filter be used. The AndyMark / Analog Devices gyro had these already. A low-pass and high-pass filter with only passive components such as resistors and capacitors should be legal under RE11.b.
        Or, you can easily throw in a software low pass filter before integration.

        Comment


        • #49
          Might as well use an NXT gyro at that point especially if you already are using a Legacy module.

          Comment


          • #50
            Originally posted by 3805Mentor View Post
            Might as well use an NXT gyro at that point especially if you already are using a Legacy module.
            The Core Device Interface Module has 8 analog ports. So the analog gyro plugs in right there. There is no need to use a Legacy module.

            Comment


            • #51
              mikets, having the gyro on the analog side might not help you. Remember that the ODS is an analog sensor as well and we're seeing delays there on the order of 75-100ms. While better, it's not great. Additional testing seems to show some possible improvement by limiting the number of I2C sensors, but it's almost as if the SDK is waiting until it has received a refresh for ALL sensors before allowing any updates from any of them. I state this from observation, not direct knowledge. We're still looking for the smoking gun.
              Technical Coach, Newton Busters FTC 10138, FLL 3077
              Chicago 'burbs, IL

              Comment


              • #52
                Originally posted by gof View Post
                mikets, having the gyro on the analog side might not help you. Remember that the ODS is an analog sensor as well and we're seeing delays there on the order of 75-100ms. While better, it's not great. Additional testing seems to show some possible improvement by limiting the number of I2C sensors, but it's almost as if the SDK is waiting until it has received a refresh for ALL sensors before allowing any updates from any of them. I state this from observation, not direct knowledge. We're still looking for the smoking gun.
                My understanding of the analog sensors is that when you call "getData", it returns the voltage value immediately. There is no caching. Since analog sensors are "dumb" sensors. There is no talking "back and forth" like the I2C bus transaction. The sensors only give you an analog voltage and the A/D converters in the CDI will do the conversion. Yes, A/D conversion takes time but it is really insignificant. It's like putting a volt meter on the signal, you get the voltage immediately.
                So far, our analog gyro works great. Like I said, our code is running a 10 msec loop and I got different reading on EVERY LOOP!
                Regarding your ODS delay, I am not convinced it's an analog port problem. Now, ODS is different from the gyro. My understanding is that it pulses the LED light at 1000Hz and taking light reading when the LED is ON and also OFF so that it can eliminate environmental light. So in theory, you should get a reading every 1 ms. Even with SDK software overhead, I can't imagine it any slower than 10 ms. I have to admit that I was focused on the gyro so I did not do any tests on the ODS. We have our next competition coming up this weekend. I promise I will look into the ODS performance after that.
                But regarding the analog gyro. It completely works. In fact, we have tuned our turns really good with it.

                Comment


                • #53
                  BTW, I just realized our team has changed to use a Moto G3 phone as our RC phone. So it has a built-in gyro (ZTE speed phones don't have a gyro). So in theory, we could have used the phone's built-in gyro instead of the analog gyro and we do have a class in our library supporting the phone's built-in gyro (https://github.com/trc492/FtcSamples...droidGyro.java). In any case, either would work.

                  Comment


                  • #54
                    We have been having similar issues reading our ODS sensor while also having a modern robotics gyro and a adafruit color sensor connected to the same DIM. I wanted to share an interesting graph of an DIM analog input being fed by an analog sawtooth waveform (100ms period - 0-4volt amplitude). The red trace is from a continuous read of a DIM with only the analog input defined. The blue trace is the same module with both a color sensor and gyro connected and defined but not being read. The sampling delay goes from about 8ms to 25ms when the other i2c devices are connected.

                    Comment


                    • #55
                      Originally posted by HagertyRobotics View Post
                      We have been having similar issues reading our ODS sensor while also having a modern robotics gyro and a adafruit color sensor connected to the same DIM. I wanted to share an interesting graph of an DIM analog input being fed by an analog sawtooth waveform (100ms period - 0-4volt amplitude). The red trace is from a continuous read of a DIM with only the analog input defined. The blue trace is the same module with both a color sensor and gyro connected and defined but not being read. The sampling delay goes from about 8ms to 25ms when the other i2c devices are connected.
                      If that's the case, there is definitely a software architecture issue with the FTC SDK because it cannot be explained by I2C bus bandwidth since ODS is analog.

                      Comment


                      • #56
                        That definitely illustrates the behavior we see. There is an issue open on FTC github, but I haven't seen much activity. States this weekend, so we have to go with what we have at this point.
                        We followed previous suggestion to deregister the callback for the color sensor during init and keep the gyro active. When we reach the line find segment, we re-register the color sensor for the duration of the segment, and the deregister again. This definitely helps, but there are sometimes other color sensor issues. Gyro only: heading sample rate =~35ms. Gyro and color sensor: heading sample rate =~100ms

                        Comment


                        • #57
                          Originally posted by FTC7253 View Post
                          That definitely illustrates the behavior we see. There is an issue open on FTC github, but I haven't seen much activity. States this weekend, so we have to go with what we have at this point.
                          We followed previous suggestion to deregister the callback for the color sensor during init and keep the gyro active. When we reach the line find segment, we re-register the color sensor for the duration of the segment, and the deregister again. This definitely helps, but there are sometimes other color sensor issues. Gyro only: heading sample rate =~35ms. Gyro and color sensor: heading sample rate =~100ms
                          The above may illustrate a wilder issue with the overall sensor support architecture that may not be easy to fix. If that's true, I would not count on it being fixed any time soon. So I would suggest finding a different solution. For our team, we no longer have any issue because we switched to using an analog gyro and we are seeing different reading on every loop. Like I said in my previous post, you can also use the built-in gyro in Moto G phones. For our other I2C sensors, it is not very time sensitive. For example, don't care if it takes 200 msec to read the beacon color. For line detection, we use the ODS sensor and it has no problem finding the line (the robot was moving slow when finding the line anyway). For the range sensor, it has a sample interval of 75 msec which is adequate for us to just detect if we are close to the wall enough. So we are all good.
                          You probably should figure out what sensor requires shorter sampling time. I can't think of any except for gyro and try to find a work around for it.

                          Comment


                          • #58
                            Originally posted by mikets View Post
                            The above may illustrate a wilder issue with the overall sensor support architecture that may not be easy to fix. If that's true, I would not count on it being fixed any time soon. .
                            The Dev. team is already making inroads on improving I2C device performance.
                            This is due to the quality of reports being made by teams, our ability to replicate the problem, and the use of sniffer tools etc.

                            Several alternatives are being evaluated. Some are simple patches, other are more system-wide, requiring more changes but with possible greater impact.
                            The trade-offs are being assessed.
                            More reports will follow when results are definitive.

                            Comment


                            • #59
                              Phil,
                              Thanks for the update. It is nice to hear progress's been made. Without this feedback, teams don't know what to expect especially when competitions are around the corner. Please do brief us when the investigation has definitive results. The community may be able to help regarding the tradeoffs in fixes.

                              Comment


                              • #60
                                Thanks Phil, I've also heard from Tom via PM that work was in progress but it's good to hear it's still ongoing and (it would appear) improvements are being made. You mention I2C improvements but what about improvements in Analog (or Digital) when an I2C is present? If there were a short term fix to allow full speed (or at least a lot better) performance while the I2C continues to be tuned that would be wonderful as well.

                                To everyone who's been contributing to this topic, THANKS! Without corroboration of the issue and the excellent data and graphs that multiple teams have provided, I don't think this issue would have been investigated as vigorously as it has (and thanks to the SDK developers/internal team and Modern Robotics for their hard work to find a solution).
                                Technical Coach, Newton Busters FTC 10138, FLL 3077
                                Chicago 'burbs, IL

                                Comment

                                Working...
                                X