DIY 3D Speaker Scanner - the Mathematics and Everything Else

[Few]

Thanks for the motor suggestion. I decided to order some motors and drivers to get myself up and going even if my choices turn out not to be ideal. Shipping can be slow these days so I just took the plunge. I’ll have other stepper needs over time so if the ones I bought are ill suited for this task, I’ll check out the Silent Stepstick—sounds like a good fit.

I found some cheap ceramic line rings intended as replacements in fishing rod guides; I plan to use them to line the guide holes for the six cables.

I was thinking that using a large diameter drum/spool would require fewer line wraps and minimize change in diameter as line is spooled on and off. It might be possible to eliminate line overlap entirely. Timing belts and pulleys between the stepper motor and spool could be used to regain the resolution lost by using a large diameter spool. I spent some time going down a rabbit hole on self-reversing threads used in level-winding mechanisms. Very cool, but there goes an hour I’ll never get back! A large diameter spool should be sufficient.

I’m completely ignorant of the g-code world, and won’t have time to become fluent in the near future, so I’ll likely use LabVIEW to take my first steps. It’ll make it easier (for me) to synchronize acoustic measurements and mic positioning. Real life will kick in before long so I’m hoping to take at least a few preliminary steps before my day-job intrudes.

Few

 

[bigjacko]

Very nice news @Few , I am too lazy to do anything. I don't have many knowledge about the automation and motor choices but I am willing to help anything if I can. Regarding the self reverse lines you mean lines have memory that can get back to original shape? I think you can use a wide spool and use the same winding mechanism used on fishing rods, the lines will get evenly distributed along the wide spool so less circumference change. But those things are expensive, we need to find cheaper ones or make them ourselves.

 

[NTK]

Idea on solving the overlapping wire in the wire spool problem:
Tape decks use capstan and pinch roller to precisely control the tape movement/speed. The rest of the wire can be taken up with an automatic retracting spool (just an idea, I know the products I linked to are too expensive for the job), or just attach a weight at the end and let the "excess" wire dangle. Alternatively, loop the wire over a roller a few times without any overlap, have the wire properly tensioned so that it doesn't slip when you rotate the roller.

If you positively want to know the position of the wire (to not worry abut motor slip), you can use a rotary encoder and a roller to sense its position. You can read quadrature encoder signals easily with an Arduino.

 

[Few]

Thanks bigjacko. The winding mechanism on fishing reels is precisely what I was referring to so we were thinking along the same line (no pun intended). On a level-winding baitcasting reel there is a self-reversing thread that rotates as the handle on the reel is cranked. That's what guides the line back and forth to lay the line smoothly on the reel. It was that ingenious self-reversing thread, and the line guide that it drives, that I was learning about. It’s such a cool mechanism that I was looking for an excuse to use one! But I don’t think it’s really necessary in this case, and it would complicate things unnecessarily.

I want to keep the length of the spool covered by line wraps fairly short, and avoid layers of line on the spool, so that the geometry doesn't throw off the relationship between spool rotation and length of line played out. If the line covered the entire length of the spool in this sketch, then the distance spanned between the spool and the line guide (plate with two holes through it) would change noticeably. Since I plan to try to use spool rotation as a measure of the length of line deployed I want to minimize those errors--that means the line wraps should come from a narrow range along the spool.

A back of the envelope calculation shows that 3.14 m of 20 lbs. test braided low-stretch fishing line (0.23 mm diameter) could be held in 40 wraps around a 25 mm diameter spool, and occupy 10 mm of spool length. That seems pretty practical, so I'll likely aim for somewhere between a 25 and 50 mm diameter spool to avoid finicky line wrapping.

 

[Few]

NTK: Once again, two posts passing through the ether! Sorry.

Thanks for the suggestions. I've considered a rotary encoder and capstan mechanism to track the line deployment and ultimately decided that I should get something simple going first, rather than aim for perfection that never sees the light of day. If I can put something together using just stepper motors and spools, and scan the mic around a reasonable measurement volume, I can measure how accurately and precisely it moves. If it's good'nuff for audio measurements then I can move on to the next steps knowing I can always go back and refine the motion later. If there's too much play in the simple mechanism then at least I'll have a real world problem to diagnose (skipped motor steps, unpredictable line wrapping, line stretch, etc.).

Few

 

[bigjacko]

Capstan looks complicated, I don't know how it works, wiki did not explain the detail mechanism. I think we can use other ways to counteract the circumference change of spool. One way is to set the software to spin slower at full spool and faster at low spool if we can calculate the length of each lines. Another way is get the spool slowly closer to Mic at low spool and slowly away at full spool. The slow movement can use high gear ratio to achieve.

 

[Few]

I doubt there's a ton of interest in the details but since I sketched up a rough plan for my NEMA-17 stepper motor and timing belt-driven spindle system, I thought I'd post it. Each of the three assemblies will be mounted to the ceiling upside down (relative to these sketches). Trying to keep it as simple as possible, I was able to find enough pre-built brackets and parts so that each motor and spindle system will just require that I make a couple of boards (probably baltic birch plywood) and attach the parts to them. The one exception is that I'll use 1" schedule 40 PVC pipe for the spindle (outside diameter is 33.4 mm). I'll turn down its outside diameter on a lathe to be sure all spindles have the same diameter, are truly round, and are concentric with their axles. Most of the rest will just require assembly if things go as hoped. Some parts have already shipped. I hope they arrive promptly because a bit of surgery in a couple weeks is going to interfere with my ability to use my left arm!

Few

 

[Few]

A bit of progress. I turned the spindles on a lathe so their diameters are matched within a few thousandths of an inch. I still need to construct and attach the structure supporting the pair of ceramic line guides for each system. That should go quicker than what I've finished so far. It's hard to believe that braided fishing line has a 50 lbs. breaking strength!

I've also made some headway on the LabVIEW programming but have more to do. So far I have a logarithmic (actually exponential) sine sweep generator as described by Farina, and I can tell the steppers to move with adjustable speed and acceleration/deceleration via USB. I still need to finish the geometry that goes from desired mic location to stepper motor steps, address the simultaneous audio input and output, add file saving.... And then I have to get all the aspects to work in synchrony. Since I'll be down to one usable arm in a couple of days I've been emphasizing the hardware aspect so I have things in a testable state.

Few

 

[somebodyelse]

Seeing the fishing line reminds me of restringing string pots.

 

[Few]

It's my last opportunity for a bit of two-handed hardware progress, so I was glad to be able to piece together a simple line guide system for all three motors/spindles. I decided to go with front-and-back ceramic line guides at each location. They're cheap, and it was easier than the over-engineered solution I had envisioned. I also made quite a bit of LabVIEW progress: I can now control all three steppers simultaneously via USB.

Few

 

[Few]

Can someone check my reasoning? The 3 stepper motors need to know how many steps to make, and in which direction, to place the mic at a target location.

1. Calibrate steppers A, B, and C by calculating and measuring the line each spool draws in per motor step.
2. Establish the xyz coordinates of each mic-facing line guide within the measuring space. (The guides facing the spool don't matter).
3. Use the 3D Pythagorean equation (below) to calculate the distance from each line guide to the desired mic location, expressed in the same coordinate system.
4. Use distances to calculate motor steps based on the calibration.

I've implemented this using 3-element vectors to streamline the code but I want to be sure I'm not doing something stupid by adopting this approach.

Few

 

[Few]

I just came across a series of relevant video presentations by Dr. Klippel himself. The link takes you to the first in the series, on YouTube.

Few

 

[dc655321]

Can someone check my reasoning? The 3 stepper motors need to know how many steps to make, and in which direction, to place the mic at a target location.

1. Calibrate steppers A, B, and C by calculating and measuring the line each spool draws in per motor step.
2. Establish the xyz coordinates of each mic-facing line guide within the measuring space. (The guides facing the spool don't matter).
3. Use the 3D Pythagorean equation (below) to calculate the distance from each line guide to the desired mic location, expressed in the same coordinate system.
4. Use distances to calculate motor steps based on the calibration.

I've implemented this using 3-element vectors to streamline the code but I want to be sure I'm not doing something stupid by adopting this approach.

Few

Seems like a reasonable start, IMO.
Have you fully worked out the forward and inverse kinematics?

Maybe I missed it, but I didn't see any accounting for backlash.
Then again, I also maybe missed what accuracy and precision requirements there may be...

 

[Few]

Thanks for the response. I think timing belt slop will be the main source of backlash, and that will be much smaller than other issues such as cable sag and stretch. That's a guess completely uninformed by experience! I'm actually expecting the spooling geometry, and its possible lack of reproducibility, to be the dominant source of errors in the simple implementation I'm starting with. My lathe's threading function needs repair or I would have grooved the spools to address those concerns.

 

[NTK]

Can someone check my reasoning? The 3 stepper motors need to know how many steps to make, and in which direction, to place the mic at a target location.

1. Calibrate steppers A, B, and C by calculating and measuring the line each spool draws in per motor step.
2. Establish the xyz coordinates of each mic-facing line guide within the measuring space. (The guides facing the spool don't matter).
3. Use the 3D Pythagorean equation (below) to calculate the distance from each line guide to the desired mic location, expressed in the same coordinate system.
4. Use distances to calculate motor steps based on the calibration.

I've implemented this using 3-element vectors to streamline the code but I want to be sure I'm not doing something stupid by adopting this approach.

Few

I believe your equations should work with the configuration you showed. The 3 wire lengths should uniquely define the mic location.

I played with Mathematica to get the inverse kinematics, and the expressions are pretty scary.
In the notebook, a is the length squared for wire 1 (with its base location at x1, y1, z1), b is the same for wire 2, and c is for wire 3. There are 2 set of solutions, as the mic location mirrored to the ceiling plane is also a mathematically valid solution.

 

[Few]

I'm not sure I want to manually enter that "simplified" expression! Holy cow!

 

[NTK]

If we take advantage of symmetry, the solution is much much simpler. Say, let the ceiling be z=0 — motor 1 at (0, -y1, 0); motor 2 at (0, +y1, 0); and motor 3 at (x3, 0, 0).

 

[Few]

I understand the difference between the definitions of the forward and reverse kinematics, but I don't have a clear sense of when each needs to be applied in practice. If I define a sequence of mic locations, that defines a corresponding sequence of cable lengths. If there is no feedback in the system, are both the forward and reverse equations required? I'm not an engineer so this is new territory for me.

 

[NTK]

The location of the mic is (x, y, z), but you can only control the lengths of the wires [in my equations, they are √(a), √(b), and √(c)]. The inverse kinematics is the solution to x, y, z given a, b, c and the other fixed parameters — in this case the locations of the motor bases. The formulas give the lengths of the wires you need when you want to place your mic at your target location.

The expressions given by Mathematica give x, y, and z as functions of a, b, c, x1, and y3.

x1 and y3 are fixed by the geometry of your setup. You can therefore control the wire lengths to position your mic to where you want it. The only difference between the first and second solutions from Mathematica is the sign of the z value (as the mirror image to the ceiling plane is also a valid solution geometrically, but not when you take gravity into account).

The calculations are purely geometry based. There is no feedback mechanism.

 

[Few]

Thanks, I knew my reference to feedback would cause confusion and I regretted including it as soon as I posted. I do realize it is all just geometry-based.

Another try: If I define a coordinate system and locate the motor assemblies within it, and then define a target mic location, I can calculate the 3 mic-motor distances (cable lengths). Why is that not the end of it?