OpenSCAD - 3-D modeling script language

I had been looking for some easy-to-use 3-D CAD software which runs on Linux, and is preferably open-source. The goal is to design and build stuff like this Do It Yourself Book Scanner, where all the pieces can be cut out of a 4x8ft sheet of plywood or maybe thick plexiglass.

I had initially passed over OpenSCAD because it seemed that it was more about assembling 3-D renderings from 2-D CAD files. However, I had cause to look at it again this week, and I like it a lot better this time.

The basic idea is that you create a script that draws out 3-D primitives (cube, sphere, cylinder, etc.) and add / subtract them to make objects. What follows is an example.

Here is a small module for a part.

module flange() {
  difference() {
    translate([1,0,-1]) cube([8,4,2]);
    translate([7,2,-1.1]) cylinder(h=2.2,r=1,$fn=100);
  }
  translate([-1,2,-1]) cube([2,2,2]);
  translate([-3,0,-1]) cube([2,4,2]);
}

Here's the code to actually call the module to render it.

color("LightBlue") flange();

And this is what it looks like:

The modules can be called multiple times, for example here to make interlocking parts:

rotate(a=[180,-90,0]) translate([0,-4,0]) flange();

Both of them rendered looks like this:

Where this is becoming handy (at least for me) is that I can create a module which renders the finished assembly, with all the component parts moved into the proper place for the design, similar to the above, and see how all the cut-out parts will fit together.

It is then easy enough to use the same components and have them all laid out in a single plane. I can then convert the drawing to DXF, open it in LibreCAD, set the actual dimensions, and go!

That is very neat. Overall, this is quite a different experience than what you get with a traditional CAD environment, but it more suits me as a programmer. Conditionals, math formulas, loops and such are possible with OpenSCAD, so that makes some kinds of designs much easier.

Writing Code on Handhelds

I was emailling recently with someone about doing development on handheld devices. Not just writing software for handheld devices, but what it is like to actually write code using a handheld device as the development platform.

What follows is a description of my mobile development environment, and the ups and downs of using current generation phones for software development.


I've wanted a decent, portable Linux machine to do hacking on for a long time... dating back to the days when I was messing around with trying to get a cut-down version of Linux running on a HP 100 LX palmtop. And now I'm finally there.

My current mobile phone is a HTC Dream (a.k.a. the T-Mobile G1). I actually bought the unlocked ADP1 version directly from Google. It is currently running a custom Android 1.5 firmware (cupcake). Since everything basically works (like phone calls), I haven't been on the upgrade treadmill... though I'll definitely upgrade to CyanogenMod CM6 when Android 2.2 (froyo) is released.

For doing code development on this device, I'm using the excellent ConnectBot as a local terminal program. This is far superior to the Google terminal.

After partitioning an 8GB micro-SD card (2GB for FAT32, 6GB for ext2), I was then able to install Ubuntu Jaunty userland using Paolo Sammicheli’s instructions. So that gets you: Python and Lua, VIM, screen, ssh, rsync and GCC. A decent browser, always-on (if slow) Internet, WiFi, Bluetooth, expandable storage... and it makes phone calls too! How cool is that?

I've been using Mercurial for my DVCS, but the Ubuntu packages weren't available. However, I was able to just download the source and run it on the G1 as well.

For the code I write, I'm not accessing any of the phone's features, nor am I trying to make regular Android applications. If I were, though, there is the Android Scripting Environment available, through which you can also use Lua.

As far as editing code on a small mobile device, the major pain points are exactly what you'd expect: screen size, keyboard, overall speed and storage.

With ConnectBot, I can get a 80x22 terminal window... using a tiny font. So that's kinda OK. And using GNU screen here helps a lot by just being able to flip between my edit window and the compile / run window.

But not having a browser window open on a 2nd monitor slows me down a lot. Sometimes I can get by with Lynx in another console window, but that isn't too fun.

As far as the keyboard goes, the G1 is completely superior to any other phone keyboard I've ever seen. For starters, it has dedicated number keys, and the brackets, parens, and other ASCII symbols are all available with a single Fn button push. This is in marked contrast to other phone keyboards which would make typing code in any programming language much more painful.

That said, the keyboard does slow me down. I don't type real fast (maybe 60 wpm normally), but the phone's keyboard slows me down enough to interfere with my thought processes.

As far as speed goes, it is not too bad really. I don't do heavy number-crunching or work with large data sets, and Lua is one of the fastest scripting languages anyway. But if I do start dealing with large data sets, the phone will be unacceptably slow compared to a desktop.

There are some new chips on the horizon (like Nvidia's dual-core Tegra 2) that should improve things considerably. I'd like to see that in somethine like the OpenPandora form factor (though I have issues with that particular product).



So how good is this platform really? Is the environment good enough for short edits, like fixing a bug?

Yes, it definitely works fine for stuff like that. I do write short segments of code on it too, when I don't feel like breaking out the netbook.

Do note that I only use VIM for code editing, which works way better for this handheld device.

For instance, since I don't use 'find letter' commands in VIM, I've mapped 'f' to page down and 't' to page up. So I'm not hitting control key combinations very often. That is a two step process in the ConnectBot terminal program... you have to press the trackball button, and then 'f' for Ctrl-F. There is no dedicated ESC key either, that is mapped to a double press of the trackball button, which isn't too bad.

If I was using Emacs or any other non-modal editor, code editing would be a lot more painful, and I'd have to rely on using the trackball to move the cursor around. And that would be very slow.

Code editing in general is going to be a problem for any mass-market handheld device I'd expect. I've never seen one with a dedicated ESC key, Ctrl key, or (hah!) an Alt key (in the desktop keyboard sense). These devices are optimized for typing in plain text, not editing. And definitely not code editing.

ConnectBot has other nifty features. For GNU Screen you can map the phone's camera button to 'Ctrl-A Space', to switch to the next terminal window. You can also map a short press of the right ALT key to be '/', and a short press of the right shift key to be Tab. So typing in paths and autocomplete are easy.



I've looked at some of the other Android phones that have keyboards, but most don't have dedicated number keys. Many also don't have some important symbols mapped to the alt-keys. Typically these symbols are missing: { } < > [ ] ~ _ \ Whereas the G1 has all of these as Fn-keys. It is probably possible to type in those symbols on other phones, but it may require a three key press combination. :-(

The Motorola Android phones are examples of the ones that have less keys on their keyboards. And my co-workers tell me that typing on the Droid isn't that fun anyway, the keys are too close together.

Other phones with possibly acceptable keyboards include the LG GW620 and the Samsung SPH-M900 'Moment'. I'm not sure what it takes to get root on those phones though. I bought the developer version of the G1, so it was easy to load custom firmware and get root.



So, in summary, if you're satisfied with the tools I normally use: GNU Screen, VIM, ctags, and command-line everything else, the G1 phone is about as good as it gets for ultra-portable hacking right now. With some practice, I've been about to get up to about 30wpm on the G1's keyboard for English text.

My dream phone would have a slightly larger screen, about 4.2in. We don't have to go crazy-high resolution, WVGA would be fine. The keyboard could be a little bigger, with the keys spaced out a little more. But not too much! I still want to use just my thumbs, without having to stretch.

More important though would be dedicated ESC, Tab, '/', Control and Alt keys. I can live with the symbols being Fn-key combinations. Other minor touches would include re-programmable shoulder buttons.

More speed and storage would of course be welcome. Qualcomm has talked about dual-core 1+ GHz Snapdragons, so that would be excellent. I'd also want at least 512MB of RAM. Full support (and APIs) for OpenGL ES and OpenVG would make GUI applications real zippy.

Designing that sort of thing is actually my day job too. But I can't justify the hundreds of thousands of dollars to just make one for myself. :-)

Lua for "Artificial Intelligence - A Modern Approach"

I've started a Google code project for a Lua implementation of the algorithms from the Stuart Russell and Peter Norvig book Artificial Intelligence: A Modern Approach.

I'm planning on working through the book, chapter by chapter, and creating Lua implementations of everything. In general, I'll try to stick to the spirit of the algorithms presented in the book, though there may be ways to implement them it in a more elegant and concise fashion using Lua's unique strengths.

Emphasis too will be on code that is "production ready", meaning that it can be readily incorporated into other projects.

The style of the code will vary. If it makes sense to use OO style, great. If functional seems a better fit, then I'll use that instead. I'm not as dogmatic about that kind of thing as I used to be.

I'm using a Mercurial repo, so if you'd like to contribute, just clone it and get going!

SWIG and Lua

So I've been trying out SWIG with Lua recently. This was to wrap a 3rd party C library that I didn't have source for.

The initial wrapping went pretty smoothly. The only problem was that the library had its own typedef of 'bool' as an unsigned char, but SWIG treated that as a syntax error. I had hoped to avoid making copies of the header files, but ended up doing that and so commented out the typedef.

I was also a bit disappointed with the handling of some pointer types. Suppose you've got a function that takes a pointer to a double. I had expected that I could just call the wrapped Lua function with a Lua number and have that handled automatically. But I ended up declaring some pointer types, creating those C-based objects, and using those. There is some means with SWIG to declare pointer args, but I need to read that section of the docs again.

Similarly, I wanted to just pass in a table of strings and have that automatically converted to 'char **', but that is not automatic either. So that code on the Lua side is klunky too. I'm not sure that can be fixed.

I'll have to investigate luabind and toLua more.