These are coupled in a somewhat nonintuitive manner. Previously, we
would send a command every other request. Due to an oversight, we were
only sending a request once per second, which meant we were reading
position once every two seconds and writing position once every two
seconds. However, this seemed to work pretty well (at least the radio
performance was largely improved and qualitatively it seemed like the
controller was doing a better job of keeping up with the pointing
target).
I wanted the UI to update the position more frequently, so we keep the
scheme of sending a command every N requests, but we send
significantly more get position requests. These can be adjusted on the
fly in order to get an idea of how much the communication pattern
actually impacts the pointing performance.
This is very messy. I forgot how much callback-based async programming
sucks, especially without closures. Now I need to slap together the
UI.
This essentially has a "fixed" rate poll loop that alternates between
setting the position and getting the position. We return mangled
positions through the interface for display purposes, so this might be
usable.
I will never get tired of vendoring dependencies. ha ha. It is possible
I am insane. I had to do a lot of pruning to get these not to be
ridiculous (especially the unicode data, which had nearly 1 million
lines of... stuff).
