Raspberry Pi Robot – Assembly Part 1

So you’ve got a bunch of parts, assembly is pretty easy. I’m going to skip over most of the chassis assembly since it came with instructions, but I have a couple pointers and I’ll go over how I attached the encoders. Then I’ll talk about soldering the motor controller and wiring the encoders up, and which pins to pick from the GPIO of the Pi. So this is what the chassis looks like fully assembled:

Installing Arch Linux with an encrypted root

I’ve got a ThinkPad T410. I got it off craigslist in what was a somewhat shady transaction. Regardless, it came with a 300GB spinner. Not interested in finding out how much life was left on it I got a solid state replacement from NewEgg for “Cyber Monday”. A 240GB Intel one for $110, that’s less than 50 cents per GB!

The spinner has a single unencrypted partition with Arch Linux running on it. I wanted to run Arch on an encrypted partition. The main reason: If it’s ever stolen I don’t want to have to worry about any of the data on it. Bonus reason: Geek/spy points.

So, while there are excellent guides for installing Arch, and setting up encryption, and optimizing an SSD, there don’t seem to be any combining the three. In reality it’s not that much more difficult, and if you are motivated to setup encryption on Linux in the first place you probably know what you’re doing. Still, I was disheartened a bit at the lack of information so I decided to note how I went about it in general.

Raspberry Pi – Cross-compiling

Now that you have the hardware built and tested (although that’s not necessary), you can either use the code I’ve written-which is specific to the hardware and environment I have, or compile your own version. If you want to compile your own there are two options:

  1. Compile on the Pi itself
  2. Compile on an ARM virtual machine
  3. Cross-compile on a faster machine

The trade off? Compiling on the Pi is slow (very slow). The virtual machine is a marked improvement for compiling speed, but is complicated to setup. Cross-compiling is about the same difficulty as setting up a virtual machine but a bit faster and less “bulky”. So it depends. The virtual machine is nice if you have a lot of libraries you want to use, since you’ll have to compile all of them to be available for linking. If any of them have poor autoconfig support, it might be a pain to fix if you weren’t already on the target machine. But, since I just needed one or two popular libraries, I decided to setup cross-compiling from my host (x86_64) machine.

The last time I setup cross-compiling it was on Gentoo, and it wasn’t pleasant. However, after a little bit of research it looks like the crosstool-ng project is pretty popular and useful. I only had to patch one tiny thing.

Here’s the overall process:

  1. Install crosstool-ng
  2. Configure a cross toolchain with it
  3. Try and build the toolchain
  4. Use the toolchain to build your Pi code

Raspberry Pi Robot

So, a while back I gave my wife a Farscape DRD kit. I promised to make it in to a robot. How hard could it be? Well, not too bad. A little more expensive than planned, though…

Image no longer available :(

Interesting Spam

Akismet is really good at preventing spam, but I’ve noticed that spammers don’t even seem to be trying sometimes. This is what’s in my spam queue: {I have|I’ve} been {surfing|browsing} online more than {three|3|2|4} hours today, yet I never found any interesting article like yours. {It’s|It is} pretty worth enough for me. {In my opinion|Personally|In my view}, if all {webmasters|site owners|website owners|web owners} and bloggers made good content as you did, the {internet|net|web} will be {much more|a lot more} useful than ever

Carduino 2.0 – Intel Galileo Setup

Out of the box the Galileo is setup to run sketches uploaded from volatile memory, which is really lame. I didn’t spend much time with it using the stock SPI kernel. So, an SD card is pretty much required to do any serious development with this board. This is not a bad thing (although you aren’t running in real-time anymore), since having a full OS to use has lots of advantages. Plus, this way I can automate the build process in a way I’m more familiar with.

Carduino 2.0

Over a year ago I got an Arduino Uno and a CAN-BUS Shield to try and make some kind of datalogger for my car. I was also interested in using the OpenXC library with it (which might need a port if there isn’t one already, since it uses the Digilent chipKIT Max32 development board). While OpenXC allows interfacing with Android stuff for phones, I’m more interested in a self-contained datalogging type deal.

First autocross with a VG33

Well, with less than a couple hundred miles on the rebuilt engine, it was time to really break-in the new VG33. I took it to an autocross. Things were going well until I shut it off after my second run. It didn’t want to restart after that. It appears that the culprit was low battery voltage, as the ECU was resetting and the fuel pump never even came on during cranking.

280Z LED Conversion Part 2

Continuing from part 1, this is the start of installation and results of the LED conversion. I ordered a small bunch of LEDs to get a feel for what brightness I’m looking at since the website I ordered from has somewhat confusing ‘relative intensity’, ‘brightness’, and ‘lumens’ listed for each bulb. Not to mention the prices seemed to fluctuate independently of any of those values so it wasn’t as simple as ‘find the most expensive ones’.

280Z LED Conversion Part 1

My 280Z isn’t what you could call “modern” in the electrical department. Originally, it came with an externally regulated alternator, fusible links, incandescent bulbs, and very few relays. The design inhereted a few things from Lucas eletronics, which is not a good thing. Regardless, it was fairly normal for the time. I’m glad there are no vacuum operated things, like some makes. The most electrically obtuse part of the design is the lack of relays.