Good plan. And if that doesn't do it, low profile bolts could be used to gain even more space. The forces on the wheels are pretty tiny.
Another small update:
Added some code to work with the scanner. And some hardware changes:
Counterweight is working. Motors can be turned off, no more whining noise:
All it took were some standard nuts:
I mounted the (bulky) arduino box:
And used a banana plug thingy instead of my protoboard to get power to the CNC shield:
It's starting to clean up nicely (for a prototype).
Added some code to work with the scanner. And some hardware changes:
Counterweight is working. Motors can be turned off, no more whining noise:
All it took were some standard nuts:
I mounted the (bulky) arduino box:
And used a banana plug thingy instead of my protoboard to get power to the CNC shield:
It's starting to clean up nicely (for a prototype).
I added a counter weight to the scanner. Untill now, the speaker had been acting as the counter weight.
Does anyone have any ideas about the servo and microphone cables? I would like to keep them under control and not drag them around (e.g. over the table). Depending on the position of them microphone I could have 1.4 meter of microphone cable hanging free/lying around.
Does anyone have any ideas about the servo and microphone cables? I would like to keep them under control and not drag them around (e.g. over the table). Depending on the position of them microphone I could have 1.4 meter of microphone cable hanging free/lying around.
In the CNC world something like this is typical. They are designed for linear motion, though, so likely only a partial solution.
Maybe spiral cable wrap would be helpful as well.
Few
Maybe spiral cable wrap would be helpful as well.
Few
Of course you could do that. I would need (to buy) another microphone, microphone cable, audio interface, profiles, stepper motors, ...
Also, how do I say this... The position of a single mic is easily known relative to its starting position. A second mic would need its position known relative to the first one or one needs an algorithm to deduce that from measurements.
So using a piece of iron as a counterweight was a bit easier.
Also, how do I say this... The position of a single mic is easily known relative to its starting position. A second mic would need its position known relative to the first one or one needs an algorithm to deduce that from measurements.
So using a piece of iron as a counterweight was a bit easier.
I don't follow.
The second mic is just the same + 180 degrees (+ additional error correction at first setup).
Since both are connected to the same arm (beam) the relative error is basically non existent.
So it's actually quite simple.
Update:
I have only two USB ports on my laptop. I need 3 (tic, arduino & soundinterface) for the NFS. I tried some USB hubs, but the devices are not visible/working behind the hub. With a larged powered USB hub (the new 'docking station' kind) I even got sparks, so I quickly disconnected that before the magic smoke was released.
A raspberry pi has always been in the back of my mind. A small dedicated computer with remote access appealled to me. The lack of USB ports on my laptop was the droplet that made the bucket overflow. I bought a Raspberry Pi 5 (4Gb RAM, metal case). Now I have to reinvent the wheel a bit. How do I connect to the audio interface? How do I connect to the arduino on the serial port? How do I get MATAA to work under linux? ...? Besides that, Octave is great for mathematical operations, but simple control (flow) is not its (my?) strength. So I'm contemplating python. It looks like it has a nice grbl package that I could use.
So after two steps forward (and maybe even more), I'm taking one step back at the moment.
I have only two USB ports on my laptop. I need 3 (tic, arduino & soundinterface) for the NFS. I tried some USB hubs, but the devices are not visible/working behind the hub. With a larged powered USB hub (the new 'docking station' kind) I even got sparks, so I quickly disconnected that before the magic smoke was released.
A raspberry pi has always been in the back of my mind. A small dedicated computer with remote access appealled to me. The lack of USB ports on my laptop was the droplet that made the bucket overflow. I bought a Raspberry Pi 5 (4Gb RAM, metal case). Now I have to reinvent the wheel a bit. How do I connect to the audio interface? How do I connect to the arduino on the serial port? How do I get MATAA to work under linux? ...? Besides that, Octave is great for mathematical operations, but simple control (flow) is not its (my?) strength. So I'm contemplating python. It looks like it has a nice grbl package that I could use.
So after two steps forward (and maybe even more), I'm taking one step back at the moment.
Ugh...very familiar territory! It so often seems that little logistical glitches manage to disrupt grand plans. That said, I share your enthusiasm for something like a Raspberry Pi solution. They're cheap enough so that it could provide an affordable way to bridge the Windows/Linux/Mac divide, and if measurements are going to take hours, I'd rather not tie up my laptop while I wait for the data to crunch. So maybe this is just a helpful hint from the audio gods?
I also like the Python approach. I've spent WAY more time with Matlab(/Octave) than Python, but Python is definitely a more general purpose language; I think it would be a good fit for this application. NTK even started with Python before porting things over to Matlab-ese.
Few
I also like the Python approach. I've spent WAY more time with Matlab(/Octave) than Python, but Python is definitely a more general purpose language; I think it would be a good fit for this application. NTK even started with Python before porting things over to Matlab-ese.
Few
you should use an usb isolator to prevent groundloops, like this
https://nl.aliexpress.com/item/1005004366571248.html
https://nl.aliexpress.com/item/1005004366571248.html
It occurs to me that I should separate data acquisition from data analysis. Has anyone seen information on how much time is required for each of those steps? I could imagine using a dedicated Raspberry Pi to move the mic, make the measurements, and record the results, and then using a faster computer to do the analysis. But without having any sense of the pie chart describing the time typically required for each step, I don't know if that "imagining" makes any sense. I'm hoping someone else is better informed.
Few
Few
There are quite a few measurements required to get a proper point cloud. I am guessing that a lowly Pi will rapidly run out of RAM. So a division of labour would seem the most intelligent way to do it. As Tom mentioned getting an audio interface to play nicely with a Pi is also another not so easily done request.