Top Gear is dead . . .

. . . and I’m OK with that. I was rewatching shows from series 7 and 8, and those were the types of shows I wanted to watch. At some point, it became less about cars and more about cocking about in vaguely car-related ways. It was still fun, and I still watched it, but I felt like it was missing something.

The BBC may try to revive it with new presenters. Problem is, the current three have perfect chemistry together, which was a 1 in a million chance of working out (which is the fundamental reason why Top Gear Australia and US were never going to work). They might try to change it back into a straight car show like old Top Gear, but the brand probably can’t go back to that.

The current presenters may try to revive the concept under a new organization (Netflix? who knows). Fans underestimate the complications involved in that. They may not have access to the track, studio, production staff, or connections to the car industry that they did before. There’s more to putting on a show than filming a couple of old blokes with cars.

Meanwhile, some of the actions of the fanbase have been horrid. Jezza punches a guy for not providing hot meals, and they blame the BBC for suspending and firing Jezza. Plus, the victim started to get death threats, which is all kinds of fucked up.

Even the fanbase that doesn’t go to the deep end of the shit pool still dips their toes in. “Je Suis Clarkson”? Charlie Hebdo is a satirical newspaper that got shot up by religious extremists. Clarkson punched a guy in the face. Let’s have some perspective here, huh?

I still really like Regular Car Reviews. All the review sites were trying to ape the Top Gear style for years. Regular Car Reviews is the first in a while to try something different. Their 1995 Miata review was an instant classic (just like the car itself).

How did Linux become a second-class citizen on Arduino?

Using Linux with Arduino reminds me a lot of using Oracle with Perl; it works, but there’s a lot of things that aren’t up to the same level as other combinations. For Oracle and Perl, it’s somewhat understandable, as Perl comes from a FOSS background and Oracle, well…doesn’t.

That’s not true of Arduino however. Mac OSX seems to have better support than Linux, and Windows is almost seamless. I find it all very odd, because when it comes to most FOSS stuff, Linux support is easy, Mac OSX tends to work with minimal effort, and you’re a bit surprised when things work right on Windows. Somehow, Arduino has gone the other way round.

Just some examples I’ve come across:

  • I haven’t tried the latest versions of the IDE, but burning the Arduino bootloader to a fresh ATmega from the Arduino IDE doesn’t work. The reason is that the Makefile needs to know which of the USB ports to use, but it doesn’t even use the port that you selected in the GUI. The port that it does use is hardcoded to a Windows naming convention.
  • The Arudino IDE serial port monitor always crashes on me.
  • I’ve been playing with UnoJoy lately, which turns an Arduino Uno into a USB joystick. Which is great, but look at the instructions and download pages. There’s all the help you need on Windows and Mac OSX. There’s a wiki page for help on Linux, and it starts with “I really don’t know much about Linux at all . . . “
  • A while back, I was playing with HCDlib for controlling small toy quadcopters. When I tried to compile it, there was a compiler error about a missing arduino.h file. When I raised an issue with the author, he said my environment was screwed up. Once I dug a little deeper, the problem was that the proper name of the file is Arduino.h. Assbackwards compatibility on Windows means that you can get away with case-insensitivity like that, but not on Linux.

I suspect that these issues came about because Arduino was successfully marketed to people outside of the normal FOSS community. This meant a lot of people were developing and testing things on Windows and often Mac, but rarely Linux.

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

m4s0n501

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.