Dr. Lawlor's Code, Robots, & Things

July 17, 2015

Flailing squid: 3D printer adhesion failure

Filed under: Random Thoughts — Dr. Lawlor @ 12:21 am

After starting an all-night print, I checked on my printer this morning to discover this many-tentacled glob of plastic, which apparently ate my print:

3D printer with orange plastic squirting in all directions from extruder.

3D printer with orange plastic squirting in all directions from extruder.

The problem here is the print head grabbed one corner of the print, and peeled it up.  With that corner sticking up as leverage, it incrementally peeled up the rest of the print, which stuck to the hot nozzle.  Since I’d left the printer running unattended (bad idea!), it KEPT PRINTING, with plastic squirting in all directions, resulting in an annoying-to-remove glob instead of a clean print.

The fix was to heat the hotend back up, and carefully clip away the gobs of excess plastic.  I had to be fairly careful, because the hotend’s heater and thermistor wires were buried in the goo.  I’ve wrapped them more securely in kapton tape for when this happens again.

This was with rubbery NinjaFlex, but I’ve had the same thing happen with ordinary ABS.  The trick is keeping an eye on the printer while it prints!

October 23, 2014

Monkeys, Typewriters, and Shakespeare

Filed under: Random Thoughts — Dr. Lawlor @ 6:39 pm

This Wednesday we did our first ACM student chapter coding challenge, verifying the infinite monkey theorem:

“A monkey pounding keys on a typewriter for an infinite time will eventually generate the complete works of Shakespeare.”

Clearly, we don’t have infinite time, but computers are faster than monkeys, and a virtual monkey doesn’t need bananas or people to clear the typewriter jams (and clean the cage).  Also, the crucial role of “monkey editor” needs to be automated.

Surprisingly, the default C++11 random number generator std::default_random_engine repeats every 4 billion keystrokes, which happens within only a few minutes.  std::mt19937 did not repeat during the duration of this test.

Shakespeare’s word length distribution is approximately:

0 19 101 588 1871 3295 4443 4963 4486 3486 2372 1584 860 476 219 92 39 15 9 7 0 1 0 1 0

That is, there are 0 words with 0 letters, 19 words with one letter (a, i, and other letters counting section titles and abbreviations), 101 two-letter words, etc.

The spacebar is bigger than the other keys, which is good because otherwise the median monkey-word has length 26.  By varying the size of the spacebar, we can set the average word length.

In typing 1.8 trillion keystrokes (on a quad-core machine over the course of a few days), billions of short words were generated, but the longest Shakespearean words generated were only 9 letters long:


This is all of them.  The full bard is 5 million characters long.  Monkeys, get crackin’!

October 13, 2014

Extrusion Multiplier: why your 3D printer won’t print

Filed under: 3D Printing — Dr. Lawlor @ 12:54 am

I’ve realized one single parameter, the extrusion rate multiplier, can control whether your 3D printer makes a brittle, stringy object (multiplier too low); a strong, watertight object (multiplier just right); or just jams up and fails halfway through the print (multiplier too high).  This multiplier is called different things in different slicers, but it’s basically the fudge factor that together with filament diameter determines how much plastic squirts out of the extruder during the print.

  • Multiplier too low: not enough plastic, and the top of the object is missing material (not watertight), the layers split apart easily (they’re not thick enough to bond together well), infill is detached from the object perimeter, and the part is overall undersize.  The printer prints, but often parts detach into a pile of spaghetti, and are too weak to use for anything.

    3D printer stringy brittle object

    Rate multiplier too low–not enough plastic for the layers to fuse into one solid part.  25mm / 1 inch diameter part.

  • Just the right amount of plastic, and the part looks great, with a very subtle “waffle” pattern on top.  The printer works reliably, and the part is strong and has correct dimensions.

    3D printer correct look

    Rate multiplier correct: just the right amount of plastic, part fuses correctly.

  • Multiplier too high: too much plastic, and the part will get wider and wider at each layer as excess material squirts out in all directions.  This results in ugly blobby parts that look like an over-iced cake, increases the size of parts and decreases the size of holes, and makes stringing worse as the head plows through excess plastic.  But eventually (1) excess material sticking up catches the extruder head and tears the part off the bed, or (2) the back pressure on the extruder gets too high and the filament shreds under the drive wheel.  Either way, the printer will continue thinking it’s printing happily while it cooks the filament in the hot end into carbonized char, sometimes clogging it up until you tear the hotend apart and clean out the nozzle.

    3D printer malfunction: too much plastic, lumpy ugly part

    Rate multiplier too high: excess plastic is squirting upward and in all directions. Surface is lumpy and ugly.

These three outcomes can be separated by a multiplier difference of only a few percent!

Here’s how to set the extrusion multiplier in your slicer.  You’ll need to re-slice the part to use the new value.

  • In MakerWare, “Create” a new custom filament profile, “Edit Profile”, under extrusion you’ll find “feedstockMultiplier”.
  • In Slic3r, “Filament” tab, “Extrusion Multiplier” (right below Filament Diameter).
  • In Skeinforge, “Craft”, “Dimension”, “Filament”, “Filament Packing Density (ratio)”.

For ABS, everybody recommends 0.85.  Most of my filament seems to work better around 0.88, but it depends on the color.  Filament that has absorbed humidity from the air boils and bubbles during printing, requiring a multiplier as low as 0.80.  PLA squishes less (see nophead describing the complexities of measuring extrusion rate), so needs a larger value, typically 0.95.  This is all assuming you’ve measured the filament diameter with digital calipers and entered it exactly.

With a correct rate multiplier, the print dimensions are correct.

With a correct rate multiplier, the print dimensions are correct.

3D printer lumpy output

With rate multiplier too high, the part is lumpy, holes are too small and the outside is too big.

There are several complexities here:

  • The amount of plastic needed for the first few layers depends almost completely on your platform height and levelness, not on the feed multiplier.  But the effect of not enough plastic (gaps, poor adhesion) and too much plastic (extra squirting out, extruder problems) are the same.
  • If you print at less than 100% infill, you’ve got space for any extra material to go, so you might be able to bump up the multiplier a few percent without any problems.  I usually use 100% infill, because I want stronger parts, so I have no wiggle room!
  • If you use a big layer height, like 0.3mm or bigger, the multiplier isn’t as crucial because there’s lots of space for extra filament to spread into.  At small layer heights, like 0.2 and especially 0.1mm, the multiplier needs to be perfect.
  • If the part curls at all, the corners pushing up acts like the multiplier is too high.  You can compensate somewhat by knocking a few percent off the multiplier, although you may lose watertightness in flat areas.
  • If the filament diameter changes through the spool (cheap eBay filament, I’m looking at you!), one value won’t be perfect everywhere.  For cheap filament I set the multiplier artificially low by a few percent, and ignore the lack of watertightness.

When people show amazing prints from a “tuned” printer, one of the things they tune is the rate multiplier.  Try it!

August 20, 2014

Setting up a HTTPS server via Apache mod_ssl: start to finish

Filed under: Linux, Servers, Sysadmin — Dr. Lawlor @ 1:42 am

If you’re like me, you’re already running a Linux web server.  It uses port 80 by default, which sends everything unencrypted across the network.  This is a bad idea, because anybody watching your users’ network traffic can see everything sent in either direction.  So you want to use HTTPS, which runs over TCP port 443.  Here’s how to set it up!


August 18, 2014

UAF Eduroam setup in Linux

Filed under: Linux — Dr. Lawlor @ 5:23 pm

Eduroam provides simple, no-login roaming wifi at a bunch of higher educational institutions.  It’s an IEEE 802.1X authentication setup, where you set up credentials at your home institution, and they can be used worldwide.

First go to https://nah.alaska.edu/eduroam/, and log in with your UA credentials (same as blackboard, UAOnline, etc).  Download the Root certificate (rootCA.crt) and your “PKCS12 with intermediate and root” .p12 file, and save them to a fixed location on your machine.

Select the “eduroam” network from Network-Manager applet.
Should auto-identify as WPA/WPA2 Enterprise.
Authentication is TLS.  (It’s NOT Tunneled TLS or PEAP here, like it is most other places.)
Identity is “YOURLOGIN@alaska.edu”.
User certificate is left blank (for some reason).
CA certificate is rootCA.crt file downloaded above.
Private key is your .p12 file, again from above.
Private key password is YOURLOGIN.
Overall, it should look like this browser and network manager setup.

This shows Eduroam working correctly in Linux.

This shows Eduroam working correctly in Linux.

Now connect to the eduroam wifi!

It should connect within 10 seconds; if it lags for half a minute or more something’s messed up.  You need to download new certificates every year, so keep this post handy!

August 9, 2014

WebGL Nonlinear Iterated Function System Rendering

Filed under: Random Thoughts — Dr. Lawlor @ 1:13 am

A few years ago I built a fun little nonlinear iterated function system fractal renderer that works on the GPU.  I got very pretty pictures and interesting scientific results, but my demo is an OpenGL application, so it’s a pain for people to download and see. Juergen Wothke just ported my renderer to use WebGL, so it can animate beautiful swoopy lines in realtime, at least in Chrome. A prerecorded video doesn’t capture the full resolution or the 60fps speed that a good graphics card is capable of producing!

Read his technical details at his blog.  Browser audio processing was the main headache.

I’d love to see somebody build a full-on interactive editor for nonlinear IFS using WebGL and my GPU rendering technique!

May 21, 2014

Tolerating Electrical Interference: reconnecting USB ports

Filed under: Arduino, Hardware, Linux — Dr. Lawlor @ 6:18 pm

UAF’s Aurora Robotics team entry in the NASA Robotic Mining Competition is using a standard Arduino Mega as the central microcontroller, which has worked well except for one intermittent disconnection problem, which we believe is caused by electrical interference from our big motors.

When it disconnects, the Linux kernel shows a dmesg error like “ehci_hub: USB disconnect on port 3 (EMI?)”.  We had previously built a system to tolerate this, by simply waiting a few seconds and reopening the USB serial connection, but this was only a partial fix since eventually the kernel disables the port completely.  This is bad because we could only fix it with a complete restart.  During our second practice mission yesterday, the kernel disabled all USB ports just as we began the run, resulting a completely scrubbed practice mission.

John Pender found a very simple way to re-enable the USB ports by running these commands as root:

echo "0000:00:1a.0" > /sys/bus/pci/drivers/ehci_hcd/unbind
echo "0000:00:1d.0" > /sys/bus/pci/drivers/ehci_hcd/unbind
echo "0000:00:1a.0" > /sys/bus/pci/drivers/ehci_hcd/bind
echo "0000:00:1d.0" > /sys/bus/pci/drivers/ehci_hcd/bind

This basically just turns off the kernel’s EHCI USB driver, then turns it back on, allowing the USB ports to be used again. Use “lspci | grep USB” to verify those addresses are correct for your machine (they seem right for most laptops).

The long-term fix for electrical interference issues on Arduino is using opto isolators on each digital control channel connected to a noisy source, but it’s often difficult to fully separate the ground planes in real robotics designs, so this is a simple fast way to get your robot moving again!

April 9, 2014

NightWeaver: a trivial live HTML editor

Filed under: Random Thoughts — Dr. Lawlor @ 11:38 am

One of my fellow professors is teaching an introduction to HTML in his CS 101 course, and I felt like he could use a simpler interface for students to get their first taste of HTML web programming.  So I built this trivial two-column editor:


Everything runs on the client side using a half dozen lines of quick and dirty javascript (basically just output.innerHTML = textarea.value).  It’s conceptually similar to my server-side C++ and assembly interface NetRun.  It’s called “NightWeaver” since I wrote it in one night, and is not related to Adobe Dreamweaver.

April 8, 2014

OpenCV: fix for V4L VIDIOC_S_CROP error

Filed under: Random Thoughts — Dr. Lawlor @ 5:00 pm

I’ve been playing with the excellent little OpenCV library ArUco for detecting the 3D position and orientation of printed QR-code style “markers” in live video feed from a webcam, but I kept getting this annoying error now and then:

VIDIOC_STREAMON: Invalid argument
VIDIOC_STREAMON: Invalid argument

What’s weird about this is it wouldn’t happen every time, normally things would work fine until this started, and then it’d keep happening until I unpluged and re-plugged the USB camera.  

Turns out, this happens when you press ctrl-C (interrupt) during the middle of a video capture.  Evidently this screws up something in the kernel (dmesg shows “xhci_hcd 0000:00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring”), preventing further video streaming from that device.  Operationally it’s quite annoying, and for an autonomous robot, you can’t easily unplug and replug just to get things working again.  

A simple workaround is to catch SIGINT, the signal generated by ctrl-C, and delay shutdown until after the next video frame has fully arrived:

/* Keep the webcam from locking up when you interrupt a frame capture */
volatile int quit_signal=0;
#ifdef __unix__
#include <signal.h>
extern "C" void quit_signal_handler(int signum) {
if (quit_signal!=0) exit(0); // just exit already
printf("Will quit at next camera frame (repeat to kill now)\n");

... in main setup ...
#ifdef __unix__
signal(SIGINT,quit_signal_handler); // listen for ctrl-C
... in video capture loop ...
yourCaptureDevice >> videoImage;
if (quit_signal) exit(0); // exit cleanly on interrupt

My webcam now works reliably, even when I ctrl-C out of the analysis program!   (I’m running Ubuntu 13.11 and OpenCV 2.4.1, but this may be a bug in the Linux kernel 3.11.)

March 16, 2014

Arduino millis() jumps by 2 every 43 milliseconds

Filed under: Arduino, Programming — Dr. Lawlor @ 1:07 am

I’ve been doing some software-modulated infrared light detection work, and for the signal to be sent correctly I need millisecond-accurate timings.  I realize professionals do this sort of thing with interrupts, but I hate debugging interrupt code, and I’m always afraid there’s some rare timing glitch that will kill the entire project at the worst possible moment.

I was using Arduino’s millis() function as my time base, and I kept getting weird screwy timing every 43 milliseconds.  I assumed it was my code, which does a bunch of other stuff like serial communication, but the glitch didn’t change regardless of what I did.  Turns out, the Arduino Uno’s oscillator runs at a power of two rate, 1.024 milliseconds per overflow, so every 1/0.024 = 41.666 milliseconds, it’s a full millisecond off.  Arduino wiring.c fixes this by keeping track of the fractional milliseconds, and adds a sort of “leap millisecond” every 43 milliseconds to keep things in sync.  This results in millis() instantly jumping up by more than one.

Here’s an example Arduino Uno sketch that demonstrates these timing jumps, and shows two fixes.

/* Demonstrate timing gaps in the millis() function */
void setup(void) {
 Serial.begin(57600); // to report the horror

extern "C" volatile unsigned long timer0_overflow_count; // from wiring.

unsigned long last=0; // last value of millis()
void loop(void) {
 unsigned long next;
 do { // watch the timer until it changes
   next=millis(); // jumps by 2 every 43 ms
   //Two possible fixes:
   // next=micros()/1000; // slow, but works
   // cli(); next=timer0_overflow_count; sei(); // faster, but 1024 microseconds/tick
 } while (next==last);

 int delta=next-last;
 if (delta!=1) {
   Serial.print(" jump at ");

 if (last%10000==0) {
   Serial.print("Still running at ");

On my Arduino Uno, the millis() version of this reports regular timing glitches:

Still running at 0
2 jump at 43
2 jump at 86
2 jump at 128
2 jump at 171
2 jump at 214
2 jump at 256
2 jump at 299
2 jump at 342

The easy way to avoid these timing jumps is never to use millis() at all!  It works to just use micros()/1000, although looking at wiring.c’s implementation of delay(), you need to be a bit careful about when micros() overflows every hour.  You can also directly read the raw timer0_overflow_count as shown above, although the actual speed this increments depends on the Arduino clock rate, and you need to do cli/sei around the read to avoid jumps of +-256, as the interrupt function updates the two bytes of that value.  Both fixes never have leap milliseconds, and result in dependable timing.

« Newer PostsOlder Posts »

Create a free website or blog at WordPress.com.