Fanjita's Rants

Welcome to Fanjita's Rants. This site is just a repository for random thoughts and jottings about the state of the PSP scene. Anything you read here is my opinion, and mine alone - it does not represent the opinions of the Noobz team, or any other websites I might be affiliated with.

Note: If you're looking for the latest information about eLoader and other PSP homebrew news, you should be looking at www.noobz.eu. Fanjita.org hasn't carried any development news for a long time.

The new, improved, but uglier Raspberry Rover!

A few months back, I posted about my prototype "Raspberry Rover" - and then I had to stop work on it for a while, because things were busy at work, and my part-time work on iFringe and FringeGuru were reaching their busiest time of the year with the Edinburgh Fringe Festival coming up.

Recently I was able to pick it back up again, and fix a few of the snags that I'd come up against. It's now in a state where I feel able to share some of the lessons learnt. It's far from perfect, but it is functional with some clear ways forwards.

This posting will deal with the hardware design, and I'll talk about software and further plans for the future later. Continue reading "Raspberry Rover part 2 : The Hardware"

One of the essential properties of a mobile, Raspberry Pi-based robot is that it needs to run on battery power - trailing a power cord around is not much use.

The problem is that the Pi takes an appreciable amount of current (say 500mA, depending on activity and attached peripherals), and needs a pretty narrow input voltage range (5V +/- 0.25V, or so). Because battery voltage varies pretty wildly depending on the current charge level, running directly from a battery is not really sensible.

So, I set about looking into various options for converting standard battery voltages into something suitable for the Pi.

Using a linear regulator

The traditional approach, back when I was first tinkering with electronics about 30 years ago, would be to put together enough batteries to get a significantly higher voltage than 5V (say, 4x nonrechargeable AA to get 6V, or 6x rechargeable AA for 7.2V), and then run that through a linear regulator (e.g. 7805-series IC) to get a steady 5V.

There are 2 main problems with this approach.

1. Linear regulators are inefficient, and effectively burn off the excess voltage as heat. That means that you're just wasting battery life, and also probably have to deal with dissipating that heat with a heatsink.
2. The Pi draws quite a lot of current, so it would need quite a large regulator, along with a large heatsink.

Fortunately, there are much better approaches nowadays, in the form of switched-mode regulators, which are much much more efficient, even at high currents. Continue reading "Running a Raspberry Pi from batteries"

Here's a little video of my work-in-progress robot rover. It uses a Raspberry Pi, running OpenCV with a webcam, to see and react to its environment.

The current program is just a proof-of-concept prototype - it looks in the field of view for any strongly green objects. If it can see one, it turns to face it, then advances until it is close. If it can't see any, then it turns on the spot until it can.

The current platform was built very cheaply - parts from a 3 in 1 All Terrain Robot from I Want One Of Those, a Slice of Pi prototyping board from Ciseco, a cheap Hue HD webcam, plus a 2-channel H-Bridge motor control IC from Hobbytronics, and of course the Raspberry Pi. Total cost is probably about £60. Continue reading "The Raspberry Rover"

Self-portrait of a Raspberry Pi

Although installing OpenCV on the Raspberry Pi was made very easy by Arch Linux (see previous blog post), persuading OpenCV to capture images from my webcam was substantially harder. But, eventually I managed to get it working. Here's how.

My first attempt followed a sample program found on Stack Overflow. But what I found was that I was repeatedly receiving select timeout errors on the cv.QueryFrame(...) call. I also received 3 VIDIOC_QUERYMENU: Invalid argument errors every time I called cv.CaptureFromCAM(...), and Xlib: extension "RANDR" missing on display "localhost:10.0" the first time that I called cv.NamedWindow(...). Following those errors, the captured frame was displaying as a black screen, so I assumed that one of them was fatal. Continue reading "Capturing webcam video with OpenCV on Raspberry Pi / Arch Linux"

I've been experimenting with trying to get a usable OpenCV environment up and running on my Raspberry Pi, so that I can experiment with using it for machine vision. The catch is that I don't have a decent monitor and keyboard hooked up to the Pi, and I'm using Arch Linux - so most available tutorials aren't quite applicable to me. This blog post describes what I've done so far to get up and running using remoted X-Windows to get the job done.

Since I have an iMac as my main development machine, I already have a decent X server built in. I've happily used that in the past to remote VirtualBox virtual machine desktops from Debian, and it's a convenient and efficient way of running graphical apps on a headless server. So, that seems the logical way to go here.

The first step was to get a basic X client up and running on the Pi. This was probably the hardest part, and involved a lot of searching around, via both pacman and Google. Below are what should be the minimal set of steps to get this working, to save future readers from the trouble... Continue reading "Running OpenCV headlessly in Arch Linux"

I recently got my Raspberry Pi, and although I haven't had a lot of time to play with it, I've been able to do a little bit of mucking around.

I initially started with the Debian OS distribution, since I already run several Debian servers (such as this one) and it, or Ubuntu, are usually my distro of choice. But the experience with Debian on the Pi seems pretty flaky - no sshd by default (which matters to me since I only plan to run my Pi without a screen), and lots of people seem to have trouble getting hardware up and running (especially webcams), so in this case I fairly quickly moved over to Arch Linux - if only for the experience of playing around with another distro. Continue reading "Initial Raspberry Pi adventures : Setting up a webcam"

My last post discussed receiving and decoding signals from the Maplin socket controller. Here, I'll describe how I went the opposite way - faking the signal to control the sockets directly with an Arduino.

As it turned out, this was a lot simpler than receiving. For one thing, the transmitter module is just 4 pins rather than 8, and can be directly driven from the Arduino with no further components. For another, I already had a representation of what the signal needed to look like - I just had to drive the transmitter input pin with the right timings.

So, here's some trivial code to do just that - it turns channel 3, ID 2 on for 3 seconds, then off for 10 seconds, repeatedly. The transmitter module plugs directly into analogue pins A3-A5, as shown in the photo. The antenna pin is left unconnected for the time being - in practice, you'd probably want to connect a suitable antenna (or just a short piece of wire, as per the data sheet) to get optimal range.

Maplin have recently had special offers on remote-controlled mains sockets - as cheap as £5 for a socket and controller pair. Since the control frequency is on the standard 433MHz band, and I had a pair of Arduino-friendly 433MHz transmitter/receiver modules lying around, I thought I'd have a play to see if the control protocol can easily be reverse-engineered for use with the Arduino.

So, I dutifully hooked the receiver module up to 5V and an oscilloscope, and started pressing buttons on the controller. Things looked promising - a simple ASK pulse train, probably Manchester encoded.

A single data packet. Not shown is the leading low pulse between each packet - approx 13ms.

A slight sidetrack from Arduino stuff, but a friend asked me to write up how I did this - so here it is.

At the weekend, I helped my son build a "junkbot" - a little moving toy, built from odds and ends, and intended to look like a robot. It was inspired by this post on Hack-A-Day, plus Frankie's delight whenever I "invent" something for him.

The gist is really straightforward : stick a vibration motor on top of a base, add a coin cell for a power source, and whatever extra ornamentation you feel like. The spirit is to hack something together out of old junk you have lying around. The "robot" jiggles around due to the vibrations, and moves in random motions. It's pretty cool for such a simple little thing. Continue reading "Making a junkbot"

I posted previously about a cool ATTiny project by ELM, which implemented wave table synthesis. After playing with that, I decided that at some point I'd like to take it a little further. That point came last night.

My kids' favourite tune is Twinkle Twinkle Little Star, and we usually sing it at bedtime. I recently picked up a cheap moon-shaped wall-mounted night light from Homebase for £5 (no link, sorry - it doesn't seem to be on their website. Also available from B&Q, but again, nothing on the website), and it's pretty useless in its standard form - the batteries last for no time at all, because it uses an incandescent light bulb. So I decided to put it to better use, and convert it to LED lighting, and to put in a music box version of Twinkle Twinkle at the same time.

Cleaning up the waveform : before (yellow), after (blue).

When I last looked at my musical instrument tuner, I was having difficulty with real-world waveforms from the instrument : all the harmonics meant that zero-crossing analysis wasn't accurate for capturing the fundamental frequency.

This post describes my approach to solving that problem in the analogue domain - so that I don't need to worry about fast A to D conversion (although that would be an interesting problem in itself).

The standard approach is to implement a low-pass filter, with the stop frequency tuned around the desired fundamental, to get rid of those troublesome harmonics. A passive filter would only achieve 6dB/octave roll-off, which is unlikely to be enough. And you can't sensibly cascade passive filters to improve that. Time to roll out the op-amps, and implement active filters, which are easily cascadable, and in the simplest form, are usually 2nd order so 12dB/octave. Cascading two of those together should give 24dB/octave, which should be plenty of attenuation. Continue reading "Instrument Tuner - Programmable Filter"

I picked up some digital potentiometers, partly as a building block for making a programmable filter for the ukulele tuner, but also just to play around with, as they seem pretty cool.

They act exactly like a traditional potentiometer (i.e. there's an end-to-end resistance of 10KΩ, with a 'wiper' that can travel from one end of the resistance to the other), but the position of the wiper can be controlled via digital signals. It seems that they do actually use physical resistors internally, in some fancy switched network. Anyway, these can normally be used to generate a variable voltage, but I'm also interested in being able to dynamically change resistance in order to tune a filter.

Originally, I assumed these would be an I2C interface (previous models I'd seen were), and didn't pay too much attention to the datasheet. I2C is great, because you can use 2 pins to control a whole string of devices, so long as they all have unique addresses. But it turns out that they're actually SPI, which is not so good for small microcontrollers, as even in its minimal form, it uses 3 wires per slave device. I'd ideally like to control 4 digital potentiometers with a single ATTiny85 - with just 5 data pins available (6 if I don't care about being able to reprogram more than once).

So - is it possible to control 4 or more SPI devices, using a single ATTiny85? Yeah, of course it is - with a bit of jiggery-pokery. Continue reading "SPI addressing with minimal pins"

It's all well and good being able to place an ATTiny in my universal ZIF ICSP board, flash it, and then put it back in the circuit being prototyped.  But wouldn't it be better to be able to flash it in place, without all that tedious plugging and unplugging from sockets?

Well, I could add a 6-pin ICSP header to all my projects, which would make that possible.  But it's a bit of a pain to do that, and once the project is complete, that header will never be used again.  Seems like a waste.

And so, partly inspired by a post at JeeLabs (although I'd independently been thinking along the same lines), I came up with a different approach - the Frankentiny.

The principle is to create a small daughter board, comprising an 8 pin socket, and ICSP header, which can plug into another 8 pin socket.  This way, I can plug the ATTiny under development into the Frankentiny board, and plug that board into the socket in the circuit being developed. When I need to reflash, I just disconnect the power, connect the ICSP cable, and click "upload". As far as the prototype circuit is concerned, this board indistinguishable from an ATTiny.

This takes a little bit of caution to make sure that there are no delicate components connected to the ATTiny pins used by ICSP, but that's not much to ask in return for the convenience. 

Here's a picture of the ugly beast:

[UPDATE: And overnight, it was chosen to be featured as an Editor's Pick!  I'm delighted.]

I just published my first ever Instructable, after being inspired by following their channel on Flipboard for the last couple of months.

Here it is : How to build your own Duplo traffic lights, using an ATTiny, switch, 3 LEDs and a few bits of Lego.