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

  • gof
    replied
    Ok, Done! (needed more characters)

    Leave a comment:


  • mikets
    replied
    Originally posted by gof View Post
    It looks like the solution is now being implemented. I'd suggest closing this thread and continuing over here:
    http://ftcforum.usfirst.org/showthre...nt-team-update
    You are the original author of the thread. You can close the thread. At the top under the thread title on the right hand side, you see an "administrative" drop down which gives you the option of closing the thread.

    Leave a comment:


  • gof
    replied
    It looks like the solution is now being implemented. I'd suggest closing this thread and continuing over here:
    http://ftcforum.usfirst.org/showthre...nt-team-update

    I know the ODS is mentioned as still unknown, but it's more than likely that this is going to be the solution thread. Thanks to everyone who added more data to this thread to prompt the investigation by the core team (and to the core team for taking it on mid-season).

    Leave a comment:


  • mikets
    replied
    Originally posted by gof View Post
    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.
    I have a feeling the I2C improvement will also improve Analog performance. Regarding short term fixes on the ODS, did you try "unregistering I2C devices" when using the ODS and re-registering them afterwards? We are using the ODS to detect line while the I2C bus has 2 sensors on it (color, range). It's working fine detecting the line even without the "short term fix".

    Leave a comment:


  • zain
    replied
    As somebody who's been lurking on this and the related threads I just wanted to say "thank you!" to all you folks with the skills and wills to investigate and post this stuff. While I may understand what you guys are posting, and could thus steer the kids from trouble, I really lack the time and java skills to have done this kind of investigation on my own. Your efforts kept my kids, and surely countless other teams, out of the weeds. Understanding the current system's limitations really helped me ensure my kids had a positive experience this season so far. Even while using an MR range finder, gyro & integrated heading, and color sensor all at once.

    Leave a comment:


  • gof
    replied
    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).

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • Philbot
    replied
    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.

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • FTC7253
    replied
    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

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • HagertyRobotics
    replied
    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.

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • gof
    replied
    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.

    Leave a comment:

Working...
X