Catmaker's Blog

Ramblings of a Robot Cat Maker Wannabee, Because Real Cats Aren't Allowed :P

Archive for the ‘Uncategorized’ Category

Arch Linux ARM on Pi

leave a comment »

I do this over, and over again. I own quite a few Pi’s. There a couple of permanently-powered ones — my RaspBMC media centre attached to my living room TV, and there’s the one on my worktable’s bulletin notice which is where I perform my day-to-day general coding and testing.

I do have a panel of 4x Pi’s which some buddies call it a cluster. That too is permanently powered. But it isn’t really a computing cluster, it’s there for me to test power consumption and further inspire to read on power manangement techniques. I also have a couple more Pi’s in my wannabee robots; Hagar the rover and Mosfet the cat.

Where does all the above leave me? Everytime I pass by a shop that has a cheap SDcard , or a bigger one which is affordable, or a better one with higher performance, which happens every two or three months: I get the itch to upgrade! Also, everytime there’s a new Operating System distribution image uploaded to the Internet: upgrade!

Why is this a problem? Imaging an SDcard over, and over again is tedious. Even though I do this quite “repeatedly”, I tend to forget some steps. Yeah, yeah I have these steps written down in text file notes here and there, in a notebook too, but the steps aren’t always the same, and sometimes making sense out of different notes is totally confusing. So here I am: I shall (hopefully) use this page as the final one for myself.

Step 1: goto archlinuxarm.org and pull the image…
… flash it
… resize it

… mount it

… change hostname

… copy /etc/hosts from known source

… copy /etc/skel/.* from known source

adnan@pav:~$ ssh -Y mosfet

adnan@mosfet’s password:
X11 forwarding request failed on channel 0
Last login: Thu Jan 1 07:30:22 1970 from pav

edit /etc/ssh/sshd_config

#X11Forwarding no
# test 2 – must set next line
X11Forwarding yes

Written by catmaker

2013/09/01 at 11:16

Raspy Juice Reworked

with one comment

Reworking the revised Raspy Juice Expansion Board left my table a mess!

Saturday Evening Mess

All that because I received this on Friday… 2 panels of 4 printed circuit boards (PCB) of a revised version (Rev.1) for my Project Raspy Juice, an experimental expansion board for the Raspberry Pi low-cost educational computer.

Panel of 4 Raspy Juice Rev.1 PCB

Manually soldering up tiny surface-mount devices (SMD) onto a single PCB can be time-consuming, especially when there are many different types of component devices. I used to do that with an older revision of the above PCB when it came in single-unit pieces. Like the pictures below… Just to solder up the components of the below single-unit PCB into the one on the below-right would take me a good whole morning.

Single-unit PCB into…

a completed Raspy Juice Rev.0

Anyway, on Saturday, in the same time I used to populate one PCB in the past, I managed to solder up 4 PCB’s in one go. Here’s a picture of the completed panel being washed in the basin…

Washing, and…

Left to dry. (Just kidding, compressed air-jet and hot-air blower was used, really 😎

A quick ‘smoke’ test was done just to see if the main circuits still work.

Powering up of one Raspy Juice in the panel-of-4.

You know, I hate to see the panel of 4 PCBA  being ‘broken’ up to actually use it for the Raspberry Pi purpose — it felt like a nice piece of work. Anyways… yyeeeaarrrrgghhh!!! There it goes >>>>>

Raspy [cracking noises] Juice Rev.1 PCB’s

And a picture of the old versus the new…

So… Why a revised Raspy Juice Rev.1? I just couldn’t stand it that, mechanically, the PCB didn’t sit on the Raspberry Pi PCB properly.

  1. The dimensions of the old version were just a little off.
  2. The stereo jack that provided for the serial port console was also too near to the Raspberry Pi HDMI socket.
  3. The power socket near the top-left of each PCBA was incorrectly oriented, and the power wires that came out of it rubbed against the pins of another header.
  4. The seven JST connectors all had electrically incorrect orientation.
  5. Other than the above, only some minor electrical alterations were updated in the electronics.

To be continued…

Written by catmaker

2012/07/25 at 17:05

Posted in Uncategorized

Tagged with ,

Raspberry Pi To Do List

leave a comment »

BWAR HAR HAR HAR!!! (Megalomaniac laughter :-)) I’ve just popped over to element14 to self-collect my Raspberry Pi !!!

When I got a call yesterday late afternoon, I was squealing (like a school girl). But when I reached there then, their employees were already knocking off work and streaming out — I was too late! Arrgh!!!

Finally this morning, my Raspberry Pi is in my hands! Three months of anxious waiting, and all this time, I have designed and pre-built a DIY expansion board for it called Raspy Juice. I was and still am, overcome with excitement to try out my expansion board. BUT, I’d better practise some self-control and go through the rigmarole of baby-steps of testing the Pi “AS-IS’ first. So, this blog is just to cool me down and make a To Do list.

A bit about the Pi and my project: Raspberry Pi (the gadget) is an extremely low-cost, small credit-card sized, relatively high-computational power and low-power consumption Single-Board Computer. It was designed and promoted by the UK-based Raspberry Pi Foundation as a means to enhance a more hands-on approach to computer-science education to students all over the world. In this day and age where computers are used as consumer devices where one would only need to mouse-it, swipe, touch, prod, etc., we forget how complex the inner workings of a computer are.

The Raspberry Pi Computer

My Raspy Juice Expansion Board

And today, a computer is just another handy gadget — a display panel with some user-interface mainly for browsing, reading and, gaming. To get youngsters to learn about computers, programming and maybe some electronics, I thought it’d be fun to add some “do this, and get that” kind of effect. Like some blinking lights, or mechanical movement. So, Raspy Juice is an expansion board to allow this Raspberry Pi computer connect to controllable motors (they’re called RC Servos) to make things move. Well, it’s really more than that: but I just want to keep this short. (Oooyah: As I’m writing this, my Pi is staring at me, calling, calling, calling, “power me up!!!” Resist, resist, I must resist).

And so, the baby-steps TO DO list:

  • Borrow nephew’s spare Dell LCD monitor with HDMI input.
  • Where is my microUSB +5volt power adapter?
  • Find an SD card and load it with the foundation’s standard linux distribution. Probably Debian.
  • Test with LCD monitor, mouse and keyboard!!!
  • Practise the boot up sequence.
  • Go through my ‘new’ linux distri routines: dmesg, drivers, networking, date/time, update/upgrade, free, mounts.
  • Add jed, emacs, less, psmisc, wpa, dropbear, ssh.
  • Test USB hubs.
  • Test USB wifi adapters.
  • Test USB webcam adapters.
  • Test USB audio adapter.
  • Test USB external HDDs.
  • Add my pet interest linux applications: alsa, mpg123, espeak, motion, mjpg-streamer, etc.
  • Add some linux helpers: samba, ntfs-3g, usbmount, i2ctools.
  • Add some linux services: lighttpd, php-cgi, qbittorent-nox.
  • Find kernel sources and try to rebuild kernel, with I2C drivers.
  • Try to restart standard distri with new kernel.
  • Test Pi with +5V through the GPIO header pins.
  • Hold breath and test Pi with Raspy Juice.
  • Test the console.
  • Test I2C bus with i2ctools.
  • Test Raspy Juice-powered USB external HDDs.
  • Test Raspy Juice-powered RC servos motors.

And more to come:

Written by catmaker

2012/06/01 at 17:50

Cross Compile a Beagleboard ARM OpenCV Application

leave a comment »

Why is cross-compiling so difficult? Because the libraries aren’t there!

What I have:

An Ubuntu desktop running oneiric ocelot. Some OMAP3-based boards like beagleboards B5’s and C2’s, gumstix overo fires, and IGEP modules on self-built baseboards. But for this blog, I’ll just refer to all these experiments as for the beagleboard.

What the OMAP’s are running and are for:

Mostly linaro oneirics on rebuilt linux 3.1.2, running OpenCV experiments. Only one of the beagleboards (the C2) is connected to a VGA monitor, and it’s running the linaro ALIP (generally an XFCE based X), the rest of them are headless.

So far:

All of them can compile OpenCV applications natively on themselves. But the compiler and tools like g++, svn, etc is so slow.

Why do I want cross-compile on my desktop?
  1. Faster compilation!
  2. Better tools like emacs (or vi if you like it). Personally I’ve installed and use jed on the beagleboards — it’s small and fast, but I still prefer my emacs on the desktop anytime.
  3. Tools on my desktop like subversion svn to my repository also feels faster.
  4. Testing the same code on my desktop is also convenient. My desktop is, well, graphical: I can easily add/modify code to use the display components of opencv on my desktop, instead of guessing around results from my headless toys.
What’s already in place:

Rebuilding the ARM kernel on the desktop already fulfils some of the requirements of cross-compilation an application for the beagleboard.

sudo apt-get install build-essential arm-linux-gnueabi-gcc etc,etc.

With the above tools already installed, I could already compile and transfer a simple hello.c program.

me@desktop:~$ arm-linux-gnueabi-gcc hello.c -o hello.bin
me@desktop:~$ scp hello.bin me@beagle:
me@desktop:~$ ssh me@beagle

me@beagle:~$
me@beagle:~$ ./hello.bin
Hello, world!
me@beagle:~$

When that above application runs, I thinks the runtime startup libraries and the Standard C libraries libc for the arm are already in place.

So whaabout compiling something bigger?

Like an OpenCV application? With its application-specific shared libraries? Hmmm, here’s the example code from opencv webcam capture-and-show application:

/*
http://opencv.willowgarage.com/documentation/cpp/ \
highgui_reading_and_writing_images_and_video.html#videocapture
*/

#include <opencv/cv.h>
#include <opencv/highgui.h>
using namespace cv;

int main(int, char**)
{
    VideoCapture cap(0); // open the default camera
    if (!cap.isOpened()) // check if we succeeded
        return -1;

    Mat edges;
    namedWindow("edges", 1);
    for (;;) {
        Mat frame;
        cap >> frame;   // get a new frame from camera
        cvtColor(frame, edges, CV_BGR2GRAY);
        GaussianBlur(edges, edges, Size(7, 7), 1.5, 1.5);
        Canny(edges, edges, 0, 30, 3);
        imshow("edges", edges);
        if (waitKey(30) >= 0)
            break;
    }
    return 0;
}

And compiling the above with:

me@desktop:~$ arm-linux-gnueabi-g++ opencv_camshow.cpp -o opencv_camshow.bin \
              `pkg-config --libs opencv`
Epic failure!
  1. The arm-based libraries cannot be found.
  2. The pkg-config command returned the correct library names, but the linker tried to use my ubuntu-desktop’s x86 opencv library files instead.
  3. And the arm-based opencv libraries weren’t installed in the first place!

Natively compiling the above on my beagleboard isn’t a problem at all: Generally, all I had to do to compile an opencv application, the libraries required are installed by “apt-get install libcv-dev libhighgui-dev libcvaux-dev” and all their dependencies (like libgtk2.0, etc) will automatically be installed also.

But on my i386 ubuntu desktop, these arm-based cross libraries must be pre-installed before the arm-linux-gnueabi compiler can use them. With help from blogs, help forums and tutorials I found (see my references below), I only just managed to learn how to install these cross libraries. The directory location where arm-linux-gnueabi-g++ searches for these arm-based libraries are in /usr/arm-linux-gnueabi/lib

The desktop tool used to install arm-based cross libraries is called xapt, which like apt-get, but downloads and installs cross-architecture packages. And I had to add a one-liner file of /etc/apt/sources.list.d/armel-oneiric.list for it to work.
Also, the pkg-config tool to be used instead is the arm-linux-gnueabi-pkg-config which I found in a linaro blog tutorial. (It’s also available as an ubuntu-precise package as pkg-config-arm-linux-gnueabi, but I’m running oneiric).

me@desktop:~$ sudo apt-get install xapt
me#desktop:~$ sudo sh -c "echo deb [arch=armel] http://ports.ubuntu.com/ \
              oneiric main restricted universe multiverse \
              >> /etc/apt/sources.list.d/armel-oneiric.list"

me@desktop:~$ sudo wget 'https://wiki.linaro.org/PeterMaydell/A15OnFastModels\
?action=AttachFile&do=get&target=arm-linux-gnueabi-pkg-config' \
-O /usr/bin/arm-linux-gnueabi-pkg-config
me@desktop:~$ sudo chmod 755 /usr/bin/arm-linux-gnueabi-pkg-config

me@desktop:~$ sudo xapt -a armel -m libv4l-dev libgtk2.0-dev \
              libcv-dev libcvaux-dev libhighgui-dev

me@desktop:~$ arm-linux-gnueabi-g++ opencv_camshow.cpp -o opencv_camshow.bin \
              `arm-linux-gnueabi-pkg-config --libs opencv`

Still fails @#%$!!! — The compiler complains of missing libblas and liblapack!

me@desktop:~$ dpkg -l | grep liblas-armel-cross
me@desktop:~$ dpkg -l | grep liblapack-armel-cross

shows they’re installed, but the libraries just aren’t there in /usr/arm-linux-gnueabi/lib/…

Ahhhh! What to do? Copy over the natives from my beagleboard which are in /usr/lib/libblas and/usr/lib/lapack over to my ubuntu-desktop /usr/arm-linux-gnueabi/lib

me@desktop:~$ sudo scp -r beagle:/usr/lib/*libblas* \
              beagle:/usr/lib/*lapack* \
              /usr/arm-linux-gnueabi/lib
me@desktop:~$ arm-linux-gnueabi-g++ opencv_camshow.cpp -o opencv_camshow.bin \
              `arm-linux-gnueabi-pkg-config --libs opencv`

and compile! OK!! Finally builds!!! Copying over to my beagleboard…

me@desktop:~$ scp opencv_camshow.bin me@beagle:
me@desktop:~$ ssh -Y me@beagle

me@beagle:~$
me@beagle:~$ ./opencv_camshow.bin
    #(Here, the application starts on my desktop in an Xwin and shows the webcam capture. Hooo!!!)
me@beagle:~$^C


Awww… OK, I still have a problem with the libblas3gf-armel-cross and liblapack3gf-armel-cross arm packages. But, I’m so relieved that cross-compiling can be made to work after all.

My references:

Written by catmaker

2011/12/21 at 16:29

Ubuntu Serial Converter udev Rules

leave a comment »

On my (recently-updated Oneiric 11.10) desktop Ubuntu, my FTDI-based serial converter just couldn’t be opened by a non-root user, either for the screen command, or the GUI-based terminal application putty. The /dev/ttyUSBxxx device node was instantiated with mode 0660 to owner root:dialout and, even when I’m in the groups dialout, the permissions wouldn’t just let me access it.

My quick-and-dirty solution was to add the below overriding udev rule-file as /etc/udev/rules.d/10-local-override.rules :

# /etc/udev/rules.d/10-local-override.rules
# Local rule to override distribution's rules of putting my
# FTDI-based serial convertor mode to 0666 instead of 0660.
# 
# References:
# http://www.cl.cam.ac.uk/research/dtg/research/wiki/Udev
# http://www.reactivated.net/writing_udev_rules.html
#
KERNEl=="ttyUSB*", MODE="0666"

# Previous attempt, but I use other serial-converters too.
#ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", MODE="0666"

Written by catmaker

2011/10/18 at 11:56

Posted in Uncategorized

Tagged with , , ,

Previous Attempts

leave a comment »

Hi there,

I’ve a long history of attempting to build a robot as a hobby. None of them have been successful – either by lack of parts, lack of skill or knowledge, or procrastination. Maybe also because of too much thinking, and not enough ‘do’. I found some of these items still lying around…

Around 1995

My first attempt, if my memory serves, came after Altavista searching popped up a robot on an MIT research on micro-ants. Wooo, that looks interesting, I thought — many little robots zipping across my desk, and they look manageable. So I acquired these chain and sprockets as samples. It helped that I was in the electronics industry, close to manufacturing, so an automation vendor helped me get them as samples.

Image of chain and sprockets

Chain and Sprockets

Hoping to make this…

microant-fingrant-50

Microant from MIT

Details of this robot and its research can still be found at  http://www.ai.mit.edu/projects/ants/ and, its category title lists it now as ‘Retired Robots’.

My attempt — FAILED.

1996 – onwards

So there my quest for robot parts began…

Image of wheels

Wheels and Castors

Image of motors

Motors

Image of random parts

Random Parts...

Things I did with them —NOT A LOT: But the collection gets bigger every year…

Around 2002

Sometime in late 2001 or 2002, I really forget when, some UK magazine started a series called Real Robots and was sold in the newsstands down here. It was a fortnightly, and came with robot parts with which one was supposed to collect and assemble into a full working rover. I have my 2 very, very young kids then, so I bought the mags in pairs. If I remember then, it wasn’t released to our newsstands consistently every 2 weeks; I eventually gave up and never got past the 6th(?) issue. That was that.

Image of cybots

Cybots: That's them today...

A search in Wikipedia now lists this robot and its magazine as End of Series.

This attempt — ALSO FAILED.

Late 2009

I was bored last year, so I started designing a few pieces of test electronics tools. These were small circuits on little 30 x 30mm boards. I managed to include some electronics as motor and servo controllers, battery power regulators and other stuff. It kind of grew into a body with some motors and a servo attached to it. It moved for a little while , but it also looked like a terrible hack. So I decided to name it ‘Hgar the Terrible’.

Image of Hgar

Hgar the Terrible, perched on top of a power supply

Why is it sitting up there and not on the ground? Because it doesn’t run straight, and keeps bumping into furniture even though it has sensors for avoidance. One day, just one day, I may get back to its programming and improve its attitude. But for now…

This attempt — Danger of Procrastination. ALMOST FAILING.

February 2010

An old buddy of mine came to me for some electronics and software help in his robotics hobby project. Initially, he wanted to build a hexapod. A little later, it was to be a quadruped. Finally, a biped. I got started on some programming for the feet motion, but these conceptual changes made it hard for me to focus on its programming, and the spirit finally kind of dissipated.

Image of pbot

Semi-built Hexa? Quadru? Bi? -pedal Robot

Anyway, the limbs look like an insectoid. I hate bugs.

This attempt — ALSO FAILED.

June 2010

I NOW WANT A ROBOT CAT!!!

Good luck to me.

Written by catmaker

2010/07/02 at 09:40

Posted in Uncategorized

Tagged with ,

Robot Relish Rekindled

leave a comment »

RoboCup2010 Banner

RoboCup2010 Banner

This is the last week of the school holidays and I took a day off from work to bring the kids to RoboCup 2010 Annual Robotics Soccer Competition. Held at the Suntec Convention Center in Singapore, it certainly made for a fun family outing. Just seeing the kids’ eyes light up at the robots (attempting to) play soccer games, and all the delightful exhibits, has rekindled my desire to restart a robotics project.

RoboCup 2010 Match 1

First RoboCup 2010 Match we Watched

I WANT A ROBOT CAT!!!

Written by catmaker

2010/06/29 at 00:52

Posted in Uncategorized

Tagged with ,