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
-
Originally posted by gof View PostIt 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
Leave a comment:
-
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:
-
Originally posted by gof View Postwhat 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.
Leave a comment:
-
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:
-
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:
-
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:
-
Originally posted by mikets View PostThe 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. .
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:
-
Originally posted by FTC7253 View PostThat 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
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:
-
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:
-
Originally posted by HagertyRobotics View PostWe 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:
-
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:
-
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:
-
Originally posted by gof View Postmikets, 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.
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:
-
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:
Leave a comment: