Dr. Lawlor's Code, Robots, & Things

August 12, 2015

Parrot “Rolling Spider” UAV Hacking: Dumping the Filesystem

Filed under: Hardware, Linux, Programming, Rolling Spider — Dr. Lawlor @ 11:53 pm

I just got a new tiny UAV, the Parrot “Rolling Spider” ($80), which is very fun to fly via bluetooth with my phone.  But it’s also a linux-based computer, so it’s also fun to hack!

The easiest way to get a root shell is to just plug it in via the USB cable, which not only shows up as a removable USB drive, it also shows up as a network device (at least, as of the 1.99.2 firmware version).  This means you can immediately get a root shell with:


That was easy!  Now to dump the filesystem, to netcat on port 1234.  (The ^p avoids /proc, which has infinite recursive root links; the ^y avoids /sys, which has files that change in size.)

tar cpf - [^p][^y]* | nc -l -p 1234

To get the filesystem as a file on your desktop computer, now just:

nc 1234 > rootfs.tar

This has *everything*, from:

drwxr-xr-x root/root 0 1969-12-31 14:00 bin/
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/getopt -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/dd -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/cp -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/df -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/ip -> busybox
-rwxrwxr-x root/root 35 1969-12-31 14:00 bin/kk
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/ln -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/ls -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/mv -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/ps -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/rm -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/sh -> busybox
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/vi -> busybox
-rwxrwxr-x root/root 305 1969-12-31 14:00 bin/blink_led_orangeleft.sh
lrwxrwxrwx root/root 0 1969-12-31 14:00 bin/ash -> busybox


drwxr-xr-x root/root 0 1969-12-31 14:00 usr/share/avahi/
-rw-r--r-- root/root 560 1969-12-31 14:00 usr/share/avahi/avahi-service.dtd
-rw-r--r-- root/root 5104 1969-12-31 14:00 usr/share/avahi/service-types
drwxr-xr-x root/root 0 1969-12-31 14:00 var/
lrwxrwxrwx root/root 0 1969-12-31 14:00 var/log -> /tmp/
-rw-rw-r-- root/root 7 1969-12-31 14:00 version.txt
drwxr-xr-x root/root 0 1969-12-31 14:00 www/
-rw-rw-r-- root/root 485 1969-12-31 14:00 www/index.html

For example, now I can see the contents of the control shell scripts:

$ cat bin/set_led_greenleft.sh 

# temp behaviour : red light right on
gpio 33 -d ho 1
# temp behaviour : red light left off
gpio 30 -d ho 0

#green light right off
gpio 31 -d ho 0

#green light left on
gpio 32 -d ho 1

I can also see the details of how the code was built:

$ file bin/busybox
busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped

Of course, eventually I’ll want to permanently modify this filesystem, by re-flashing the UAV with a reverse engineered PLF firmware file, which is similar to the Parrot AR Drone PLF format.  I’m nearly there with “plftool -e raw -i rollingspider_update.plf -o .”, but each resulting file has the filename prepended in some sort of fixed-length binary header.

Stay tuned!


August 6, 2015

Alaska90: my huge new 3D printer design

Filed under: 3D Printing, Hardware — Dr. Lawlor @ 12:51 am

I started working on a huge new 3D printer design, the “Alaska90”, back in November 2014, but I got busy with school and stalled out.  This summer I finally got a few spare days and finished up the build, which is working well and printing huge things. Main features:

  • 600mm x 500mm x 600mm build volume (24 inch x 20 inch x 24 inch), to construct models as big as a few feet on each side.  By contrast, a typical printer prints about 200mm (8 inches) on a side.
  • Frame is built from 3/4 inch plywood, and parts are secured using 1/4 inch hex head bolts.  By contrast, a typical printer uses 1/4 inch wood or plastic, and tiny M4 screws.
  • Uses heavy 16mm steel rods, so it’s rigid enough to mill wood with a small dremel tool.
  • Support rods are moved inward, to gauss points, to better support the 24 inch x 24 inch bed.

3D rendering of Alaska90 3D printerPhotograph of Alaska90 3D printer The full design details, STL files, and OpenSCAD source code for the Alaska90 printer is on my github.

July 18, 2015

LaserJet 8500: a huge awesome ancient laser printer

Filed under: Random Thoughts — Dr. Lawlor @ 8:52 pm

At a surplus auction today, I picked up an Apple LaserJet 8500, a 60 pound black and white laser printer from the 1990’s.  Why did I bother buying such an ancient beast?

It can feed huge 13 x 19 inch paper!  I often do robot design work in CAD, then laser print a template to glue onto steel, plywood, plastic sheet, or whatever material for further drilling, cutting, and machining.  This means the size of my parts is limited by the size of my printer, so a big printer lets me build bigger parts more easily.

Anyway, the hard part was getting the printer’s IP address.  Once you have the original IP, you can reconfigure it via telnet (it will make you set a password), and then send it Postscript files via the JetDirect (9100) network port.  All you need is the LaserJet 8500 PPD file, version 1.2–link is plain text that I had to unpack from Apple’s ancient classic Mac smi.bin file using the BasiliskII emulator.

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!

« Newer PostsOlder Posts »

Blog at WordPress.com.