I need to do a few attempts with the bobbin because the clearance was not sufficient.
At this point, the components / general steps I have isolated include:
The auto-calibration involves figuring out at which position each axis is. One part of it can be done by the encoder if it is active (and homed) while the user connects the cable to the end-effector plate. It means allowing the stepper to move freely while the encoder is on and records the displacement (possibly with some minimal holding torque).
I can imagine the encoder in two states: (1) fixed positioning (from driver / board) with closed loop correction, and (2) free positioning (user can move it with minimal holding torque) while the encoder records the position but does not correct it. The state could be toggled with a switch on the hook.
Full positioning requires an extra information to be provided, either through accelerometers, or torque / tension sensors to fully determine the position at an instantaneous time point. Another strategy would be to use multiple calibration points to fully determine the system, but this would make it less user-friendly.
The slip ring is an important part if any signal is transmitted through the cables to a board near the stepper motor. It is meant to transfer signals from an element that is spinning (e.g. the cable around the bobbin) to a stationary component that is not (e.g. the stepper motor board). For example, it was used in the 3D printer for Interactive Electromagnetic Devices.
I winding the electric wire around the failed bobbin and discovered that although it would fit (but barely), the multiple layers end up creating lots of elastic energy that is not welcome for the system. I will go with fishing lines that do not stretch, are very strong and are much lighter and smaller.
I printed the bobbin with clearances of 1/128 and 1/256 inches, and both seem to work pretty well. The real test will be when these are loaded.
I had lots of discussions with my colleagues in my lab about what types of sensors I should be using for the calibration. This is more complicated than I thought and I didn't figure out an easy setup that would fully determine the system easily yet.
The initial (0,0,0) position would be defined by the user setting up the machine (and possibly clicking on a button to trigger the calibration procedure). At that point, we have three pieces of data (provided by the stepper encoders): the distance from (0,0,0) to the three winches. The system is not fully defined, we need more constraints. Total: 9DoFs if we simplify the winch models and assume single point of exit without caring about the winch and cable orientations.
If we use step movements for each axis, we can measure some of the changes of the system and potentially infer the remaining DoFs. Unfortunately, getting the relative position from (0,0,0) directly does not seem trivial. Can we do it indirectly with sensors? Hopefully yes.
Given lots of thinking and not many good outcomes, I decided to start creating a simulation environment for cable machine using Three.js. This may help get a clearer idea by looking at the system's dynamics.
Created page project for sound-based positioning. The idea is to use sound to do fine localization of components within a machine, which would be very useful to automate the calibration of a cable-driven machine.
I read about Euclidean Distance Matrices or how to precisely find the relative position of nodes when we know their pairwise distances. This means that the project is basically focusing on figuring out the distance between two similar nodes using sound (similar to sonars, except these usually work with echo waves). Piezo-electric components (such as that one) seem to be able to emit and sense sound, but are not necessarily very efficient. I'll be checking these to figure out if it's any use for distance measurement at multiple meters apart. A friend of mine suggested to not have co-located emitters and receivers, but instead use dedicated chips that would have much better properties. He recommended usound but these are in progress, so not for today. He also suggested looking at the InvenSense chips from TDK.
I'll be getting piezo-element samples from Amazon and testing them soon. If they work, perfect. Otherwise, we'll go with distinct emitters and receivers that are located nearby. In that case, we may want the emitter to have some directionality (to be more efficient at transferring sound).
I tested the basic piezo element from Amazon and although they can generate reasonable amount of sound, their receiving sensitivity is much lower. They can easily hear contact vibration such as knocks but I could not get any reading from external sounds that would not be in direct contact with the contact surface. This means I'll probably go with a two-components approach with a specialized mini speaker located near a mini sound microphone.
I will need to figure out the exact emission power to find a reasonable pair speaker/microphone with similar frequency of maximum efficiency.