The encoders are driven by the way that they’re initialized underneath the hood, and it’s a bit odd. Perhaps the HAL implementation will get updated this fall and it’ll get better. Sorry about the lack of documentation. Feel free to improve it and submit a PR.
You’ll note of course that the place where the implementation tends to be strong is in stuff that we used, and as you mentioned I like to attach encoders to the CAN devices directly instead of using them standalone.
When you say they are driven, I’m curious what you mean by that. This is solely for testing/simulator use so we can verify the behavior of various controllers. I assume that since the code has no idea how the physical system is connected it can’t automatically increment encoders. What I’m trying to write is the physics.py:update_sim(self, hal_data, tm_diff) function. Visibly, the robot is moving properly in the simulation but encoder values can’t possibly update on their own. I’m trying to add that.
And don’t worry, I’ll take a whack at a PR (or one of my students will) once we have something to contribute back. And we haven’t (yet) made the leap to CAN though I suspect that might be coming in the near future. But possibly one major change in the software is enough for the time being.