Evolution of a Blog

This blog has evolved as I have as a maker. It starts at the beginning of my journey where I began to re-tread my tires in the useful lore of micro electronics and the open-source software that can drive them. While building solutions around micro-electronics are still an occasional topic my more recent focus has been on the 3D Printing side of making.

Monday, March 25, 2013

RPi as a Remote Control for a Canon DSLR - Part 2

As with many others, I have had problems with gphoto2 running on the RPi due to USB issues.   It works for a single capture, if that, and then dies.   There is a lot of discussion out there about solutions with the idea of resetting the USB Bus high among them.   Others may have had success with this but I can not seem to get it to work.   I downloaded the code from this thread in the RPi forum, got it compiled, but on execution, could not get it to work as discussed!

I have, however, come up with another idea courtesy of angryelectron.  Their observation was that the problem occurs from opening and closing the camera as gphoto2 does for every transaction.   If you do a bunch of stuff between the open and the close you don't have a failure (until you do another open/close).  

The above suits me fine as I was not planning on using gphoto2 command line but was really looking to use libgphoto2 from Python via a wrapper developed by alexdu / piggyphoto.

My initial experiments are positive though I am still encountering failures though not until a significant number of previews and captures have been done.   I am going to continue to head down this direction.

Sunday, March 24, 2013

Handy, Cheap, Small Keyboard/Pointer

I bought this keyboard last week to save some space on my desk and have a mouse and keyboard with only one USB slot...all while not spending much money.   The reviews on Amazon were mixed but I bought it anyway and am quite pleased.   It is certainly not going to become a primary keyboard but it meets my requirements.   It worked with no fuss and no muss on both wheezy and arch.

Friday, March 22, 2013

Handy Directory of Arch Linux Utilities

The Arch Linux Wiki is the end all place for documentation on Arch...though Arch for the RPi is not necessarily what is documented there!   In any case this page of that wiki is particularly useful for finding a utility (like atool for archiving).

Thursday, March 21, 2013

Raspberry Pi Inventory

Somehow I have ended up with no less than four Raspberry Pi's.   I started with the one that I wanted to build the 'Bot around.   Then I decided that I needed one for development that I could mess with and not have to dismantle the 'Bot.   Since then I used one to save me having to drill a hole in the wall of our new house to run another TV antenna lead.

Then I fried the one that I had designated as my development platform (unfortunately it was one that does not appear to have a polyfuse on the USB circuit.  The CPU is ok as the device boots, displaying status to the monitor, but never makes a network connection nor can it talk to a keyboard :-(.

So I, obviously, had to buy a fourth RPi to serve as my development platform.  It arrived non functional so I ordered another one and in the meantime returned the non-functional unit for a refund.   Got a replacement instead and just decided to keep it.  Sad but true, I now have five of the little things working and one fried.  Cheap for the entertainment value provided!


RPi Current Use
1. Model B 256mb Fried.
2. Model B 512mb 'Bot - was running Wheezy now being ported to Arch
3. Model B 512mb TvHeadend - Serving TV to media clients (office and tablet).   Also host for ntop - running Wheezy
4. Model B 512mb Development - Miscellaneous uses
5. Model B 512mb Development - Currently being built as a CritterCam - running Wheezy.

Wireless Performance Issues on the RPis

I have been having intermittent performance issues on my wireless connections to my RPis.   As in the terminal or FTP sessions are either irritatingly slow or unusably slow.  
Unfortunately this is not a CPU usage issue. I can have the WLAN connection acting constipated while an Ethernet connection or the Console are humming along. 
I have multiple RPis and have had the problem with both Arch Linux and Wheezy running both Belkin N150 and Edimax dongles.
The Ethernet running well seems to rule out a USB issue (I think?) but that still leaves me baffled.  the choice of USB port for the dongle does seem to make a difference. In fact I may be chasing multiple problems as I have found that the remaining port on the RPi itself (after the other goes to the hub) provides the most reliable performance. Unfortunately this is not making any difference with my latest incarnation of the issue.
ifconfig shows pretty high rate of drops on rx and none on tx....but there are also drops on the ethernet connection rx side (though not nearly as high). I wonder if it is something on my network?
e now!

I am going to move my RPi environment to a second WLAN and see if that makes a difference. Before I do that, however, I am going to try and see if I can use ntop to shed any light on the situation. Really cool little tool. I have installed it on the RPi that serves up Live TV to my media clients. 
The question is...will I understand the output?

Wednesday, March 20, 2013

Arch Linux on the Raspberry Pi - Part 3 - 'Bot

The setup for my 'Bot running on Wheezy was described by an earlier post.   The below is a replication of that installation on Arch Linux based on the image that I described by the previous posts on this thread (Arch Linux on the Raspberry Pi).

With the base system built previously booted and running, I decided to work on installing the Arduino development environment.   It looked like I needed to download the source from the Arch User Repository (AUR) so I installed base-dev.   Interestingly there seemed to be a couple packages missing.  I did a "pacman -Syu"  (again as it had been done before for the image that I am using) and they downloaded!  There is a lesson here.  In any case it was all in vain as the source I downloaded apparently is not supported on the RPi!

Given the above I went to github and found the source code there and started to work on what it would take to get it to work.   I am still confused by what is needed so decided to defer the installation of the Arduino SDK.   I don't really need it running on the 'Bot as I can download the Py2Ard interface from one of my other workstations.

The 'Bot is written in Python V2 and relies on a number of Python extensions which is where I decided to begin:
pacman -S python2-imaging
pacman -S python2-pyserial

Once again there were some packages missing so I ran another synchronize.   I wonder if this was because pointers in one of the above packages were out of date?  I don't get it:
pacman -Syu
pacman -S python2 python2-numpy opencv 

With the above installed I went to test the webcam capture from within Python - it needs to be root??? I don't get this either!  I am using the shortest possible webcam capture script and it captures a zero length image without being root.

I don't actually use Python to capture my images given some issues with the camera dropping offline after a while so I pivoted to fswebcam and installed it now.  Note that I do use the above imaging libraries for a couple functions like creating an image of my radar map:
pacman - S fswebcam

My use of the GPIO bus requires one more library, again one that needed to be pulled down from GITHUB:

Finally, the last thing we need is a queue management solution called Beanstallk.  The architecture of my 'Bot is a little more complicated than it needs to be but I thought it would be cool to use some background Daemons with inter-process communications via Beanstalk.

No Arch Linux package exists for Beanstalk so I had to download the source and compile it on my target.   It seemed to work flawlessly:
git clone git://github.com/kr/beanstalkd.git 
install make
install gcc
sudo make install 

Now it was time to setup Beanstalk to run as a service per these instructions.  My approach was to create a service description file by cloning the one that proftpd created:
/usr/lib/systemd/system/proftpd.service -->         

Note that you may need to add your user name to a group, per the below, assuming you want to view logs generated by an error:
sudo systemctl start beanstalkd

I also created a directory for the PID as pointed to from the service file and pointed executable to /usr/local/bin/beanstalkd.

The service can be started once as shown below:
sudo systemctl start beanstalkd

Or started at boot:
sudo systemctl enable beanstalkd

Lastly, I found a version of the beanstalkc extension for Python and copied it into the directory with my Robot source code.

One important caveat.   Something is not working at the moment!   Beanstalk is not starting reliably.   More later.

Monday, March 18, 2013

Arch Linux on the Raspberry Pi - Part 2

It took some fumbling around as I wanted to see if I could get Gnome to work but decided it either would not or would be just to hard.   I don't need it anyway!   So I asked Google what the best GUI was for Arch Linux on the RPi and he/she told me to install LXDE - Lightweight X11 Desktop Environment.  

I got the steps below from a great recipe provided by sudo!Xanthippe for an LXDE install. Here are the steps that we need condensed from his tutorial:

pacman -Syu
pacman -S xorg
pacman -S xorg-xinit xorg-twm xterm

At this point sudo!Xanthipp added a user but we have already done that in the previous post.

I also installed two different VNC servers, tightvnc and tigervnc but am not sure about either at this point.  Both seem to crash now and again and both need post installation customization that might be user error.

At this point I feel that I have a pretty good base image replicating most of what comes in Rasbian "Wheezy" (plus some essentials).   Given this I am going to start forking a couple different images.   One for the 'bot of course (that is the title of the blog after all) and another for my BirdCam / RodentCam / WaterFowlCam (that is actually getting more attention right now)

On to Part 3

Saturday, March 16, 2013

Arch Linux on the Raspberry Pi - Part 1

As part of diagnosing my camera issues (previous post) I decided to try an installation of Arch Linux on the RPi.    My first two observations are that it is a LOT more complicated than Wheezy.   My second observation is that it boots REALLY FAST.   I decided at that point that I needed to try it for the 'bot where speed matter.

Here is my install procedure (in multiple installments):

Log in to the system as root, password root, upgrade your base system and catalogs to current revision levels:
pacman -Syu

This is crucial for finding the later packages to be installed!   I ran this from the console as it takes a while.   Once this is done you can use dfconfig to find the ip address so you can ssh in from your normal workstation.

Now configure some base stuff starting with an ftp server first (and have it start automatically):

pacman -S proftpd
systemctl enable proftpd.service

Then let's add the pi user:
useradd -m -g users -G \
audio,lp,optical,storage,video,wheel,games,power,scanner,ftp \
-s /bin/bash pi
passwd pi

Install sudo so we can use pi rather than root and maybe save our selves some future pain:
pacman -S sudo

Now run visudo and add pi with all rights.   Escape : x to save the file.
## User privilege specification
root ALL=(ALL) ALL

Now for the wireless network to auto start.   First install the network configuration tool:

pacman -S netcfg

Edit /etc/conf.d/netcfg as shown below (using your names of course!):

# Network profiles are found in /etc/network.d
NETWORKS=("ethernet-eth0" "wlan0-Daysleeper")

# Specify the name of your wired interface for net-auto-wired

# Specify the name of your wireless interface for net-auto-wireless

Create a network profile (in my case wlan0-Daysleeper) in /etc/network.d:
DESCRIPTION='Automatically generated profile by wifi-menu'

As you can see, this profile was generated by wifi-menu which is part of the netcfg package and can be run as "sudo wifi-menu wlan0" to build a profile for a wireless network.

Now make sure that the network configuration we have just created starts automagically:
sudo systemctl enable netcfg

More at https://wiki.archlinux.org/index.php/Netcfg#Net-Profiles

Time for a backup.   More to come as I continue to build an Arch Linux image to replace my current Wheezy image that runs the 'Bot.

On to Part 2

Friday, March 15, 2013

Backups Revisited

One of my early posts talked about doing backups of the RPi SD card.   At least part of that post was crap so I thought I would revisit with an explanation of what I am doing now which is simply to use dd.

I take my backups of both partitions of the SD card using the inverse of the restore commands shown below.

A restore is then done to an SD card formatted to the same specifications as the backup (assuming it is not the original).

For SD cards that I use for testing I am using 4gb cards as they backup and restore faster.   I might get some 2gb cards for that matter!

Restore commands:

    sudo dd bs=4M if=2013-08-03-base-image-1.img of=/dev/sdc1
    sudo dd bs=4M if=2013-08-03-base-image-2.img of=/dev/sdc2

RPi as a Remote Control for a Canon DSLR - Part 1

In the quest to play with more gadgets, and to get better image quality for my birdcam, I am going to try and integrate my Canon 500D with a Raspberry Pi.   The RPi will provide a wireless remote capable of motion detection and also for populating a web server with captured images.

I am going to base this on gphoto2 with the help of a Python binding that I found here.  The first step is to get gphoto2 working on the RPi in it's command line state.  Then I will download the Python binding and see if it works.

So, first, here is a condensed version of the build process from the various bits and bobs that I found across the above (and other) sources:
  1. Download the tarballs for libgphoto2 and gphoto2 from the gphoto2 website and expand them on the RPi.
  2. Install the precursor software that you will need automake, autoconf, gettext, (pkgconfig, make on Arch) for the builds
  3. The following should also be installed:      libusb-1.0-0-dev, libexif-dev, libpopt-dev, libfuse-dev, mono-devel, monodoc-base, mono-gmcs, python-pyrex, libtool, [libusb on Arch].
  4. Build libgphoto2 (./configure --prefix=/usr/local, make, sudo make install).  There are switches that will allow you to pick cameras to include.   If you just take the default for all cameras you can have a cup of tea during the make step!
  5. Now install the precursor software that you will need for the build of gphoto2 (assuming you are want the client even though most folks can not seem to get it to work (more later on my work around)!   Note that libpopt-dev, which is needed to the build here, was not found on Arch Linux?
  6. And build it (autoreconf -is, ./configure, make,  sudo make install).  Note that the instructions for building from the tarball did not say that you needed to do the autoreconf but I found it necessary.
  7. But...don't go and try and run gphoto2 unless you want to get this error message: "gphoto2: error while loading shared libraries: libgphoto2.so.6: cannot open shared object file: No such file or directory".   Edit /etc/ld.so.conf and add the line "/usr/local/lib" then run ldconfig as root.
  8. At this point you should be able to run "gphoto2 --auto-detect" and have it find your camera, or, "gphoto2 --capture-image-and-download" to take a picture.
I got through all of the above and then got an error doing a capture that I believe is due to the infamous RPi USB issues discussed at length on the Raspbery Pi Forums.

There are some references to possible work arounds on the web so I am going to do  some investigation.

Here are apt-get command lines for the precursor needs on wheezy:
sudo apt-get install -y automake autoconf gettext
sudo apt-get install -y automake autoconf  gettext libusb-1.0-0-dev libexif-dev libpopt-dev libfuse-dev mono-devel monodoc-base mono-gmcs python-pyrex libtool

Monday, March 4, 2013

Distracted! AGAIN!

Am still chasing the instability I mentioned in an earlier post and frankly it is not as much fun as trying new things.   This time it is setting up a Raspberry Pi as a webcam located in our bedroom and looking out at the Thames.   We just bought our place at the end of last year and much of our view of the river is sheltered during the summer by a big willow.   Last week the willow got a haircut and we now have an onobstructed view of the river from the 1st floor.   Hence the need for a webcam to bring this view down to my study!

I have struggled a little with getting one of the webcam solutions to work on my RPi.   I did finally get motion to work following the instructions here.  Unfortunately I can only seem to get a low resolution (320x240) to work.   Will update this post as I make progress.

Solved my resolution issue with the help of the RPi Forum and user Gomoto in particular.   As an aside I have to say how impressive the RPi Forum is in terms of the rapidity and quality of responses to a post.   In any case, here is a link to the solution.  Note this only applies to Python captures and does not seem to work for command line applications.

With resolution now working I was able to get my motion sensitive BirdCam to take these photos:

The motion detection in these photos is provided by a simple function that calculates the mean differences between two images (absdiff from opencv).   Given the simplicity of my requirement it works pretty well.   I do have to adjust for the threshold at which point I declare the motion to be interesting but it weeds out most of the chaff from wind movement and changing light.

I am still distracted by this line of interest.   In my next post I will describe the integration of the above technology with an SLR in the pursuit of improved image quality.