Fighting with computers

I was recently invited by Pablo Murillo to give a talk at Zaragoza Maker Show  and I wanted [among other things] to present a hands-on project to the audience, outlining the process I followed to get it done. I was lucky my friend and fellow "Arduinist" Colin Dooley gave me away a 15-led addressable RGB stripe a while ago. Unfortunately, the Cylon effect (aka Lasrson scanner for those old enough) was already taken as one example from FastLED library, so I had to do something else. I have chosen the title "Beyond Blink" for my talk , so it would be nice to get something that, while blinking, performed a more useful work. So what I decided was to use the 15-led stripe as some sort of presentations clock, that will help the speaker to know the time elapsed, a new led lit each minute, while of them is blinking each second. But as many talks are longer than 15 minutes, I repeated the same pattern with changing colours for each next quarter. Red being the last colo

Since I published my DC motor control project on youmagine I have got some feedback from users with 2000 PPR (pulses per revolution) encoders or more where they end up having trouble above 3000 RPM. The reason is that the poor Arduino cannot process the interrupts fast enough and the system becomes unreliably. While optical encoders are available quite cheaply, some of the magnetic sensors from AMS are very competitive and offer very good accuracy (from 12 to 16 bits). One interesting model (due to its low price) is the AS5600, that provides a 12bit angle measurement for less than $2. Measurement data is read by means of an I2C serial bus and needs no interrupts. Hopefully those having trouble with interrupts can switch to this type of sensor, but model AS5600 is most likely a bad choice as it is intended to replace manual knobs in hi-fi equipment and it will not work at high RPMs (in fact the manufacturer does not provide the max RPM at all). But for position control applicati

For my CAM project I was using a 3D offset of the parts to compensate for the tool diameter. But i have recently have incorporated a new feature so 3D assemblies of blocks can be represented in 3D. For the automatic assembly (courtesy of Carlos Sánchez) I cannot use the offset surfaces but I have to use the original meshes. One way of machining a 3D mesh is dropcutter algorithm, that in a nutshell works by modeling the milling bit and setting the z-depth at each XY location so the model is barely touched by the tool. As meshes are made of triangles, each feature of them is tested for contact: edges, facets and vertices. The feature with the highest z-depth value will set it for that particular location. I have found a lot of insight and useful information in Anders Wallin blog . Though my initial approach was to adapt his monocam's C# code to Java, I ended up with a buggy result. Anders released later a C++ library, opencamlib, that is most likely a much improved version,

I have just noticed there is a new version of Autodesk's Meshmixer software available for Linux but this time is no longer running over wine but it is compiled to run in Ubuntu 14.04 64bit. And the first tests suggest it works reliably (only crashed once when searching on the online 123D library). It is a great program and it is free to use so I find myself using it from time to time. There are quite interesting but unexpected uses . It is been a while since I last checked, so do not bash me if this is not new news for you, I now it was released first around March 2015, but I am a bit slow :-)