Individual Progress
Analog Voltage Reference PCB
Since the last progress review, I developed a circuit that provides a clean +/-5V reference from battery voltage (Figure 1) and buffers the linear potentiometer wiper before sending it to the DAQ (Figure 2).
The first step in the voltage reference is to convert battery voltage to +/-15V power via a pre-packaged solution from Murata. I had initially experimented with building my own circuit, using a LDO and switching inverting regulator, but the LDO was not a good choice due to overheating. The current sourced by the switching regulator was higher than I had expected, and there seemed to be EMI generated by the capacitor associated with the switching regulator. I believe that the Murata packaged solution will be easier to use, and doesn't cost much more than the combination of ICs that I had chosen. In the meantime, Robin and Jess built the original circuit on a breadboard, and moved the switching capacitor to reduce EMI. Until we have time to assemble and test the new circuit, we will continue using this circuit.
This +/-15V voltage is then converted to a +/-5V analog reference signal using a reference circuit taken from the datasheets of the two components involved. The comparator input of the 10V reference is attached to the desired -5V analog reference, which is the overall output of the instrumentation op-amp (in-amp). The desired +5V analog reference is wired to the in-amp in an inverting configuration, with the in-amp defaulting to unity gain. Because the two analog references are constrained to be the sign inverse of each other, the circuit quickly converges to the desired +/-5V reference.
The second part of this circuit consists of two dual op-amp ICs. One IC is dedicated to each linear potentiometer, with one of the op-amps in a unity gain non-inverting configuration that feeds into the second op-amp, which is in a unity gain inverting configuration. The differential voltage range when the +/- WIPER inputs are connected to a DAQ is +/-10 volts, which gives full resolution when used with the Elmo drive's analog input. Even though we are not currently using the Elmo to read this signal, the USB DAQ is configurable to this voltage range.
If I had known that we would not be using the Elmo as our DAQ, I could have chosen an alternative voltage range for the voltage reference, which would have made the voltage converter selection easier. There are many converters that output +/-5V, but this voltage cannot be used for the rail supply of an op-amp that will hit +/-5V. In contrast to the Elmo, the USB DAQ we use has options for +/-5V and lower values.
Ultimately, the decision I made on which voltage range to use may turn out to be correct. One simple configuration for the leg eliminates the USB DAQ and uses the Elmo drives to read the linear potentiometer voltage. Alternately, in a real product version, the linear potentiometer may be eliminated and replaced with the difference between the load (absolute) and motor encoders, giving the spring deflection. This will probably be necessary because the motor encoders are incremental, so they lose their absolute position reference when the leg is depowered.
Finally, I laid out the PCB and ordered two copies using Advanced Circuits' Bare Bones PCB service, which does not include soldermask or silkscreen but which provided a weekend-turn with 2 day shipping for the same price as their $33 board/educational pricing, which takes more than a week.
FSR Swing/Stance Transition Detection
After our demo on Monday, I took another look at the swing/stance detection, and John suggested placing the FSR in the iWalk adapter itself. It turns out that this works much better than placing an FSR inside the knee attachment. The knee attachment is clamped tightly, which places too much pressure on the FSR even when the leg is in swing. This makes detecting the transition very difficult.
By contrast, the FSR in the iWalk knee support experiences almost no pressure when the user is in swing, and a simple voltage divider configuration serves to detect the transition using the existing code. The transition can be sensed almost immediately, and with low false-positive/negative rates. Future work in this area (eg. next semester) will focus on designing a sensor that can be integrated into the knee attachment itself or into the base of the foot, allowing use by an amputee.
Motor Encoder - Joint Angle Equivalence
Some trigonometry needs to be done to establish the equivalence between motor-top encoder reading and joint angle. This calculation also gives the relationship between force in the actuator and torque on the joint. I have tried two different methods so far, both giving incorrect results. The first uses law of cosines and exact dimensions of the leg to determine the angles of the triangle that the actuator makes with the shank. The second method assumes that the actuator angle with the shank does not change by much, which is a valid assumption because the angle does not vary by more than several degrees. Therefore, the relative actuator deflection can just be treated like the leg of a right triangle where the hypotenuse is the actuator lever arm. Therefore, the relative deflection is just sin(angle) * lever arm length. In the worst case, we will just linearly interpolate between the low and high values of the joint angle and spring deflection. This is also a valid assumption because of the small-angle approximation to the sine function.
Challenges
FSR Swing/Stance Transition Detection
We are trying to balance the number of sensors on the leg (and associated concerns about robustness, wiring, power) with the computational complexity of detecting transition events. At first, Robin developed an accurate, but computationally complex method for detecting the transitions using only the ankle linear potentiometer. However, we need this algorithm to run in real time with a loop speed of 0.5-1kHz. Therefore, we explored other options, and found that adding a FSR to the knee pad of the iWalk gives a good balance of complexity and performance.
Motor Encoder - Joint Angle Equivalence
This calculation is still causing us problems. I haven't been able to figure out where the error is coming from, and so I keep picking simpler and simpler versions of the calculation in order to debug it. One problem is that I'm not familiar enough with LabView yet to be able to debug quickly. However, in the end we can just use linear interpolation and not suffer too much in performance if we can't get a higher-fidelity approximation to work.