Lab 3 - Haptic Environments

The virtual spring was the easiest of the virtual environments to implement. You could feel the variation of the force as you rotated the armature. With a dead-zone, the chatter visible in the video below was removed.

Implementation of the virtual wall was second easiest. When the armature was pressed against limits set on either side of the equilibrium function, the motor would turn on to resist the motor. This environment was somewhat unsatisfying, though, since the resistance of the motor was not enough to prevent moving the armature past the wall. Increasing the force that the motor could apply caused the armature to bounce back and forth between the two walls on either side of equilibrium. Addition of a damper inside the wall might correct this behavior. A delay of 0.05 s had to be added to the control loop for the virtual damper to slow down the sampling rate (and provide a rough time value between samples to use for the derivative). Damping torque could be felt to increase and decrease with the speed of rotation of the damper.

The virtual spring-mass system was the most difficult to implement, mainly because it was difficult to tell whether it was behaving correctly or not (partly because it had the largest number of adjustable parameters). Eventually, we were able to tune the system so that we could move the mass backward and forward between the two endpoints of the motor's workspace. When given an impulse, the mass would oscillate between the two endpoints. This matched expectations, since no damping was accounted for in the spring-mass system. A spring-mass system with no damping will oscillate forever.

The iTouch motor, in its current configuration, has problems with chatter. The position sensor has very limited resolution (on the order of 1-2 degrees) because of the very small variation in voltage from the Hall-effect sensor and the resolution of the Arduino's analog-to-digital converter (1024 steps between 0 and 5V). Because of the limited resolution, the motor would hunt back and forth around equilibrium points (since the position never registered as exactly at equilibrium). To fix this problem, one solution developed was to add a dead zone around the equilibrium point. However, this introduces positional inaccuracy about the equilibrium point equal to the width of the dead-zone (since the armature is free to move within that range).

Another improvement to this motor would be to increase the resolution of the position sensor by amplifying the signal from the Hall effect sensor, increasing the range over which the signal would vary as position varied. This would allow more of the analog-to-digital converter's range to be used (closer to 1000 different values over 36 degrees, rather than the 20 values over 36 degrees we currently get).

Some amplification of the hall-effect sensor input was achieved by changing the orientation of the magnets so that repulsive sides faced each other. This required us to hot-glue those two magnets in place. This roughly doubled the range of values from the hall-effect sensor (after analog-to-digital conversion).

A line was added to the virtual spring program to cause it to output HIGH on a digital I/O line when the spring was above a certain angle on either side of the equilibrium position. A LabView script was written to play a tone whenever the input was HIGH.

Though there was resistance to moving the motor armature (you had to apply force to play a note), the instrument was not very satisfying. The resistance of the controller would mean more if it controlled either pitch or amplitude. This will be easier to realize with the Arduino connected directly to the midi interface, because the position value from the hall-effect sensor can be used to control amplitude, and the input from a potentiometer can be used to control the byte used to select pitch.