Encoders for testing

[Andrew Schreiber]

When implementing tests for an off season evaluation I've run into a lack of documentation on how to mock out encoders. Obviously, for booleans and analogs it is possible to do stuff like:

        hal_data['analog_in'][2]['voltage'] = self.position

However, for encoder data this becomes a bit more complicated. I tried checking into 1418's code but they are heavily based on CAN and seem to be mocking CAN messages reporting the encoder values.

Was curious if anyone had tried to do this and found a good way to do it?

(65% test coverage is bothering me)

[Andrew Schreiber]

In case someone else comes along curious about the same thing, because it wasn't intuitive to me, you can access the encoder count value by using:

hal_data['encoder'][index]['count']

Where index is the order they were initialized in. If you want to verify it's the correct pins you can check hal_data['encoder']['ASourceChannel'] and ['BSourceChannel']

[virtuald]

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.

[virtuald]

I suspect a good utility function to add to the test HAL would be 'get_encoder(pinA, pinB)' that would scan the list of encoders and find a matching encoder, and return that dictionary. (Bug report now at https://github.com/robotpy/robotpy-wpilib/issues/152)

[Andrew Schreiber]

Originally Posted by virtuald

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.

[virtuald]

When I said 'driven', I should have said 'the design for the encoders was driven'

[Andrew Schreiber]

Originally Posted by virtuald

When I said 'driven', I should have said 'the design for the encoders was driven'

Ah ok. I'll double check that this approach will work and I'll see what I can write up. If nothing else, this thread should show up in searches for anyone else who is lost.