Quanser Academic makes a line of products, which you can see demo'd at their YouTube channel, that are sold to university laboratories as teaching aids for control theory. Today I noticed a funny undocumented quirk about one of those products. I have notified Quanser of this, and there is some indication that they will update their documentation to reflect this quirk. However, because their documentation is not on-line, it's hard to see how that update will ever reach people who have already bought these products.
I TA a graduate control lab, and today's lab had the students design and implement an LQR controller that made use of a full-state observer to control Quanser's flexible joint. The motor angle is measured by a shaft encoder (which is the output we use to drive our observer), and the arm angle is measured by another encoder. We don't need the measured arm angle because we're using a full-state observer, but we still capture it for comparison to our estimated arm angle.
The students build a controller that stabilizes the plant to a moving equilibrium that tracks a square wave. At every transition, the observer trajectories had some peaky transients, as is expected, but it appeared like they were always in the wrong direction for the arm angle and its speed. I dismissed this as peaking, but one group wanted to investigate further, and so I had them track a sine wave instead. What did we find? The arm angle and speed estimates were always EXACTLY 180 degrees out of phase with the measurements.
I was shocked, and so I looked into it. Visually, I could tell that the FLEXIBLE JOINT's ANGLE ENCODER is mounted UPSIDE DOWN with respect to the motor's angle encoder. That means that rotating the motor to the "right" produces a positive angle even though rotating the JOINT to the right produces a NEGATIVE angle! The observer had it right; it was the MEASUREMENTS that were incorrect! (I built a minimal example to test my hypothesis, and what I say matched what I observed; the opposing rotations lead to equal signs)
Nowhere is this documented. Because this angle is not directly driven (it's coupled to the assembly via springs) and the arm+spring system is naturally stable and fast, this POSITIVE FEEDBACK doesn't lead to destabilize the system unless you have extremely high gain. So I'm guessing no one ever noticed. Multiplying the measurement by -1 restored intuition. I drilled down into some Quanser demo code, and I found that they do the same thing in their controllers. I have no idea why they would not document this in their rotary joint docs. Do they expect everyone to go through all of their MATLAB and Simulink code?
I could understand this error if the flexible joint was a generic component made by a different company, but the joint is solely for the purpose of connecting to the motor, and so it would make sense that its encoder orientation would match the motor encoder orientation! At the moment, we need different gains for both.
2 comments:
I used to TA a control lab at Purdue using Quanser setups, too. Not the flexible-joint one, but the multi-purpose one with a seesaw, a track, a cart and a pendulum. We have four.) The setups are taken apart and put together again every semester by a support staff to make a different system, and the seesaws are sometimes mounted in the opposite direction if he doesn't pay attention -- two supposedly identical setups can have different positive directions for the same encoder! We (or rather I, no idea about the other TAs) almost always had to check the calibration. While it's annoying, I don't see how this is a problem. What if you decide to choose a different positive direction when modeling?
The issue with the flexible link is that...
*) There is only one way to assemble it. There's no option of a TA putting something on backwards.
*) Models are already provided by Quanser (in multipe places) for the joint. Those models have both angles going in the same direction. So you have to invert your measurements in order to agree with Quanser models (in fact, in Quanser's sample Simulink code, that's exactly what they do even though they don't mention it anywhere in their docs).
*) The flexible joint is made to work with SRV-02 motor specifically. The flexible joint "module" has no use without the SRV-02.
*) The two encoders (joint and SRV-02) have the same axis of rotation.
*) The joint documentation mentions the encoder calibration gains, but it makes no mention of the different encoder directions.
*) There are no figures anywhere documenting the different sign conventions. You're told about the magnitude of the SRV-02 angle, the magnitude of the joint angle, but no information about their relative directions.
There are certainly other plants (like the 2DOF helicopter plant that has encoders that have linearly independent rotational axes) in which you wouldn't expect any particular relationship between encoders. However, in this particular case, it's natural to assume that the joint angle and SRV-02 angle have matching directions (they share the same rotational axis, there is only one way to put them together, and Quanser provides a model of their dynamics that uses variables that go in the same direction). It's also natural to assume that if it wasn't that way, it would be documented right next to all of the other joint angle documentation.
My gripe is either with the design (even if they couldn't fix the encoder, it would be easy to swap the EncA and EncB channels that are *HAND SOLDERED* onto the CUSTOM AT CONNECTOR built into the joint) or the documentation (with all of the other evidence that the two angles should go in the same direction, there is no documentation that reminds you that they're NOT).
The SRV-02 flexible link is constructed so that I don't have to build my own from spare motors and parts in the lab. If I have to manually calibrate every single sensor, then I might as well just build the thing myself.
Post a Comment