Category Archives: Dalek

Ports of The Dalek

I’ve decided on what interfaces the Pi-Dalek will mounted on the rear of the case.

  • USB-B socket to accept power for chrging the internal battery (a mobile phone emergency charger. Internally the socket offers a USB-A socket which is connected to the Pi with a short USB-A-to-microUSB-B cable, then the emergency charger, then another short USB-A-to-microUSB-B cable.
  • USB-A socket for memory sticks etc. Connected to the UTG socket with a short UTG cable.
  • HDMI socket. Connected to the miniHDMI socket on the Pi with a short adapter cable.

These will be mounted on the arse-end of the Dalek.  Two on the 3rd row up of the Dalek-bumps on the rear panel (both USB ports), with the HDMI socket on one of the rear flank quarters (3rd row up).

Ideally I’d like them all on the back, but the bumps on row 1 are blocked by the motor housing, while rows 2 and 4 have far too many structual bits behind it.

This still leaves me with the issue of mounting the camera. While I’d love to have the camera mounted to the eyestalk, this is impractical.  Mainly as the eyestalk is missing, but also because the camera module is a huge square blob that wouldn’t look right.

The best I can hope is to mount the camera on the Glacis, between the Whisk and Plunger, just above the top of the skirt. It will still mean that some cutting will have to be done, but it will probably not look as awful.

I’ve also decided that instead of mounting the Pi and Motozero directly to the base chassis, I’ll mount them upside down hanging from the internal ceiling at the top of the skirt. This shortens the distance to where I want the camera to be, and means only 6 wires need to be run down to the base (motor power +/-, motor left +/- and motor right +/-). Everything else will be skirt mounted. So the 40pin GPIO header connection twixt Pi and Motozero forms the split in the arrangement.

A sort of split between the head and body, if you want to make up some sort of analogy up.

I’m sure there’ll be some photos of it when its done.


Installing Raspbian on a Pi-zero W

There is so simple way to do this. I’ve tried several times and failed each time. So here is my idea to make things easy.

    1. Download your prefered Raspbian Jessie version from be it Lite or with Pixel.
    2. Get and install Etcher, and use that to burn your image to the microSD card.
    3. Remount the SD card and create a file on it called “ssh”.  Create another file called “wpa_supplicant.conf” with contains:
    4. This should enable you to boot the Zero-W. It should then get an an address for your LAN via DHCP. All you have to do is check you router, or use Fing (or something like it ) to find it.


Ah. Do you have another Pi with a wired connection somewhere about the place? Good.

Pop your microSD card from your new Pi-zero into an adapter and boot your other Pi (in my case one of my KODI boxes) and boot it.

Find the machine on your network and login (“pi” and “root” have the password “raspberry”).

As root, run

apt-get update
apt-get upgrade

And, while you have a wired connection, install Apache2 and PHP5.

apt-get install apache2
apt-get install php5

Set your new hostname in /etc/hostname now, so you’ll ne able to identify it later.

After thats done, shut it down, pop the card into the Pi-Zero W, and it should come up and appear on your network.

From Fing or your hub you should be able to get the MAC address and add the to your DHCP.

And it should all work.

Additional note concerning #3 above. If you are planning to use it on more that one WiFi network (example: I use my home network, and also the hotspot on my phone if I’m working on it anywhere but at home), your wpa_supplicant.conf file can contain multiple network entries.  Thusly:



Put the entries in order of preference.

Resurrection of the Dalek

At last I can paraphrase a Doctor Who serial title again.

This time I’m going to be using a Raspberry Pi-Zero W with MotoZero control board. Gone are the attempts at bashing by own circuitry (which are already in the Model Railway control system anyway), and this time IT WILL WORK!

So, the ingredients for *this* incarnation of the Dalek are:

For now I’ll forego the distance sensors, as I’ve already bashed them into a sort of thermin idea.

Anyway, the key stages for this project are:

To make things easier to track, the new Category Pi-Dalek has been created.


Death to the Arduino Dalek

Here I go again, repurposing shit. In this case it is both a Doctor Who episode title and some  electronic bits.

The Arduino Dalek/Raspberry Dalek project has been on hold for some time (obviously), due to me not being arsed to sort out a niggling wiring problem that only allowed one of the motors to run in one direction.  That and the camera melting itself into slag. That didn’t help.

Anyway, today it suffered a major setback when the Arduino and relays got removed for use in another project.

But Daleks never say die, so it might come back later.

The gubbins are being reassigned to Project Railway, and will act as the point motor control system, once I’ve worked the circuit design out.

Daleks Never Retreat

I’ve thought again about the problem of not being able to do bi-directional motors on the Dalek Project when using just one Piface Digital.

Why should the motors need to run backwards? Daleks never retreat! The only controls I’m going to need are Forward! Advance Left! and Advance Right! (and Exterminate!)

Looking back (which is something that Daleks can’t do anyway), the whole full movement thing came from my idea to build an Arduino Turtle (which was based on an idea developed from a Spectrum project from about 1985). But a Turtle is not a Dalek. Sure, they both have a hard shell and two driving wheels, but that is where the similarity ends.

So now we just need a web interface to control the Dalek’s movements forward, and to the sides a bit. All the while we need to be able to see what the Dalek sees from the on-board camera


Raspberry Pi Camera Module (of the Dalek)

So now I’ve bought the Camera Module for the Raspberry Pi. I got mine from Amazon, mainly as I was putting in a big order and was drunk enough to tag it on to the end.


Getting the damn thing set up and streaming video through a web page was a Pain In The Arse (which I know about)!

The only resource I could find that worked was Miguel Grinberg’s guide, but I still had problems with that. I suggest that you read his site, as it contains a lot more information. My version, below, is a quick run through, more for me to refer back to than anything else.

1. Build and Install the software

Run the following as root:

$ apt-get install libjpeg8-dev imagemagick libv4l-dev
$ ln -s /usr/include/linux/videodev2.h /usr/include/linux/videodev.h
$ wget
$ unzip
$ cd mjpg-streamer-code-182/mjpg-streamer $ make mjpg_streamer
$ sudo cp mjpg_streamer /usr/local/bin $ sudo cp /usr/local/lib/ $ sudo cp -R www /usr/local/www

2. Start the Camera and Streamer

Starting “raspistill” as suggested in Miguel’s guide dumped a lot of text to my xterm, making things really annoying, so I installed “screen” and ran the Camera software and the streamer in a different “screen”, which would also keep running after I logged off the machine (follow the oncreen prompts when you see them):

$ apt-get install screen
$ screen
$ mkdir /tmp/stream
$ raspistill --nopreview -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &
$ LD_LIBRARY_PATH=/usr/local/lib mjpg_streamer -i " -f /tmp/stream -n pic.jpg"
-o " -w /usr/local/www" & 

Dropping out of “screen” ( CRTL-A CTRL-D ) and back to a command prompt, and its all done.

3. Viewing the Stream

Fire up your favourite Browser (which I hope is Firefox) and access the site generate by th Pi. As the eventual goal of this whole thing a Wifi controlled toy Dalek drone, the hostname is “dalek”. Thus, on my network the address is:


You’ll have to substitute dalek for either the name of the machine on your network, or the IP address, eg:

You should be getting a web page with instructions on how it all works.

Short Version:

To grab a single from the camera:


To grab streaming video:


There other things you can play with, but those two are the only ones relevant to my little project.

Finally, an example of a still picture from the camera:

(Once again, full credit to Miguel Grinberg and his excellent guide.)

The Arduino Dalek Is Dead – Long Live The Raspberry Dalek

Well, it has been nearly two years since I looked at the Dalek project.

Last time I was looking at using a Raspberry Pi to control the Arduino, which would in turn control the motors in the Dalek.

Since then, I build my own Shield to fit the Arduino (and munged up the circuit design, rendering it useless), repurposed the USB camera that I bought to use in a security system, moved house, and generally forgot about the whole thing.

I’ve had a rethink over the last few days about the whole thing, and looking back on past ideas, I’ve come up with some better ones…

I’m replacing the Arduino with a PiFace Digital. This will solve most of the power problems. That, along with a Camera Module designed for the Pi will cut down on the USB sockets needed.

Pi with Piface Digital
Pi with Piface Digital

Next, for connectivity, I’m only having a WiFi dongle on the Pi, and a wired Ethernet socket on the outside case. Anything else is really going to be superfluous.

The question is, though, should it act as a WiFi hub, or should it connect to my existing network?

As the Piface Digital only has two SPDT relays on board, I’m going to use those to control the power on/off for the motors for now, just giving me forward movement for now. Eventually I plan to enable bi-direction operation on both motors, as was the case with the Arduino Dalek project before I made a balls-up of soldering the circuit. This time I won’t be trying to cram it all onto one small board, so it won’t be as hard to mess with.

A problem I have come across is that, unsurprisingly, the Piface Digital does not have any analogue inputs. This is going to make the distance sensors difficult to implement for now. I’m sure I’ll come up with something though.

So, for now the immediate goals are:

  • Get the motors working in one direction.
  • Get the Pi to either connect to my existing wireless network, or act as a WiFi hub

Protocol of the Ardunio Dalek

Ok, so now I’m just making Doctor Who episode titles up…

Anyway, while eagerly awaiting the release of the Raspberry Pi, which should be available within a month, I’ve been playing about with the communication method twixt Raspberry and Arduino.

As the ‘berry will be running Debian Linux, my Ubuntu server had been used as the test host, despite it being far too massive and heavy to be carried by the Dalek. I have a very long USB cable for such eventualities.

The plan has come down to initially sending single character commands to the Arduino over the serial port, and listening for a response. The responses will be a 5 character code with optional additional data.

The single character commands, their actions and return messages are:

Command Action Response
q Move forward and left MOVSF Ok
w Move forward MOVFF Ok
e Move forward and right MOVFS Ok
a Spin left MOVBF Ok
s Stop MOVSS Ok
d Spin right MOVFB Ok
z Move back and left MOVBS Ok
x Move back MOVBB Ok
c Move back and rigt MOVSB Ok
h Return last movement order MOTOR {motor status} Ok
v Return version number VERSN {version number}
l Get distance from left sensor DISTL {distance in cm}
r Get distance from right sensor DISTR {distance in cm}
  Unknown command UNKNW

So, here is the Arduino Sketch for this protocol:

// Project: Dalek control system – Receive and process commands from USB
// Version 1.0 (2012-02-09-09-06)
// Tony Blews

int MotorDirectionR = 10;
int MotorDirectionL = 11;
int MotorPowerR = 12;
int MotorPowerL = 13;
int IRPinLeft = 2;
int IPPinRight = 3;
String motorStatus = String (“”);

void setup()
pinMode(MotorDirectionR, OUTPUT);
pinMode(MotorDirectionL, OUTPUT);
pinMode(MotorPowerR, OUTPUT);
pinMode(MotorPowerL, OUTPUT);
motorStatus= String(“MOVSS”);
Serial.println(“START Serial control Dalek system starting…”);

void check_distance(int IRpin) {
float volts = analogRead(IRpin)*0.0048828125; // value from sensor * (5/1024) – if running 3.3.volts then change 5 to 3.3
float distance = 30*pow(volts, -1.10); // worked out from graph 65 = theretical distance / (1/Volts)S –
Serial.println(distance); // print the distance
delay(100); // arbitary wait time.

// modes for the motor control
// convention here is modeXX – where X is F for forward, S for stationary and B for backwards
// first X is the left motor, second X is the right one
// for direction control, the LOW if forward and HIGH is backward
// for power control, LOW is off and HIGH is on

// all stop
void modeSS()
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
motorStatus= String(“MOVSS Ok”);

// move straight ahead
void modeFF()
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
motorStatus= String(“MOVFF Ok”);

// move straight backwards
void modeBB()
digitalWrite(MotorDirectionR, HIGH);
digitalWrite(MotorDirectionL, HIGH);
motorStatus= String(“MOVBB Ok”);

// spin left
void modeBF()
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, HIGH);
motorStatus= String(“MOVBF Ok”);

//spin right
void modeFB()
digitalWrite(MotorDirectionR, HIGH);
digitalWrite(MotorDirectionL, LOW);
motorStatus= String(“MOVFB Ok”);

// move forward left
void modeSF()
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
motorStatus= String(“MOVSF Ok”);

// move forward right
void modeFS()
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
motorStatus= String(“MOVFS Ok”);

// move backward left
void modeSB()
digitalWrite(MotorDirectionR, HIGH);
digitalWrite(MotorDirectionL, LOW);
motorStatus= String(“MOVSB Ok”);

// move backward right
void modeBS()
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, HIGH);
motorStatus= String(“MOVBS Ok”);

//report distance left
void lookLeft()
Serial.print(“DISTL “);

//report distance right
void lookRight()
Serial.print(“DISTR “);

// report Status back to host
void helloDalek()
Serial.print(“MOTOR “);

//report software version
void reportVersion()
Serial.println(“VERSN 1.0”);

//main program loop
void loop()
if (Serial.available() >0)
char inByte =;
// this version uses the QWEASDZXC “square” on the keyboard
// as my laptop doesn’t have a numeric keypad
// L and R are used to “look” left and right for distance sensing
// H is for Hello. To report the status of the device.
switch (inByte)
case ‘q’:
case ‘w’:
case ‘e’:
case ‘a’:
case ‘s’:
case ‘d’:
case ‘z’:
case ‘x’:
case ‘c’:
case ‘l’:
case ‘r’:
case ‘h’:
case ‘v’:


Again, parts of this come from Lucky Larry‘s site.

And the C part:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <sys/ioctl.h>
#include <getopt.h>

void usage(void);
int serialport_init(const char* serialport, int baud);
int serialport_writebyte(int fd, uint8_t b);
int serialport_write(int fd, const char* str);
int serialport_read_until(int fd, char* buf, char until);

int main(int argc, char *argv[])
int fd = 0;
char serialport[256];
char buf[256];
int rc,n;

fd = serialport_init(“/dev/ttyUSB0”, B9600);
if(fd==-1) return -1;
rc = serialport_write(fd, buf);
if(rc==-1) return -1;
usleep(100 * 1000 ); // sleep milliseconds
serialport_read_until(fd, buf, ‘n’);
printf(“read: %sn”,buf);
} // end main

int serialport_write(int fd, const char* str)
int len = strlen(str);
int n = write(fd, str, len);
if( n!=len )
return -1;
return 0;

int serialport_read_until(int fd, char* buf, char until)
char b[1];
int i=0;
do {
int n = read(fd, b, 1); // read a char at a time
if( n==-1) return -1; // couldn’t read
if( n==0 ) {
usleep( 10 * 1000 ); // wait 10 msec try again
buf[i] = b[0]; i++;
} while( b[0] != until );

buf[i] = 0; // null terminate the string
return 0;

// takes the string name of the serial port (e.g. “/dev/tty.usbserial”,”COM1″)
// and a baud rate (bps) and connects to that port at that speed and 8N1.
// opens the port in fully raw mode so you can send binary data.
// returns valid fd, or -1 on error
int serialport_init(const char* serialport, int baud)
struct termios toptions;
int fd;

//fprintf(stderr,”init_serialport: opening port %s @ %d bpsn”,
// serialport,baud);

fd = open(serialport, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1) {
perror(“init_serialport: Unable to open port “);
return -1;

if (tcgetattr(fd, &toptions) < 0) {
perror(“init_serialport: Couldn’t get term attributes”);
return -1;
cfsetispeed(&toptions, B9600);
cfsetospeed(&toptions, B9600);

// 8N1
toptions.c_cflag &= ~PARENB;
toptions.c_cflag &= ~CSTOPB;
toptions.c_cflag &= ~CSIZE;
toptions.c_cflag |= CS8;
// no flow control
toptions.c_cflag &= ~CRTSCTS;

toptions.c_cflag |= CREAD | CLOCAL; // turn on READ & ignore ctrl lines
toptions.c_iflag &= ~(IXON | IXOFF | IXANY); // turn off s/w flow ctrl

toptions.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); // make raw
toptions.c_oflag &= ~OPOST; // make raw

// see:
toptions.c_cc[VMIN] = 0;
toptions.c_cc[VTIME] = 20;

if( tcsetattr(fd, TCSANOW, &toptions) < 0) {
perror(“init_serialport: Couldn’t set term attributes”);
return -1;

return fd;

This is a canibalisation of code from Tod Kurt‘s site.

My botch of this just takes a single character as a command line option, passes it the Arduino and prints the reply. eg:

$ ./dav s

read: MOVSS Ok

$ ./dav v

read: VERSN 1.0

$ ./dav l

read: DISTL 42.15

$ ./dav k

read: UKNWN

In other news, I’ve ordered a DIY Shield Kit from Amazon, so I can tidy up the hardware a bit, and a miniscule USB webcam which I intend to fit into the head part of the Dalek. I also plan to move all the clever bits of circuitry into to the top half, of the Dalek, and Meccano-up a set of brackets to hold the various battery sets that are needed in the bottom half.

The Arduino Dalek Master Plan – Episode 2

Looking back on my grand ideas, I’ve decided on a bit of a change of plan.

The current scheme will not have ports for video, or extraneous USB holes for keyboards and things of that ilk.

The current list of ports to stick on the Dalek is:

  • Ethernet – as i think I’ll need it in case the wifi fails
  • USB (using the already fitted port) for power while testing

The Raspberry will need USB for these:

  • Connection to the Arduino
  • Connection to the webcam (unless i can get a camera that uses the on-board connection)
  • Some form of microphone

So it still looks like I’ll need an unpowered hub.

It will also need a speaker connection for whatever sound output I decide to use.

Also, at some point i intend to get the ear lights working again.

Evolution of the Arduino Dalek

The DIY Arduino Shield Kit arrived from Amazon, and has been soldered up.

emptyshieldAnd it looks really boring, without the other parts stuck on it.

The parts in question are four 5v DPDT relays (Maplin part no N05AW – which seem to be out of stock a lot of the time, but are better that the alternative BT Type 47s, as the coil isn’t fussy about the polarity of the voltage), four 1N4004S diodes (part no QL78H), and a mess of wires. Rather than try to describe the layout, I’ve drawn a really bad diagram.

Circuit-ComponentsThis is the view from the component side. The yellow boxes show the relay placements, the four vertical block are the connections to the arduino. The Cyan areas are connections on the other side of the board, either whopping great solder blobs or lines joining the pads drawn with a pcb pen. The other technicolour lines are various wires.

Although that diagram gives the impression that I’ve used a double sided board, I haven’t. In retrospect that would have made things a lot easier.

Another collosal lack of planning (ie putting the Arduino header blocks too close to the top of the board) means that the Massively Ugly Blob Of Solder at the top sits directly over the ICSP header on the <a href="http://arduino best ed pills non”>Arduino Duemilanove that I’m using, requiring a bit of electrical tape to stop it shorting.

Here is what it looks like now, shitty soldering included for free:

2012-02-24-16.47.06 2012-02-24-16.47.19

Maybe you’ve spotted some things that aren’t on the diagram. Such as the 2 pin header, the two 3 pin headers and and 4 pin header. Well, the 2 pin is for the motor power input, and the 4 pin one is for the motor driver outputs. They were an afterthought, as were the two 3 pin headers which are for the distance sensors input, and are currently not connected. That bit comes next.