PCL library with Kinect under OSX 10.11

This last week, I dug up my trustworthy Kinect for a spin. I’ve been wanting to mess around with the PCL (Point Clouds) library for some time, so I decided to give it a shot.

Installation on OSX using Homebrew is fairly straigthforward, as shown in their documentation. However, I want to make sure that I have support for the Kinect (the Xbox 360 model).

Side note on Kinect support: To get data off of your Kinect, you can use the OpenNI library (which handles Kinect “1”).  OpenNI2 does exist, but it handles only the Kinect “2” and Occipital’s Structure Sensor. I’ll be using OpenNI here, because it’s supported directly by PCL. However, for standalone applications, I’d greatly recommend libfreenect (also available through Homebrew), which is fast, lightweight, and very easy to use.

So, we’ll be using Homebrew to get the following libraries: Boost, Flann, Qt4, GLEW, VTK and last but not least, OpenNI (1 and 2, just for argument’s sakes).  Run:

brew update
brew install boost flann qt glew vtk openni openni2

Grab a coffee, ’cause this will take some time. Now, to install PCL, you may want to check the available options (brew options pcl), then install it with at least the following settings:

brew install pcl --with-openni --with-openni2

Great, if nothing intensely wrong happened midway, you should be golden. Now, at that point I was eager to get some Kinect-demo up an running, which led me to PCL’s openni-grabber page (go ahead, visit the page). They are kind enough to supply the C++ file and a CMakeLists.txt to compile it. It compiled fine, but crashed hard every time I tried to use it, spitting the message:

Assertion failure in +[NSUndoManager _endTopLevelGroupings], /Library/Caches/com.apple.xbs/Sources/Foundation/Foundation-1256.1/Misc.subproj/NSUndoManager.m:359
2016-01-06 12:50:51.779 openni_grabber[42988:7013866] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.

Now, I don’t know if this happens under other platforms. After wasting some days struggling with this, I realized what the heck was going on. Let’s take a look at the non-working supplied code. In the header section, we see:

It uses the PCL’s Cloud Viewer, which has been long deprecated (meaning that this example is very out-of-date). Secondly, we see that the grabber’s functionality is based on a callback, defined here:

The cloud_cb_ callback function is called every time a new data packet arrives from the Kinect. This is fine, but the showCloud() command updates the display of the point cloud from within the callback, witch is what’s creating our "...is only safe to invoke on the main thread..." error. To fix that, the callback should only update the cloud’s data, while the cloud itself must be displayed with a call placed on the main thread. The fixed code I came up with looks like this:

Now, the callback cloud_cb_ only updates the cloud’s data, not touching the UI. The drawing happens in a loop inside the SimpleOpenNIViewer::run(). Since the callback and the loop are handling the same data set asynchronously, I’ve added a mutex around the critical sections to avoid any issues (the nice CPP wrapper  stolen from libfreenect’s examples, thanks!). To compile it, the following CMakeLists.txt should do the trick:

The results are not astounding: the RGB data is slightly out of place with the depth data, but I believe this is a problem internal to PCL, since my Kinect is properly calibrated. To use only the depth data in the code above, simply replace all instances of pcl::PointXYZRGBA with pcl::PointXYZ.

’til next time!

Using CMake and Qt Creator 5.5.1

Well, things have been dead around here. So, to keep things running, I’ve decided to post some less important content, mostly as notes-to-self (ya know, when you spend the weekend trying to get something to work, only to forget how you did it a month later). To avoid purging hard earned pseudo-knowledge, I’ll try to create the habit to write it down here.

So, for my first post in this (otherwise endless) series: how to use CMake with and IDE.

CMake is a nice cross-platform utility that generates Makefiles for C/C++ applications. It will automatically search for include files, libraries, generate configurable source code, etc, etc. A simple CMakeLists.txt file looks like this:

This neatly handles dependencies and configurations in a much more platform-independent way. Nice tutorials on CMake are available here.

As the kind of guy that can’t cope with VI(M) (sorry, I’m just to dumb for it), I generally gravitate towards programming-with-IDEs. I began searching for an IDE that had decent CMake integration. “Eclipse can handle it, for sure”, I thought. Nope. I was disappointed to find out that Eclipse not only lacks native CMake support, but there seems to be no plugins that handle it. CMakeBuilder was widely referenced online, but it seems that it is no longer available (using Eclipse to  query www.cmakebuilder.com/update/ yields no results).

Qt Creator ended up being the go-to solution. AFAIK, is the only well supported cross-platform GUI that handles CMake natively. Suppose we have the test_project folder, with a main.cpp and the CMakeLists.txt I’ve shown above. Use Qt Creator to open a file or project:

open_file_qt_creatorOpen the CMakeLists.txt. You’ll be prompted to run CMake (which you can skip, if you wish). After running the wizard, the left project pane will look something like this:


Neither the project name nor source files will be displayed, which is a bummer. This seems to be an issue with Qt Creator >5.0. There’s an fairly easy fix. Add the aux_source_directory command to your CMakeLists.txt:

Run Qt’s import wizard now, and the result will be as expected: project name will be featured, together with listed source files.



Great. Hit ⌘B and watch the build magic happen.

’til next time.

Biohand: first short video

I submitted my biohand project as an entry to the 2015 Hackaday Prize. Cool. So, after spending a long month in a [21st-century] cave while writing my thesis (about the biohand), I discovered on August 16th that I needed to post a descriptive video of my entry until August 17th. Today.


Here, have this sexy pic of the prototype, for no reason.

So yea, biohand‘s main control board survived the smoke test and all, but it’s not finished. So I drove a couple of biohand‘s motors and the thumb’s servo with an ever-trustworthy Arduino, just to show it doing SOMETHING.

There you go:

’til next time.


Biohand boards, fresh from the boardhouse

This page has been gathering some dust now, but this will change in the next weeks.

I’ve been working on a new project, the biohand. It’s a low-cost 3D-printed hand prosthesis, that aims at offering technical qualities similar to multi-thousand dollar devices. More details shall come in another post.

For now, I’m just willing to share the nice fact that the first iteration of the biohand main control boards (a.k.a. the BIOHAND_BOARD_V1) arrived from the boardhouse.

Biohand bare boards

As soon as I finish soldering one of them and it survives the smoke test (or perhaps doesn’t), I’ll post further results and schematics.

’til next time.


It’s said that no man is without sin, and neither am I. In an act of brilliance, I’ve managed to swap two VDD/VSS pairs from the STM32 while designing the board. While I didn’t burn a thing, I did cost me over 24h to figure out what was happening and to solder some workaround-wiring. In the end, the I got the ARM running a simple blink program (pic below). YEY!

Minimal test of the board. Disregard the workaround-y bond wires.

Minimal test of the board (Blinking LED, YEY!). Disregard the workaround-y bond wires.

Now it’s time to keep on soldering the remaining components (hoping not to find other mistakes like that). I’ll upload corrected gerbers once everything works without bursting into flames.

’til next time.

Using Marlin’s auto leveling for PCB milling

As I’ve stated earlier, I designed my 3D Printer with light milling operations in mind. One of the activities I intended to tackle was the subtle art of  PCB milling. It seems pretty straightforward at first: get a new/raw PCB (printed circuit board), use something like FlatCAM to generate G-Code from your Gerber files, get yourself a good milling bit and you’re done. While this is true for coarser trace widths and packages, you’ll soon run into trouble when milling something as fine pitched as an HSSOP-28 (like I’m doing for this little fella). Where 3D printing is fairly robust to submilimeter bed misalignments, milling widths of under 14mils is an unforgiving process: cut depth variations of even 0.01mm can ruin a trace and a board. Naturally, trying to mechanically level the board is the first step. However, larger boards may be somewhat bent, which can be hard to compensate (or flatten).

I’m currently using Marlin as my printer’s firmware. After watching the advances on automated bed leveling (or tramming, as some call it), I figured I could profit from such feature to accurately mill PCBs. However, after some tests, I noticed that only a 3-point leveling wasn’t enough. While the plane of the PCB is identified, curvatures or slightly bent PCBs can’t be properly compensated. Luckily for me, the masterminds behind Marlin are now implementing a grid-based leveling, that does just what I needed. It took me a couple hours and some minor tweaks to the Marlin firmware to get it running. First, checkout the result:

To get all running, I started by printing some mounting clamps for my Dremel’s flex shaft. Carrying the Dremel itself was an option, but the flex shaft is much lighter and equally stiff.

Setup for PCB milling. Quite... ahm... Messy.

Setup for PCB milling. Quite… ahm… Messy.

Next step was to convert my Z endstop into a “dual crocodile clip” configuration, as in the picture:

Crocodile clips on the board and on the tool. When both touch, bingo: Z endstop was hit.

Crocodile clips on the board and on the tool. When both touch, bingo: Z endstop was hit.

This allows for an accurate on-the-spot Z endstop. After that, on the software side. First, in Marlin’s Configuration.h, I enabled and configured the leveling. Around line 407:

Another important thing to change: since the “extruder” (the milling tool) and the probe are the same, I also changed, in Configuration.h, line 457:

Last change. Since you want to mill a PCB, you usually will be cutting in the negative Z space. This means the tooltip has to be able to go to, for example, Z=-1. This won’t happen by default, because the printer “thinks” there is no space below Z=0 (and usually, there isn’t). So, in Configuration.h, give the printer some room in the -Z direction. Be careful! This modification can lead to several headaches once you forget it is in place.

This should suffice. Essentially, we’re tricking Marling into probing only “inside” the size of the board. The downside (for now) is having to change and recompile this for different board sizes. By default, however, Marlin needs to home the X and Y axis before allowing a G29 (auto-leveling) to be performed. Even though this makes sense in the grand-scheme of things, it was a nuisance in my case. I wanted to be able to place the probe in any arbitrary point on the bed/PCB and start the leveling. For that, all I had to do was remove the “homing verification” on Marlin_main.cpp:

Done! Now I can manually carry the mill/tool/extruder/probe to the desired origin (where I want the board to be milled). There, I just need to issue the following commands:

After the process ends, your preferred GUI/interface will spit out the surface’s correction matrix calculated by Marlin:

Pronterface, showing the calibraton results on the right.

Pronterface, showing the calibraton results on the right.

That’s it. Now just print normally – the compensations for the bed’s irregularities will happen automatically on the background. The calibration data is lost at each reboot (though an EEPROM save can be enabled).

’til next time.

Chronicles of my 3D printer, part 2: the electrical Pandora’s Box

Having finished the mechanical assembly of my printer, it was time to assemble the electronics to get everything moving.

As I stated in the previous post, my intention to build a large-volume printer/mill made me choose NEMA 23 stepper motors for the X and Y axis. Larger motors would be capable of handling greater forces and more aggressive acceleration profiles, that regular NEMA 17s would not. After some research, I purchased 2 Applied Motion’s HT23-601. With a holding torque a little below the 2N.m, I was (and still am) pretty sure that those motors would be overkill (which isn’t a bad thing). For the Z axis I got 2 Applied Motion’s HT17-275 – good quality NEMA 17s that would do the job.

The thing with the larger NEMA 23s is their current requirements. The maximum current for the HT23’s bipolar parallel arrangement is rated around the 4.3A. Regular 3D printer stepper drivers, such as the A498 or the DRV8825 handle up to 2.2A (with active cooling!), so they are way off the range. Also, keeping the ICs operating constantly at their max is guaranteed to greatly reduce their lifespan. Operating the NEMA 23s on lower currents also wasn’t an option, simply because I wouldn’t be able to make the most out of them. At that point, I thought I’d have to get industrial stepper drives that would leave my pocket echoing. Luckily enough, Google (oh, my dear) pointed me to the Powerlolu, a 10A stepper drive that still falls in the $50 range.

After getting the Powerlolus and my RAMPS 1.4 (the printer’s control board), the wiring-fun started. I quickly noticed that, even for small test setups, the amount of wires hanging all over the place was increasing rapidly. Besides being annoying, messy wiring is the best spice for cooking your components. In order to prevent that, I mounted everything in a proper enclosure box, and tried to keep the wires, buses and connectors as neatly organized as possible. The result, after dozens of boring hours, was worth it:


Main electronics box. Bottom, the 12V/33A supply. Middle/Right: Stack of 3 Powerlolus. Top/Left: RAMPS.

For the record, there goes a somewhat simplified wiring diagram of the box’ contents. I’m using a 12V/33A power supply, so I added a 5A circuit breaker on the mains’ power input to avoid burning down my house if anything went wrong.


Simplified wiring diagram of the printer’s electronics. Some wires were omitted or labeled to keep the drawing understandable.


As the picture below displays, the components (motors, hot end, heat-bed, etc.) are attached via connectors mounted on the side of the box. This makes the connection more robust to vibration and eventual pulls. For the stepper motors, I used 3 4-pin circular connectors (the four, from the bottom). They resemble XLR connectors with extra pins and screw caps, and I’m not really sure how they’re correctly called. The heat-bed also uses such connector, in it’s 2-pin version. Such connectors handle up to 5A per pin. Though they can’t support the Powerlolu’s full 10A, they were (sadly) the most cost-effective solution I found. The bed’s thermistor and the endstops are connected to the RAMPS via P2 audio jacks. Lastly, a DB-25 plug handles all the wiring for the extruder and hot-end: stepper motor wiring, hot-end cartridge, thermistor and fans.

Connectors for the printer's parts.

Connectors for the printer’s parts.

Finishing up, a sideways view of the closed box, showing the USB plug, a fan, the power switch and the mains’ power input.

Everything has two sides.

Ready to rumble.

’til next time.

Printing something useful, for a change

After lots of bad prints, random parts, new extruders, a couple of bears and a Darth Vader, it was about time to print something with at least a bit of practical use. A bit. I’ll let you be the judge of that:


The hook... Holder... Thingy.

The hook… Holder… Thingy.

The making (and usage!)


The sad part is that I didn’t come up with that idea on my own. But then again, that’s what the internet is for. I guess.

’til next time.

Chronicles of my 3D printer

So, just a little throwback. I’ve always wanted to build a 3D printer (or any CNC machine, for that matter) on my own. Around two years ago, I’ve decided to take that desire seriously, and started doing some research on designs for 3D Printers and CNC mills. After some googlin’ I set myself with goals of building a machine that:

  1. Had a large working volume (around 35 x 35 x 30 cm)
  2. Enabled fast prints (80mm/s and faster)
  3. Was cheap-ish (I live in Brazil, and getting proper mechanical/electrical components here is insanely expensive)
  4. Enabled both 3D printing and milling (at least of softer woods and plastics)

So, pretty much a godmode machine – what every engineer desires, but only unexperienced newbies strive for. The last point there is specially tricky. Milling and printing are very different activities, that shape machines in very different ways.

Milling usually requires more robust and rigid machines that can handle the high (read: tremendous) opposing forces applied on the end-effector (the cutting tool). Cutting speeds are relatively low, and depend on the material that’s being milled. Arrangements with a moving portal carrying the Z gantry are quite common, since they allow the workpiece to remain stationary, and provide a stable frame. Such configuration, on the other hand, means that A LOT of mass has to be constantly moved around: the motors for the Y and Z axis, the portal, all mechanical components attached, and so on – which constraints aggressive acceleration profiles. Partially because of that, CNC mills are normally leadscrew driven. Most of such leadscrews present pitches in the 2 to 5 mm range, allowing increased torque transmission and movement precision, but reducing the overall speeds. From the beginning of this project, I knew that I would be working with a 12V power supply and NEMA 23 steppers – the most cost-effective solution available to me. From the graph below it’s easy to see that, even with such a 5mm pitch leadscrew, achieving speeds of around 80-100mm/s on that configuration is hard/impossible. Leadscrews were a no-go.

Typical NEMA 23 stepper motor (torque vs. rotation speed)

Typical NEMA 23 stepper motor (torque vs. rotation speed)

3D Printing behaves quite differently. During a print, the end-effector (hot-end) moves practically freely, with almost no opposing forces whatsoever. Machines are built with a minimum rigidity to prevent vibration or backlash in the moving parts, but the goal usually is to reduce the inertia of the moving elements. Classical setups include floating Y axis, and are often built out of off-the-shelf screws and 3D printed parts, MDF sheets, etc. Timing belts are the default means for movement transmission, enabling higher speeds. This comes at the cost of reducing torque, precision and general frame rigidity – but good print qualities are generally attainable.  Note: I’m clearly addressing low-cost, desktop hobbyist printers in this description.

My faith on joining those two worlds in a single machine grew after I saw the Shapeoko 2 milling aluminum. The Shapeoko 2 is a desktop-ish CNC mill that is built out of many elements that figure on a regular 3D printer: NEMA 17 motors, GT2 belts, makerslides, and so on. With all that in mind, I started designing my machine. After a couple weeks, I came up with a design that made me happy:


Everything looks cooler raytraced.

Yeah, it ended up looking an awful lot like a Prusa i3 on steroids. But I took it as a good sign, that a lot of thinking took me to the same tested-and-proven design. Though I could’ve spared the time. And now the CoreXY looks darn interesting. Whatever. Anyway, I had no 3D printer available at the time, so I struggled to keep all the custom parts “laser-cuttable”.

After purchasing all the couplers, screws, belts, pulleys, aluminum profiles and other bits, I sent the designs to be laser cut on 3mm aluminum sheets.  All parts came in; the build started.

Starting to build. And to complain.

Starting to build. And to complain.

As the pic above shows, I had originally chosen a different arrangement for the Z axis: each screw was coplanar to only one linear rail (instead of being coplanar to both simultaneously). Soon enough I saw that the smallest wobble of the screw would cause the whole gantry to wobble along, rendering even the coarsest prints impossible. Couple more days in front of SolidWorks and the mistake was fixed [the rendering above is the fixed version]. There, no one saw it. Move along.

A couple parts for the fix had to be recut. They came in, and the result soon popped out:


Assembled printer. Disregard the extruder, that one never worked.

Everything looked OK. Rigid enough for me. Next up; assembling the electronics. I’ll leave that for a next post. I’ll also put the CAD files up anytime soon.

Ah, I’ve obviously ‘Instagramed’ it. “The experience is not complete if you don’t post it on Instagram”, said someone once.

From concept to finish (almost). 🙂

Uma foto publicada por Martin Vincent Bloedorn (@martinbloedorn) em

’til next time.