Skip to content

DrawBot 5 – Makelangelo deep-dive

After a bit a a hiatus, work is progressing again.

We ordered some NEMA-17 motors from RobotShop. These seem to have the right mix of power input and strength.

Also, i’ve read most of the code to Makelangelo. The embedded code runs on a standard Arduino Uno, and connects up to an Adafruit Motor Shield v1 (or v2). This can’t directly drive the NEMA-17 motors, but will let us bring-up the rest of the system. As mentioned before, the source is on GitHub: host controller, firmware. There are also some 3D models on Thingiverse.

It conveniently runs G-code. There’s a great reference of G-code on Wikipedia. This is mostly standardized text format, but of course due to the complexities and differences of each CNC machine, you’ll rarely find 2 that are interchangeable. This is different than the earlier goal of using HP-GL, but this is easy to get up and working. With well architected software, it should be o problem switching these out — much like printing to 2 different printers.

From the Arduino IDE, you can paste G-code into the serial monitor once the Makelangelo firmware is loaded on the Arduino. To test it is working, try first rotating the motors:

D0 L500;
D0 R500;


Try drawing a triangle:

G1 X100 Y100;
G1 X0 Y100;
G1 X0 Y0;

Getting the host software up and running is a fair bit more challenging. The main problem seemed to be JOGL doesn’t seem well documented (at least from an installation perspective). Fortunately, Makelangelo has a distribution that comes packaged with all the libraries. We set this up this evening and it seemed to make the motors do reasonable things — still don’t have a pen or gondola hooked up, so hard to tell for sure.

Since this is missing the primary feature we’re wanting, we’ll have to do some code development over the coming weeks. We need to make a decision or whether to fork Makelangelo and continue in Java, or simply write something from scratch in Python. Going with Makelangelo will force us to figure out the the JOGL and possible other library issues. Switching to Python may mean we have similar issues anyways…

The plotter thickens…

Chris and Dave have been making an X-Y version that will (in theory) take the same drawing input (with g-code differences) and draw. Here’s an initial design with drawer extensions as axes.



Posted in Make, Robotics.

Tagged with , , , , .

DrawBot 4.1 – Schedule

We’ve filled out an application for Maker Expo. It is September 10 at Kitchener City Hall. Hopefully we can get something working by that point…

Posted in Make, Robotics.

Tagged with , , .

DrawBot: 4 – The 2 bears

Investigating the motors and drivers more, we hooked up the NEMA-14 to the Keyes L298 driver. This only improved the performance a bit. At 20V, the motor was getting quite hot and unfortunately still was not generating much torque. For reference, this is a Japan Servo KP35FM2‐035. This motor can in theory generate about 700 g-cm of torque, but only for short periods of time without overheating.

The NEMA-23 is a Japan Servo Pk266-02A. We carefully brought this up to 20V and 2A… this was about maxing out the Keyes driver without even making the motor work much. It wasn’t able to drive very high RPMs, thugh the spec sheet indicated that 500+.

We also tried a NEMA-23 Japan Servo KP56LM2-097. It seemed to not draw as much current, but it too would need a much more capable driver.

At this point, we have a motor that is (possibly) too big and one that is too small. We’ll need to look into getting a NEMA-17 motor (the size between 14 and 23) and getting more capable drivers. Until this is ironed out, we can at least take a look at the software side of the project.

Too small:


Too big:


Also too big:




Posted in Make, Robotics.

Tagged with , , , , .

Setting the calendar locale

The default calendar settings are pretty annoying in Ubuntu. To use more standard ones, add this line to your .profile:

export LC_TIME="en_GB.UTF-8"

This has a couple effects. It will set the first day of the week to Monday. It will also use the standard ISO 8601 rules for weeks.

You can show the weeks by:

  • click on the clock in Ubuntu’s top bar
  • click on Time & date settings
  • click on the Clock tab
  • choose 24-hour time
  • select Include week numbers

Unfortunately, this seems to be written to ~/.config/dconf/user file, which is binary… so it doesn’t make sense to try to make this into a source controlled.

Posted in Uncategorized.

Tagged with , , , , .

DrawBot: 3 – When the smoke clears

Progress as far has been smokin’. Not in a good way.

It turns out that connecting 2 power supplies will create a short on the common connection. Putting a couple amps through a fly wire cause it to smoke. Who would have guessed?

The motor tests started with a NEMA-14. We got up to 300 RPM with it, but it unfortunately has no torque.

Then we tried a NEMA-23… it drew too much current from the controller and caused it to overheat. Oops. Fortunately, no permanent damage. So instead of using the Adafruit motor shield, we hooked up a Keyes L298 driver.




Upping the voltage, the power supply started clacking. It turns out this is normal. Well, when you over current it. We had it set to maybe 300mA. Upping the current to 1000, we tried again… and it worked! A little more adjustment, and it started to smoke again. Doh! Fortunately, it was just some small lead wires that we used to connect the power supply into the Keyes.

Oh, and the Keyes can’t down convert to 5V when the supply is over 12V without overheating the regulator. Good thing we had a thermal camera handy.




Posted in Make, Robotics.

Tagged with , , , , .

DrawBot: 2 – A sketchy past


There are lots of great blogs about making drawing robots. Here is a brief summary of the ones we found most useful…

Makelangelo (MarginallyClever, 2015)

DrawBot (MakerBlock, 2012)

  • pen on vertical paper
  • very detailed info (almost too much)
  • Arduino Uno, 9V 1A power, small steppers

IsoscelEase (Whyte Darcy, 2014)

  • pen on horizontal surface
  • 1 arm, V shaped (isosceles triangle)
  • fast, seems fairly accurate
  • Arduino, motor shield
  • video

EV3 Print3rbot (2015)

  • 2 joined stiff arms, each angle controlled by stepper
  • whole arm moves up and down for pen up
  • LEGO
  • video

Hektor (Lehni Jürg & Franke Uli, 2002)

  • spray paint on wall
  • 2 toothed belts
  • little technical info available

Der Kritzler (Weber Alex, 2011)

  • marker on vertical glass
  • 2 toothed belts, laser cut gondola, servo for pen up-down, NEMA-17 steppers, 3-12V12A power, Arduino breadboard, A4983 stepper drivers

Drawbot (Fab Academy, 2013)

  • blog with build ideas

Other mentions…

Cartesio (hackaday)

ZarScribe (YouTube), 4 ropes to tension the gondola


Posted in Make, Robotics.

Tagged with , .

DrawBot: 1.1 – first steps

There is an interesting HPGL interpreter for Arduino on GitHub call plotr. The code seems pretty well written. It assume an (x, y) stepper setup… and seems to write 3 bits for each stepper. I’m not sure which it is intended for, since most steppers takes only 2 bits (4 positions). Perhaps this is 1 bit for simple micro-stepping.

Also started experimenting with hardware we already had, like the Adafruit motor shield and a small bipolar stepper. It’s been a while since i’ve used these, so can’t recall the basics of how these work. It turns out Wikipedia has a good intro on stepper motors. I’ve been wondering how it is possible to determine the direction with only 2 sets of coils.

Posted in Make, Robotics.

Tagged with , , , , .

DrawBot: 1 – planning

Their are a few big questions:

What should it draw with?

Pen, paint, spray paint, sand (like zen garden), etc…

What should the overall mechanism be?

  • (r, theta)
  • (x,y) — worm drive or belts
  • H wire axes, sides connected
  • differential tension — weighted spring to accelerate downward motions, friction to surface
  • differential compression
  • rotate surface, multiple pens(8), for raster type images


Chris offered “A large 4×8 drafting table ready to attach stepper motors to.”

Neil suggested that HPGL would be a good format. It is simple, text based, and made for plotters. It turns out that g-code is not very standardized, in that standards are great — everyone should have their own.

Some interesting ideas to make it more unique:

  • Magnetic cart, drive hidden in rear. All power to front is only EM.
  • Double motors or gear switch per axis. One for fast positioning, other for accuracy.

Posted in Make, Robotics.

Tagged with , , , , .

DrawBot: 0 – the spark

Neil brought forth the idea of a group robotics project of a drawing robot. There have been quit a few drawing robots in the past, but just because someone else is a painter (or a drawer) doesn’t mean that you shouldn’t do it too. There are still lots of room for innovation, both artistically and in engineering.

How could we make our’s unique?

  • faster
  • camera attached to make it interactive for events (Maker Expo in mind)
  • use interesting techniques to convert photo to drawing

High level architecture could be a pipeline:

  1. image acquisition
  2. convert image to vectors
  3. convert vectors to strokes
  4. hardware that reads strokes and draws them

This would mean that we would be able to replace steps with minimal impact on other components. Indeed, we could even make multiple robots that sharethe first 3 components.

There are still a lot of questions: what formats t use? g-code? SVG? Something proprietary?


Posted in Make, Robotics.

Tagged with , , , , , , .

Annual git summary

Suppose you are doing some annual reviews for your team / project. What did each person contribute, and how much? To get a year-at-a-glance, check out this git shell script.

Describing what the script does, it first lists all contributors to the repo in the past year. Then it iterates through, forming a list of commits for each contributor. Then it builds a sorted summary of how many commits each author contributed.


# Annual review of changes in a git repo

mkdir -p review
committers=`git log --since=1.year --format=%ae | sort | uniq`
for c in $committers; do
    git log --since=1.year --author=$c --pretty=oneline | grep --invert-match "Merge\|Merging" > review/$c.txt
pushd review > /dev/null
    rm -f summary.txt
    wc -l * | sort --general-numeric-sort --reverse | sed 's/.txt$//' > summary.txt
popd > /dev/null
echo "Done. Results in review/"

This script doesn’t try to weight the result by amount of code in each review, code complexity, feature vs. bug fix, etc. It is assumed that developers will tend to write changes about the same size… after all, if a change is too big and complex, then it should probably be broken into a stack of simpler refactorings prior to the feature change.

Also, it should be assumed that the development team reviews all changes and that these pass a pre-commit build and test job, for example on Gerrit and Jenkins. After all, encouraging developers to commit crap will not lead to software quality.

You will also want to check for the number of reverts or patches… If the total is more than 1% (or some small number), then you’ll want to modify the script to omit both the reverts and the changes that were reverted, possibly putting these on another list to denote a penalty — something to be discussed in the performance review and RCAed (root cause analysis) with sort of corrective action taken. This wasn’t the case in the projects i was interested in, so it is left as an exercise to the reader.

When reviewing your team, measurements help — but don’t rely on any particular one. In this case, we ignore non-coding activities, such as: writing feature specs, investigating bugs, other research, documentation, architecture, working on other projects / repos, etc. Summarizing the repo history can help get a view of one aspect of a software developer’s responsibilities.

Posted in Software development, Tech.

Tagged with , , , , , , , , , , , , , , , , , , .