We are team SparkTech#24345 from Romania and we decided to use the Sparkfun Optical Tracking Odometry Sensor for our robot and we observed that after some time of using the sensor and constantly cleaning the surface, it stopped being consistent with readings, and running some tests revealed a massive error after some movement that was not there initially. We thought something we did to it over the last months caused it to break, so we borrowed a new one that ran as expected for about one day. The strange thing is, after one day of tests, the second OTOS started showing the exact same errors as the first one, even though it was barely used. We need some help figuring out what happened to the sensors, since we managed to buy a third new one that will arrive soon but we are afraid of breaking this one like the rest. After the errors, we tried the corrected OTOS class, as well as the non-corrected one, but the results were the same, with massive inconsistencies. We also tried cleaning the sensor with isopropyl alcohol, with no change. Any ideas we could troubleshoot will help.
How far away is the sensor mounted? Maybe share a photo of the location
What type of surface is it attempting to read? How is the sensor becoming dirty?
I assume the ‘corrected class’ means you tried the calibration & offset…it might be worth re-trying
The sensor is mounted at a height of about 9mm, and we are trying to read the FTC foam tiles. We noticed that the sensor had to be cleaned every once in a while, probably because of the accumulation of dust from the game field. In the FTC OTOS libraries there are two classes, OTOS Sparkfun and OTOS corrected. We don’t know the difference between these two, but we did try them both, with no change to the result. As for the calibration and offset, we tried to change it multiple times, and while running the liniar calibration after the error we noticed different results. If you need any additional information or photos, let us know. Thank you so much for the help.
Sorry to hear you’re having trouble!
Can you please try to quantify the inconsistency you’re seeing, and under what conditions? It’s very difficult for us to diagnose anything or help without some numbers and clear test procedure. The OTOS typically has <1% accuracy, which is cumulative over the entire path length. So if your robot drives across the field and back (~200 inch path), then it’s expected to be off by up to 2 inches. We just need to understand if the inconsistency you’re seeing is within 1%, or if it’s substantially worse than that. I’m guessing you’re seeing worse than 1%, but we need to quantify it to better understand the problem and know how to help.
To start, I would ask that you please try running the sample OpMode. Change the linear and rotational scalars to your calibrated values, but do not make any other modifications. Then move the robot by hand and record the measured coordinates versus where the robot actually is. For example, if you push the robot forward 6 feet forward, the coordinates should be close to (0, 72, 0) (assuming inches), within 0.72 inches in x and y (1% of path length). Keep in mind that FTC field tiles are not exactly 24 inches, so use a tape measure. Also be careful to not push down on the robot, because that would cause the OTOS to get closer to the foam surface (which can affect accuracy).
Since you’re seeing problems at “medium to high speeds”, repeat the test by pushing the robot faster and faster to see if there’s a trend. Also, can you quantify “medium to high speeds”? The OTOS should be able to track on the FTC foam tiles up to about 100 inches per second.
If you do other tests, please do so with the sample OpMode to ensure there’s nothing in your code causing problems, clearly state your test procedure, and report the measured versus actual coordinates of the sensor. That will help us better understand the problem.
It might also be helpful if you could please take a picture of the sensing element itself, both before and after testing. One problem we’ve observed is that if your robot builds up a static charge, that can attract dust particles onto the sensor and significantly affect its accuracy. I know you said you’re cleaning it, but if dust accumulates significantly during the test, that could explain the problem.
Also, I believe the “SparkFun OTOS Corrected” class depends on whether you’re using Road Runner or Pedro Pathing (links to both classes), but neither affect the accuracy in any way. It originally was created because of a bug in the FTC Java driver, which was fixed almost a year ago. But looks like the Road Runner one also adds some other features to aid compatibility with Road Runner, and that’s all. The OTOS itself does all the tracking, the driver just reads back the coordinates reported by the OTOS.
Hope this helps, please let us know how your testing goes!
Thanks a lot for the reply! We ran some more tests and it’s clear that the inconsistencies are worse than the 1%. We started out by running the callibrations starting with the linear one. We ran it four times, getting different multipliers each test: 1.2255, 1.1759, 1.1837 and 1.7785. For the angular calibration, we got 0.9524, 0.9266, 0.9167, and 0.9370. However, while testing, we noticed a slight drift in the angle of about 0.001 ticks a second. For the sake of testing, we calculated the avarages of each multiplier and used 1.3409 and 0.9332. Running the sample OpMode, we pushed the robot 48 inches 3 times at a slower speed of about 11 inches a second, geting y values of 41.62, 41.47, 40.12. We then increased the speed to about 22 inches a second, running five test and getting widely different results: 40.98, 38.70, 41.07, 38.11, 36.90. Finally, we once again increased the speed of the robot to about 40 inches a second and ran 10 more tests, getting y values of 32.52, 32.47, 33.55, 36.12, 40.22, 39.43, 38.49, 34.50, 37.23, 39.54. It is worth pointing out that the OTOS was operating normally until three days ago. But after one day of running autonomies, the sensor started showing the current errors that made it unusable for a consistent autonomy. We’re wondering if there’s anything that we did that could have caused this error to occur. There were no physical or coding changes before the OTOS started acting this way.
We took pictures before and after running the tests. However, it is important to note that we try as much as possible to keep the field and sensing surface clean, and we did not change anything to the way we cleaned them prior to the errors starting.
Before tests:
After tests:
Thanks again for all the help!