Prototype APC OPACThanks to the good folks at VIA Technologies, we recently received an APC Android PC for evaluation. The device comes with a VIA 800MHz processor, 512MB of RAM, 2GB NAND flash RAM, VGA, HDMI, 4 x USB, audio in/out, 10/100 ethernet and a microSD card slot. All at a $49 list price and in a 170 x 85mm form factor (about 3.3 x 6.6 inches). It’s also capable of 720p resolution video.

We are currently evaluating its potential application as an Online Public Access Catalog (OPAC), said system needing only to provide a web browser running in fullscreen kiosk mode–nothing more. In order to provide a more robust set of features for the browser, we decided to install Mike Thompson’s bootable Raspbian Apricot image of Linux on a microSD card, which the device supports. While the operating system image is meant to fit on a 2GB SD card, we’re using an 8GB SD card, so I resized the partition after the image was installed in order to utilize the entire capacity of the card.

That version of Raspbian (Raspberry + Debian) comes with the Midori web browser which I and others found to crash all too easily, at least under this particular Raspbian OS. In particular, it would crash every time I accessed either our website or our catalog (obviously a deal-breaker right there). My first choice for a browser would have been Opera, as it has an extensive set of features geared for kiosk presentation. Unfortunately, I was unable to find a version of it that would run on Raspbian; however, I have since located a version of Chromium (the Linux version of the Google Chrome browser) that was compiled for the Raspbian OS and I was able to install it without any issues.

Chromium appears to be relatively stable, having crashed only when trying to access pages with a huge amount of content, primarily those “bottomless” pages that continually retrieve and display more content as you scroll to the bottom (as with the Google Chrome app store or some Facebook pages). There’s one display refresh anomaly in that the mouse pointer disappears at certain times, particularly when a page finishes rendering; however, it reappears when one moves the mouse—and it’s not limited to use of the browser, as it also occurs on the Mate X-windows desktop that’s bundled with this version of Raspbian.

The only Chromium extension that was installed is IdleReset 1.1.1, which resets the user session, clearing all cookies and returning to the homepage. Its idle reset timer is set to 90 seconds (as it is with our current OPACs using Opera’s built in idle reset feature).
Command line switches provide the other necessary features. For our purposes, Chromium is launched with the the following command:

/opt/google/chrome/chrome –-disable-ipv6 –-kiosk --proxy-pac-url=[address for proxy autoconfiguration script] [homepage]

The above launches Chromium without IPv6 support (so as to maximize performance in non-IPv6 networks), it enables fullscreen kiosk mode, it applies our proxy autoconfiguration script and it launches our homepage.

As for locking things down, autologin was enabled and the Mate X-Windows launch panel was stripped of as many menu selections as possible. In addition, once I had the Chromium settings configured appropriately, I copied the configuration files to a separate directory (basically, a repository of restorable safe settings). Finally, I wrote two scripts that are almost identical to each other. Both scripts basically do four things: 1) checks to see if the other script is running, and if so, kills it; 2) overwrites the Chromium configuration files with the “safe settings” config files; 3) launches Chromium with the appropriate command line switches; and 4) checks to see if Chromium is running, and if not, launches the other script. The first script, opac.sh, reads thusly (assuming that Chromium is run by user opac and that the backup directory is chromiumback in the user’s home directory):

#!/sh
# Before we do anything else, kill opac2.sh if it's running
pkill -15 opac2.sh
# Revert settings to known safe ones
cp -pRf /home/opac/chromiumback/* /home/opac/.config/chromium/
# Launch Chromium; disable IPv6, use kiosk mode, specify proxy script and open homepage
/opt/google/chrome/chrome –-disable-ipv6 –-kiosk --proxy-pac-url=[address for proxy autoconfiguration script] [homepage]
# Check to see if user closed Chromium; if so, launch via the second script
ps -ef | grep -v grep | grep chrome
if [ $? -eq 1 ]
then
/home/opac/opac2.sh
else
exit
fi
exit

The second script, opac2.sh, is identical to the script above, except that all references to opac2.sh as they appear above would be replaced with opac.sh. The use of the two scripts in this manner effectively provides a watchdog that ensures the browser is running in kiosk mode at all times.

I’m confident at this point that the APC would satisfy our needs for a very low cost, low power and small footprint OPAC system, especially if the Raspbian OS and compatible app development continues at the current pace. I’ve no doubt too that some performance tuning can be done to eke out better performance, which at this point is actually quite acceptable. The system board is now mounted in Mike Thompson’s clear acrylic snap-together case and it’s now prominently deployed as “Our New, Low Cost Experimental Online Catalog PC.” We’ll be sure to report on how well it performs in addition to what our patrons have to say about it.

John Lolis
Manager, Information Technology

John's Email
Tagged with:  

5 Responses to The Use of a Raspbian-based APC as an OPAC Kiosk System

  1. John H says:

    Love what you have done with that.
    How is this system working for you?
    I’m considering something similar for an internet cafe in the Philippines. With a network hard drive to store as much popular content as possible. Hopefully books for the local college and such as well.

    The problem I see is their aren’t good Cafe management software’s for Raspbian. Cant even find updated ones for Ubuntu but 9-10 are supported in at least one which works with widows also.

    I wonder if Android 4 might be better? But their aren’t Cafe management software’s for that either. Not being a programer myself I don’t really know what would be best.

  2. John Lolis says:

    Thanks for the good word. It’s actually been working out quite well. It’s been pretty stable and only slightly slower than our conventional catalog systems. It’s probably not even noticeable unless you’re really looking into how it compares.

    If you’re looking for something that would lend itself to general use as an internet public access system, I’d have to say that the APC still needs to mature in terms of online application support. For example, from what I’ve found, there’s as yet no Adobe Flash support for Raspbian on an ARM processor (and with Flash on its way out, there may never be support for it). Also, for your application, if you’re looking to offer managed, timed sessions to your patrons, you’ll have to come up with a 3rd party app or write one of your own to use with the APC. On the WEB4LIB listserv, there’s been a great discussion regarding the use of the APC, Raspberry Pi and even tablets for public use, but nothing with regard to internet café use. One contributor suggested this: http://userful.com/. I have no idea what the cost is or how well it works, but it sounds like a very nice solution and one that would lend itself well for your needs.

    I think that you have a great idea there. I wish you much success with it.

    John

  3. Is printing possible from the RP/Raspbian model? Our OPACs are also used for access to our subscribed databases, and many customers print out info from these databases.

    • John Lolis says:

      From what I could find, it appears that it is possible to print using CUPS with a raw print driver (see Raspbian and CUPS); however, my strategy is to implement a driverless cloud printing solution, such as PrinterOn, PaperCut, Print Manager, Google Cloud Print, etc. Being web-based, it not only avoids the need to install and configure something like CUPS on the APC or Pi, but such a solution would be much more universal in its application–it’s platform and device independent, and would allow remote as well as wireless submission of print jobs. Cost recovery is a necessary feature for us, so I’ll also be taking that into account when I start comparing and evaluating these print management solutions.

  4. Evan Miller says:

    This is fascinating! One thing I’m wondering: I want to do something similar, but want my users to be able to access PDF documents from my shared folder. Do you know where I would begin to look to do something like this or do you have any ideas? I am tired of spending $500 of budget line computers that will just be glorified document viewers.

    Thanks for your help!

    Evan

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Our Hours:

Mon-Thu: 10am-9pm
Fri: 10am-6pm
Sat: 10am-5pm
Sun: 1pm-5pm
Closed on City Holidays

Our Full Contact Information
Contact Us:

Call us: 914-422-1400
Text us: WPPL to 66746
100 Martine Ave.
White Plains, NY 10601