added joint encoder checkout to test script in sandbox

Description

Added a checkout step to the joint encoder test program to read out ECMIN and ECMAX values and motor-encoder/joint-encoder after running the joints around away from the indices for a while. Also writes joint positions to a .csv calculated from both motor encoders and joint encoder. This is what I developed and used, first to show that there was a problem with the TUD WAM's joint encoder data, and then to show that it had been fixed.

What to focus on

• I think we can use this as a quick checkout procedure to verify that the joint encoders look good. Does the code look good for that use case?
• The WAM system doesn't have a native way to ready joint position from motor encoders and joint position from joint encoders at the same time. The logger system needs system inputs, so I configured the WAM to use the motor encoders for it's native joint position output. For the joint encoder joint position I made an I/O system that pulls the joint encoder positions out of the WAM object with a method call every time the system framework calls operate(). This appears to work, but it seems, uh, not entirely in the spirit of the systems paradigm. Is there a more straightforward way I could have done this? I thought about extending the WAM class to have another system output, but that ended up being quite the rabbit hole of wam and low-level-wam and low-level-wam-wrapper.

Resources

• plotting script for checkout data

Timeline

• No rush on this review, anytime before Oct. 31 is fine.