Hello - We having been trying this new (and exciting) FTC approved sensor for a couple of days now, but our accuracy seems not good. I’m talking about starting the base robot in one position, moving it forward 1 tile (24 inches), and moving it back to the starting position. The new x position will sometimes change by 1 inch. That seems really excessive. If we repeat the test (forward and back), the x position keeps growing, always in the same direction. Please, please, please, any advice? We are using the code from sparkfun’s github: sparkfun/SparkFun_Qwiic_OTOS_FTC_Java_Library (github.com)
So another 2 hours of trying to get it to work has made it worse. I saw a post about cleaning the sensor with isopropyl alcohol and a qtip, but no improvement. (And yeah, the shipping tape is off.) I’ve played around with the height, adding 0.5mm shims until too low or too high, no luck. The heading always seems ok, but over 100 inches of linear straight line travel, it will report anywhere from 59-76 actual inches. I have telemetry on the status warnOpticalTracking and warnTiltAngle, but they are false (I can induce them to be bad, so I think they are working?). What do I do?
If you’re still have trouble, here’s a couple things to try to diagnose the problem:
Make sure you’re running the sample OpMode without modification. I’ve seen several users reporting bad tracking, when in reality it was something in their code doing funky things; switching to the sample OpMode had correct behavior for those users.
Make sure you’re using standard FTC field tiles that are clean. The optical sensor tracks fine on the standard tiles, but it’s right at the edge of what the sensor is capable of tracking. I’ve seen users with non-standard tiles that are darker or have a different texture, and the sensor has miserable performance there.
If you’re still having trouble, try a different surface like hardwood or cement floors, or even white printer paper. Those surfaces should be a lot easier for the sensor to track accurately.
Thanks - we are running the sample opmode without modification. After your suggestions, I did use white printer paper, and it seems much better. However, our tiles are official AndyMark, less than 1 year old, and in great shape. We ran on much worse tiles last year at competitions. If the sensor can work on good tiles, then I think we have a bad sensor. Luckily, the good people at SparkFun are sending us a replacement to try. I will try to remember to come back and post those results as well once we get it. Thanks again!
Just checking to see if the new unit worked. We had accuracy problems with older, darker tiles but seem to be running ok on newer lighter tiles. If you are running OK that will make me feel better for the long run, as we have a lot riding on this thing working.
I bought two of these sensors in November. Both are reading erroneously with linear measurements. Angular accuracy seems OK, but repeated calibration attempts and other workarounds seems to pretty consistently yield a reading of around 69" when traveling 96". I have tried the sample OP code, along with other published code, plus our own tests. We have tried various mounts, distances and other fixes people have mentioned. Is there not a way to “open up” the linear scaling adjustment? In the meantime, we have a total hack in our code to work around it, but it also introduces resolution errors.
I bought two of these sensors in November. Both are reading erroneously with linear measurements.
Have these sensors been behaving the same way since November, or did they just recently start giving worse measurements?
consistently yield a reading of around 69" when traveling 96"
Behavior like this usually indicates the optical sensor is having trouble reading the surface well. Can you try the sensor on a white piece of paper and see if that gives better accuracy? If so, it may just not be able to track well on whatever surface you’re using. If not, ensure the kapton tape has been removed from the optical sensor and make sure it’s clean; specks of dust can collect on the sensing element and result worse tracking accuracy.
Is there not a way to “open up” the linear scaling adjustment?
No, that’s a limitation of the firmware. It only allows for -12.8% to +12.7% (8-bit integer under the hood), which is more than is ever needed when the sensor is working correctly (typically <5%). If you’re seeing much bigger error, that’s indicative of poor optical tracking, which can be inconsistent and not feasibly corrected by software. Using a bigger scalar would just be a band-aid solution to hide the true problem (and likely not really fix it since poor tracking is often inconsistent), so we don’t plan to allow for bigger scalar values.