Category Archives: Dalek

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 https://www.raspberrypi.org/downloads/raspbian/ 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:
      update_config=1
      ctrl_interface=/var/run/wpa_supplicant
      
      network={
               scan_ssid=1
               ssid="yournetworkname"
               psk="yourpassword"
      }
      
    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.

IT DOESN’T WORK!

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.

 

 

 

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:

  • Getting the Pi and making it boot and connect to the Wifi network. – DONE
  • Stripping the unwanted circuits from the Dalek chassis – DONE
  • Getting the Motozero and wiring it up, and getting simple control from the command line
  • Designing the web interface and getting that to work.
  • Finding a camera, fitting it and getting that running.

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.

raspberry-pi-camera

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 http://sourceforge.net/code-snapshots/svn/m/mj/mjpg-streamer/code/mjpg-streamer-code-182.zip
$ unzip mjpg-streamer-code-182.zip
$ cd mjpg-streamer-code-182/mjpg-streamer $ make mjpg_streamer input_file.so output_http.so
$ sudo cp mjpg_streamer /usr/local/bin $ sudo cp output_http.so input_file.so /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 "input_file.so -f /tmp/stream -n pic.jpg"
-o "output_http.so -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:

http://dalek:8080/

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

http://192.168.0.203:8080/

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

Short Version:

To grab a single from the camera:

http://dalek:8080/?action=snapshot

To grab streaming video:

http://dalek:8080/?action=stream

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:

192.168.0.203

(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 tony@tonyblews.co.uk

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.begin(9600);
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 – luckylarry.co.uk
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);
digitalWrite(MotorPowerR,LOW);
digitalWrite(MotorPowerL,LOW);
motorStatus= String(“MOVSS Ok”);
Serial.println(motorStatus);
}

// move straight ahead
void modeFF()
{
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
digitalWrite(MotorPowerR,HIGH);
digitalWrite(MotorPowerL,HIGH);
motorStatus= String(“MOVFF Ok”);
Serial.println(motorStatus);
}

// move straight backwards
void modeBB()
{
digitalWrite(MotorDirectionR, HIGH);
digitalWrite(MotorDirectionL, HIGH);
digitalWrite(MotorPowerR,HIGH);
digitalWrite(MotorPowerL,HIGH);
motorStatus= String(“MOVBB Ok”);
Serial.println(motorStatus);
}

// spin left
void modeBF()
{
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, HIGH);
digitalWrite(MotorPowerR,HIGH);
digitalWrite(MotorPowerL,HIGH);
motorStatus= String(“MOVBF Ok”);
Serial.println(motorStatus);
}

//spin right
void modeFB()
{
digitalWrite(MotorDirectionR, HIGH);
digitalWrite(MotorDirectionL, LOW);
digitalWrite(MotorPowerR,HIGH);
digitalWrite(MotorPowerL,HIGH);
motorStatus= String(“MOVFB Ok”);
Serial.println(motorStatus);
}

// move forward left
void modeSF()
{
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
digitalWrite(MotorPowerR,HIGH);
digitalWrite(MotorPowerL,LOW);
motorStatus= String(“MOVSF Ok”);
Serial.println(motorStatus);
}

// move forward right
void modeFS()
{
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, LOW);
digitalWrite(MotorPowerR,LOW);
digitalWrite(MotorPowerL,HIGH);
motorStatus= String(“MOVFS Ok”);
Serial.println(motorStatus);
}

// move backward left
void modeSB()
{
digitalWrite(MotorDirectionR, HIGH);
digitalWrite(MotorDirectionL, LOW);
digitalWrite(MotorPowerR,HIGH);
digitalWrite(MotorPowerL,LOW);
motorStatus= String(“MOVSB Ok”);
Serial.println(motorStatus);
}

// move backward right
void modeBS()
{
digitalWrite(MotorDirectionR, LOW);
digitalWrite(MotorDirectionL, HIGH);
digitalWrite(MotorPowerR,LOW);
digitalWrite(MotorPowerL,HIGH);
motorStatus= String(“MOVBS Ok”);
Serial.println(motorStatus);
}

//report distance left
void lookLeft()
{
Serial.print(“DISTL “);
check_distance(2);
}

//report distance right
void lookRight()
{
Serial.print(“DISTR “);
check_distance(3);
}

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

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

//main program loop
void loop()
{
if (Serial.available() >0)
{
char inByte = Serial.read();
// 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’:
modeSF();
break;
case ‘w’:
modeFF();
break;
case ‘e’:
modeFS();
break;
case ‘a’:
modeBF();
break;
case ‘s’:
modeSS();
break;
case ‘d’:
modeFB();
break;
case ‘z’:
modeBS();
break;
case ‘x’:
modeBB();
break;
case ‘c’:
modeSB();
break;
case ‘l’:
lookLeft();
break;
case ‘r’:
lookRight();
break;
case ‘h’:
helloDalek();
break;
case ‘v’:
reportVersion();
break;

default:
Serial.println(“UKNWN”);
break;
}
}
}

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;
strcpy(buf,argv[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);
exit(EXIT_SUCCESS);
} // 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
continue;
}
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: http://unixwiz.net/techtips/termios-vmin-vtime.html
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 prescription.cc/en/Main/arduinoBoardDuemilanove”>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.

The Arduino Dalek Master Plan

All has been quiet on the Arduino Dalek front for a while now, as I’ve stopped all work on it pending the release of the Raspberry Pi credit card sized sub-£20 computer

For those not in the know, the Raspberry Pi will be an ARM11 700Mhz based computer running Debian Linux and capable of operating from 4 AA batteries. The “Model B” will have 2 USB ports and on-board ethernet.

There will be plenty of space inside the Dalek to accommodate one of these, along with the extra battery packs required.

So, assuming that they start shipping these things soon, the Master Plan (oh just guess where the title of this post is derived from) is:

  • Strip down the existing code for the Arduino version so that it just accepts commands to drive the motors and read the sensor data (pretty much like version 0.1 did).
  • Work up a protocol for the Raspberry and Arduino to communicate with. Then implement it.
  • Fit the Dalek with all the connectors for the Raspberry (RCA, HDMI, Ethernet, USB via an unpowered hub, Audio jack and micro-USB power)
  • Recode the current “free-roaming” software to run on the Raspberry.
  • Source a suitable USB WiFi dongle and camera to install.
  • Jig up a web based “Control Panel” for the beastie.

The above list includes “USB via an unpowered hub”, as I currently envision needing more than 2 USB ports:

  • USB connection to the Arduino (direct)
  • USB WiFi dongle (via hub)
  • USB Keyboard (via hub on case exterior)
  • USB Mouse (via hub on case exterior)
  • USB Memory stick/Disk interface (via hub on case exterior)

Now why, you may be thinking, would I be needing the keyboard, mouse and storage (and video outputs)?

Well, the objectives are now two-fold. Primarily I still want to build the original free-roaming robot idea, but I also want it to double as a cool set-top box to connect to our stupidly large television which has been gathering dust since the Digital Switchover (our TV aerial is really shite and Freeview is UNWATCHABLE).

I could do that using a second Raspberry as a dedicated set-top box, but that would not be as cool.

Imagine: The Dalek is connected to the TV, playing a copy of an old Doctor Who episode featuring Daleks. The on-board camera is pointing at the TV, relaying the images to a web server. So a Dalek is watching a Dalek on a Dalek (not in that way). Open up another window and the Dalek is also watching itself. Thats the kind of thing that Christopher H. Bidmead could only dream about.

I’ll be buying a second one anyway, to it inside one of these keyboards.

But as I said, it is all on hold until the Raspberry Pi ships (and I remember how to program in C again).

Then maybe I can actually make use of the contrived acronyms DAVROS (Dalek Automatic Roving Vehicle Operating System), and SKARO (Stupid Kludged Arduino Remote Operation).