Got stuff that needs to be attached to other stuff? Use Attach::Stuff

I’m in the middle of a project that’s going to be continaing a Raspberry Pi, the Rpi
camera module, a GPS breakout board, an accelerometer breakout board, and a microphone breakout board. All that needs to be screwed into a lasercut case.

Now, the lasercutter at The Bodgery takes its own special format (naturally), but can also import DXF and PLT files, among others. Both of these can be exported by Inkscape, and I’ve generally found the PLT export works a little better. In any case, Inkscape can take an SVG file, which I can create programmatically in Perl easily enough.

So I worked out how to do all that with the SVG module. Thing is, the majority of boards are covered by these steps:

  1. Draw a box x mm by y mm
  2. Place a list of screw holes at designated coordinates, which all have the same radius

Which is really easy to wrap up into a single class, which gives back an SVG object with the bits above already done. If there’s something slightly more complicated to do (like making a box for the Rpi camera’s lens), then you can draw that in yourself with the SVG object you have in hand.

Here’s an example for Adafruit’s Ultimate GPS module:

All the stuff from the Raspberry Pi Foundation has schematics out there already, so that was easy. Adafruit’s breakout boards, however, don’t seem to have any published schematics (Sparkfun isn’t any better, as far as I can tell), so I got out the callipers and started measuring. Had to do some guess work with the screw hole location and size. After a few iterations of prototypes being etched into cardboard, I got a design that looks like it will work.

Attach::Stuff v0.652389025389315 should be out to the CPAN mirrors shortly.

Perl Advocacy Fail

Guy comes by Perlmonks wondering why his Perl program is so slow to start on a Raspberry Pi. Muses that Perl may be inappropriate for small platforms like this, and that perhaps the program should be rewritten in C. Monks get salty at the thought.

So great, now that guy probably won’t be back.

Now, the program in question was I/O bound, particularly on the Astro::Sunrise module. The initial thought of many Monks was that rewriting in C would not help, but that’s not obvious. Loading the modules involved here is a big task that would be built into a single binary for a C program, plus maybe some shared libraries that will likely be loaded up anyway at boot time.

Even so, there are better ways of helping here. The program uses threads and Switch, which are both probably unnecessary. Using threads in particular is a big performance suck.

I also double-checked, and the default perl on Raspbian actually is compiled with threads. I’m sure that’s because the base Debian distro has to be compatible with any Perl script you throw at, but that’s a big, unnecessary performance suck for a little Rpi. I’ll have to check, but Hiveberry might have a more sensible compile of perl. It’s a more up-to-date 5.20, as well (Raspbian comes with 5.14). That could make for a nice performance boost.

Newwwwwww QuadCopter!

My AeroQuad kit came yesterday. It’s a Cyclone frame with an AeroQuad32 control board. Spent most of the day at The Bodgery building it, and got most of the way through the frame build:

Half-finished AeroQuad

The plan is to put a Raspberry Pi on board that can be used for control over WiFi using UAV::Pilot, and also 1080p video.

Along those lines, I’m going back to the old WumpusRover code and getting the video streaming up to snuff. It’s ported to GStreamer1 now (instead of the original GStreamer CPAN module, which compiled against the old gst 0.10). One major item is that on a new client connection, wait for an h.264 keyframe to come down the wire before sending the client anything. There’s flags on the GstBuffer object that can do that, but they’re implemented via C macros that cause some trouble to the Glib introspection-based bindings. I’ll have to write some xs code into GStreamer1 to help support it.

(I feel like a bit of an idiot having my name on the GStreamer1 module on CPAN. With the Glib introspection bindings doing a whole lot of magic, I really have no idea how it works. I was just the one who stepped up to the plate to get it done. If someone came to me directly asking for help, I’d probably have no clue.)

Building OpenTX on Gentoo

I just got a Turnigy 9XR radio for a new quadcopter. I had been thinking about the Parrot Beebop, but I decided that I wanted a grown-up quad, so I got the AeroQuad Cyclone kit instead.

Now, the reason I bought the Turnigy 9XR is that it has an ATmega on board with fully customizable firmware. It even has the standard Atmel ISP port for programming.

I setup my laptop to build one of the major FOSS firmwares out there, OpenTX. Building the firmware itself went fine. The tricky part was building Companion, which is basically a big GUI wrapper around avrdude for burning the firmware. I hit an error that I couldn’t quite figure out:

This turned out to be because my Gentoo system was setup with python3.3 to be hit by default, and the code above is still on python2.7. I still had a build of 2.7 available, though, so it was an easy matter of switching:

Then follow the rest of the Companion build instructions, and switch it back to python3.3 when you’re done.

Coding for 80 characters per line — it’s not just for old farts anymore

In a discussion on /r/coding, people once again debated the merits of the old 80 character per line rule. My usual argument is that we want to put several code windows next to each other, so yes, we do want to limit things to 80 characters. The author of the linked piece mentions this, but I don’t think he makes a persuasive counterargument.

I might have changed my mind as 4K monitors become standard, but then someone in the discussion linked this:

http://www.pearsonified.com/2012/01/characters-per-line.php

This suggests that you should limit things to 50-100 characters per line for typographical reasons. Now, they’re mostly talking about prose writing there rather than code, but lacking studies otherwise, setting the limit to 80-100 seems sensible no matter how big monitors get.

GStreamer1 and Device::WebIO::RaspberryPi

Previous versions of Device::WebIO::RaspberryPi grabbed still images from the camera by calling out to raspistill. Given the limitations of the Rpi, this meant it had to load a program off the SD card into main memory and execute.

Meanwhile, the GStreamer framework has a plugin to read from the Rpi camera on its own. Problem was, the existing GStreamer module on CPAN was compiled against the deprecated 0.10 API, and rpicamsrc wouldn’t work against it.

I ended up asking around about 1.0 API bindings on the gtk2-perl list, and they were very patient in walking me through how to create them using Glib::Object::Introspection. Creating the bindings themselves was easy; hard part was figuring out all the magic it did behind the scenes to link to the C libraries and build Perl classes out of them.

After getting all that worked out, I released GStreamer1 on CPAN (the version number in the module name follows convention from Gtk2). Short on its heels, Device::WebIO::RaspberryPi 0.006 was released, which uses GStreamer1 to grab camera data for still images.

This greatly improves the wait time for grabbing an image in Device::WebIO::RaspberryPi. It also neatly solves a problem I’ve been struggling with since building the WumpusRover, which is that it was hard to reliably get images off the Rpi camera via Perl. With better Gst bindings, I think this is finally nailed down.

Keep WiFi Alive on Raspberry Pi

So solving my connection problems to a Pi by turning off power savings didn’t work. I’m now using a crude but effective method where the Pi pings the gateway every 2 minutes.

Start by adding this script to /etc/keepalive.sh:

This script works in an infinite loop, sending a single ping every 120 seconds. Call chmod 755 /etc/keepalive.sh to make it executable. Next, call it from /etc/rc.local:

Which will run the script on the next reboot. Call /etc/keepalive.sh & in a shell to start it running, and you’re done.

So far, this seems to make ssh connections start immediately every time. I’d like to figure out what the actual problem is, but this will do.