search

acmerobotics / road-runner-ftc

BSD 3-Clause Clear License
0 stars 11 forks source link

Support for non-integer encoder values #6

Open j5155 opened 2 months ago

j5155 commented 2 months ago

This is an extremely strange request, but the data from the SparkFun OTOS sensor module is returned in non-integer inches instead of the integer ticks that encoders return, which prevents the tuning opmodes from running on it. I managed to implement support for it in the Java side at https://github.com/jdhs-ftc/road-runner-ftc-otos (through some somewhat cursed hacks), but though the data appears accurate, the graph of it is extremely strange (stepped and looping??).

I am assuming something in the Typescript code is assuming that the data is composed of integers, but I'm unfamiliar with Typescript and can't find the source of the issue.

A version of the quickstart that (at least in my limited testing) supports the OTOS for localization is here: https://github.com/jdhs-ftc/sparkfun-otos-quickstart I've also attached the ForwardRampLogger data I got using the OTOS. forward-ramp-1718681716947.json

j5155 commented 2 months ago

Discussed on the FTC Discord here: https://discord.com/channels/225450307654647808/1246977443030368349/1246977445433970709

j5155 commented 2 months ago

This is caused by the inverseOverflow function assuming integer for it's bit magic. Fixed in my fork by checking if the data elements are integers before running inverseOverflow

rbrott commented 2 months ago

Glad you figured it out. It does seem like you'll want more extensive changes to the tuning procedure (and the localizer interface as you've pointed out before).