We have received and are testing our OTOS sensor. It is consistent, if inaccurate, on our FTC tiles. We tell the robot to drive 48", and the OTOS reports X of 48", though we are actually at X= 54". This is at the outside of the linear scale (.88), so we plan to work on some calibration of both sensor placement and of angular scale.
In the meantime, though, we set linear scale to be .88. We then built and relaunched, but the sensor still reports us at 48" when we’ve driven 54". Our call to set linear scale had no effect - either the FTC SDK didn’t properly set it on the chip, or the chip didn’t react.
The offset is also giving us trouble. Our coordinate system had X going in the opposite direction, but Y in the same direction as the sensor (in other words, move the robot forward, and X went down, and not up). So, I set the heading offset to 180 to see if that would help. Nothing. I then set it to 45. That should have done something - if it thought it was mounted at 45, when I push the robot forward, both x and y would change to compensate. But it didn’t. X just grew smaller as before.
The odd part is that we did do an offset for Y so that our robot could turn while driving and the center would stay in the right place. Now THAT seemed to work. When we added the offset, the robot behaved like the sensor was in the center.
Is there something I’m missing in the setup? Should offset be in radians even though we told it to report degrees? The sample code comments implies no. The lack of any change on the linear scalar is particularly troublesome. I have a feeling that we won’t get accuracy otherwise.
For the linear scalar, that one will be a bit more tricky to debug, since there’s a number of things that can affect that. I’m not aware of any issues with setting that particular config value, and I’ve typically never needed a scalar of more than 5% (eg. 0.95 to 1.05) in my own testing, so sounds like there’s some other issue. Things to check:
Is the sensor mounted correctly? Should be rigidly mounted to the chassis, oriented completely flat, and the front face of the optical sensor should be 10mm +/-1mm from the foam tiles (accounting for the wheels squishing into the foam).
Are you using standard competition tiles? I’ve seen some folks trying the OTOS on non-standard field tiles and getting bad results. The sensor works well on standard competition tiles, but that’s right at the edge of what the optical sensor is capable of, so any tiles that are darker, have more texture, etc. can cause tracking performance to quickly degrade.
Is everything clean? The OTOS can handle some dust and such, but large amounts can cause problems. If there’s dust or debris on the optical sensor, you can clean it off with some isopropyl alcohol and a Q-tip or similar. If your field tiles are dirty, try sweeping or vacuuming them.
How fast are you driving? The OTOS has a max tracking speed of 2.5m/s (100in/s); most FTC robots can’t achieve that speed, but still want to check. Also make sure you’re not going super slow, the accuracy can be degraded at particularly low speeds (eg. <0.25m/s or 10in/s).
Test at multiple speeds. The effective resolution of the optical sensor can fluctuate slightly at different speeds, so you should try to get an average of multiple speeds.
Make sure you set the linear scalar correctly. First set it to 1.0, then perform the test again. The required scalar value is calculated as true distance / measured distance, so since the OTOS is measuring 48" and you’re actually moving 54", your scalar should be 54 / 48 = 1.125
Thanks for the reply. Glad we’re not crazy wrt the heading offset!
As for the linear, it’s way off, so we want to calibrate angle first to make sure that’s not the issue (don’t think it is -Y seems accurate when we drive straight).
On your questions/comments:
It is at 10mm (we think) +/-1. We had the same results at 5mm (long story). There is, however, a 1mm lip around the sensor for the case. We measure up to sensor, but will the lip affect anything?
Yes, standard tile, light gray.
Tiles a little dirty, but not bad. A little deformation at some interlocking connections - how big an issue would that be. We’ll clean the sensor - though it is consistently off
Haha, I wish we were going that fast. We are also not that slow.
We’ll test
We have it backward - the video tutorial implied that measured went on top but we may have misread. Be even if it’s backward, shouldn’t it have then just expanded the error? Ours stayed literally the same - which is the primary reason for writing - 1-5 are things we knew we had to tune. But having the scale not change measured v. actual AT ALL was a problem we can’t fix.
Hmm, even if you set the scalar backwards, you should have seen a difference in behavior. When I have some time free, I will try to test to see whether it works on my end, and we can go from there!
In the meantime, one other solution you can try is to treat the measurements from the OTOS as being in a different “unit” and multiply all those values by a scaling factor. I know that’s not ideal (the sensor should do the right thing in the first place), but hopefully that will be sufficient for you to keep making progress!
As in adjust in our code? Not a bad idea, esp if x and y are off differently (which I hope would not happen. Where it can get ugly is on the diagonal, as the multiplier might scale differently on the hypotenuse - with odometry wheels you can scale before the kinematic calculation. I assume that’s what your scale does.
I just tested on my end, and setting the linear scalar works fine for me. If you’re still having issues, could you please try the following:
Run the sample OpMode unmodified. Move the robot by hand a known distance (straight line along one axis), and note down the measured coordinates.
Change the linear scalar to 0.9 and run again. Move the robot in the same way as before, and note down the measured coordinates. You should see a ~10% difference from before.
Sounds like you have a custom OpMode for your testing, so I just want to verify none of your code is causing any issues, since the sample OpMode works fine on my end.
One other things to check - have you removed the yellow Kapton tape from the optical sensor? That absorbs some of the laser light, which could affect its measurements.
OK, pics of placement uploaded - we are about as close to 10CM as we are going to get. We had taken the tape off, but we cleaned it, and it now seems very accurate on lighter/newer tiles. Perhaps there was tape residue. On our slightly older, more beat up field it was now off about 2". I am hopeful that the amount off is not field dependent.
We can test the sample code. Our code is the sample code copied into a separate class, but maybe there is a timing issue.
Glad you’re getting better results now! And your mounting looks fine to me.
Based on my own testing and comments from other users, there shouldn’t be too much variance between fields, as long as they’re standard field tiles that aren’t too dirty or beat up. If it’s a concern, FTC competitions permit teams time for sensor calibration, so you could use that time to verify and adjust your linear scalar if needed for that particular field.
Linear tracking appears to work now, even in our code. Perhaps the dirty sensor was messing with the scaling readings, but we were able to get consistent scaling changes.
