Logging science in less than a second

As the Rascal has matured over the last few years, I've started to think about how it can change the working lives of artists and scientists. The Rascal is already a useful tool for people who have some experience with web programming and basic electronics, but I'd like to see it spread to a wider audience. I'm working on a number of projects to this end; I'll detail one in the scientific realm below.

Data management in science

In science, one of the largest changes in the last 20 or 30 years is the rise of computerized statistical analysis. Scientists have long used statistics to analyze their data, but with microcontrollers embedded in everything, we can now gather data more easily than ever before. I think it would be fair to say that our ability to gather data has outstripped our ability to manage that data.

In my experience, researchers manage data in a haphazard way, but only because it's so hard to do better. They're often collecting data from multiple instruments simultaneously. The data ends up with different timestamps, on various USB sticks or shared fileservers, often in CSV or Excel files, or in some weird text format specific to the instrument. The researcher then pulls the data together onto one computer, reconciles the timescales, and analyzes the data using Excel, SPSS, R, Python, or a software tool specific to their research specialty. Merging and reformatting the data into a form that you can analyze is painful, mind-numbing work, not worthy of the attention of a scientist.

I think we can do data collection and management better. It's a broad problem, but I'm working on a solution to one narrow slice of it, as I'll explain below.

The event logger

I've been collaborating with an angel-funded startup at MIT called BioBright. Their goal is to build an open software framework for the collection, analysis, and visualization of biomedical data. Recently, we have been working on a device for the lab bench that will help biomedical experimenters log their progress while executing biomedical protocols.

The first cardboard mock-up, a first try, and a much smaller, more refined prototype

The scenario goes like this: you're at the lab bench wearing nitrile gloves, holding a pipette in one hand and a test tube in the other. You might be working in a fume hood or a glovebox. You're working your way through a protocol, maybe printed out and stuck to the front of the fume hood. You'd like to be able to note down, "Yes, at 10:36 AM today, I exchanged the cell culture media," but given that the protocol is long and complex, and you have a lot of samples to deal with, you're not going to take the time at every step to log what happened. You'd have to put down the pipette, and type on your laptop one-handed, or use a pencil and a notebook. Your average time for each step could easily double or triple, and you might end up contaminating your samples as well.

Logging in less than a second

If you could create a timestamped log of steps achieved and add less than 1 second per step, that would be worth it. Then, when something goes funny with your experiment, you can look back across multiple batches of samples or cultures and check where the preparations differed. Was one culture out of the fridge for longer? Did one solution spend the night on the stir plate, while the other was only stirred as long as it took to check email?

This is the idea of the event logger-- a small box that pulls your protocols from a central server. It shows you each step, and as you complete each step, you tap the button. You can hit it with a finger, the heel of your palm, or even your elbow. The box acknowledges your button press and moves to the next step. In the background, it timestamps the protocol step and logs to a file. If you're using the Biobright software or something that implements their API, the box logs the same data back to the central server.

That's the basic functionality, but we can add more advanced features. For example, if your protocol requires that you put your samples in an incubator for 18 minutes, the event logger will give you an 18-minute countdown, starting when you hit the button. Because every event logger contains a Rascal, it's also a webserver, so you can log into it remotely to change settings, look at the data, and so forth.

Your feedback is welcome, scientists

The event logger is obviously in a child-like state. If this sounds like something you would like to use in your lab, please get in touch with me at brandon@rascalmicro.com. If you work in a lab around Boston, I would love to come to your lab and hear the details of what your lab needs. It may be nothing like the event logger; I'm still interested!

The Raspberry Pi vs the Rascal

When I talk to people about the Rascal, they often ask about the differences between a Raspberry Pi and a Rascal.

Summary: if you want the cheapest possible computer, buy a Raspberry Pi. If you want to control some Arduino-style hardware from your web browser and you're a busy person, buy a Rascal.

The Raspberry Pi on the left, the Rascal on the right

The two boards have a lot of similarities, but a few major differences as well. Let's run through the similarities quickly.

Similarities

• Both the Raspberry Pi and the Rascal run Linux.
• Both store their filesystems on SD cards.
• Both use ARM processors.
• Both have an Ethernet port (Raspberry Pi Model B only) and two USB host ports.

Differences

I'll get to the specifics of the differences shortly, but let me explain what drives most of the differences: the two boards are intended for different purposes.

The Raspberry Pi is made by a nonprofit foundation in the United Kingdom for the purpose of teaching kids to program. To quote their website, "We want to see it being used by kids all over the world to learn programming. . . . Our main function is a charitable one – we’re trying to build the cheapest possible computer that provides a certain basic level of functionality . . ." The Raspberry Pi has connections for a monitor and keyboard.

The Rascal came from my work as an embedded systems engineer. I was frustrated that I couldn't buy an embedded Linux board that was preconfigured for controlling Arduino-style hardware from the web. I designed the Rascal so that I could plug Arduino shields directly into it, and I wrote the software using a modern web framework so that I wouldn't have to set that stuff up every time I started a new project. Then I added a code editor and wrote a Python library to make it even easier. The Rascal doesn't use a monitor-- you interact with it through your web browser.

Here's a summary of the differences.

Wait, if the Rascal has a slower processor, why would I pay more for it?

In the end, the decision comes down to the value of your time. Almost anything you could do with a Rascal, you could eventually do with a Raspberry Pi, if you're willing to learn a lot of Linux programming. If you're a Linux-savvy person just playing around with embedded computers, and tweaking the Linux kernel sounds interesting, you can save some money with the Raspberry Pi. If you're new to embedded computers or you just need to get something done quickly, I think the extra cost of the Rascal is worth it.

The Slingshot, a realtime coprocessor for the Rascal

This post is to preview some of the stuff that I've been working on for the Rascal.

Suppose you want to build a pulse counter so you can tell how fast a motor is spinning. The pulses are coming out of the motor at around 10 kHz, i.e. at 10,000 pulses per second.

The Linux kernel that runs on the Rascal doles processor time out to different programs at 100 Hz, i.e. in 10 millisecond chunks. For example, the Rascal is constantly running a webserver, but also a program that watches for new USB hardware. The Linux kernel schedules those different programs so that they can share time on the same processor. If you were to add code that checked whether a pulse had arrived, it would share time with the rest of the processes running. With this kind of process scheduling running, reading pulses 10 times per second can be done, but reading pulses at 10 kHz is hopeless.

How do we think about this kind of stuff?

In my mind, I divide tasks into four groups:

1. Simple and high latency is OK, like tripping a relay to drop a box over a turtle. Any microprocessor can do this.
2. Complex, but high latency is OK, like image analysis or serving web pages. The Rascal wins at this.
3. Simple, but low latency is required, like counting pulses from a motor. A microcontroller like the Arduino wins at this.
4. Complex, but low latency is required, like using facial recognition to pilot a drone toward a target in a crowd. We can't do this on one processor.

Diagram that shows what kind of device to use for different tasks

In theory, you could change the Rascal's operating system so that the scheduling interval was much smaller, so you could actually check for pulses much faster. The problem with this approach is that every time you stop a process to run your pulse counting program, you burn some time in the switch. Eventually, your system is spending more time switching processes, and your pulse counter starts missing pulses.

Codename Slingshot

A better approach is to use a secondary processor that can handle the low-latency stuff. I've been prototyping this kind of realtime coprocessor as a shield that can plug into the Rascal's headers. For lots of tasks, you could use almost any microprocessor, so long as it doesn't have an operating system. To make things easy, I'm prototyping with an Arduino kit. In the long run, I will probably use a small ARM processor, maybe something like the Cortex M3 used on the Arduino Due. For the meantime, I'm using an Arduino Uno and calling the project codename Slingshot. (Thanks to Dan Beyer for the naming suggestion. He thought a slingshot was the sort of accessory a rascal would keep close at hand.)

In the pulse counter example, the Slingshot counts the pulses very quickly. When the Rascal has a 10 ms slice available, it asks the Slingshot for the count. The Slingshot dumps the answer into its I²C hardware, which talks to the Rascal while the Slingshot keeps counting. In the long run, I would like the Rascal to come with a Slingshot built in, and with a pile of different programs available on the Rascal. If you want a pulse counter, you just select the pulse counter option, and the Rascal drops it onto the coprocessor for you.

The picture below shows the first attempt at the Slingshot. It's just an Arduino with some parts missing, but I think the functionality will be great.

The Slingshot running off the Rascal's power supply, connected to the Rascal via I²C

I've left out the original headers and the power circuitry from the Arduino kit. For the power connections and I²C, I soldered pins in the open holes. These pins allow the Arduino to draw power from the Rascal's power supply and talk to the Rascal using I²C.

Anyway, this marks the beginning of the Slingshot. I think the Rascal/Slingshot combination will be powerful when the Slingshot is done.

Other folks doing this kind of thing

I would remiss if I didn't mention that lots of other people have done this sort of thing before. In the open source hardware world, there's the Wyolum Alamode board, which is an Arduino that plugs into the Raspberry Pi and can talk over the serial port. One of the guys behind the Alamode, Kevin Osborn, works out of our local hackerspace here in Somerville, so I've talked this stuff over with him a few times.

Reading 125 kHz RFID cards using Wiegand protocol in Python

One of the early Rascal customers was the Massachusetts General Hospital Learning Lab. The Learning Lab has been developing an attendance tracking system using 125 kHz RFID cards. In their current system, each card reader talks to an Arduino microcontroller using the Wiegand protocol; the Arduino talks to a PC over a USB cable; and the PC talks over the local network a database server to determine whether a card is valid or not.

The folks at the Learning Lab wanted to replace the PC and the Arduino with a Rascal, so I offered to help them interface their Wiegand card reader with the Rascal. For testing purposes, I got a cheap Wiegand protocol card reader off of Ebay. A little googling revealed that a gentleman by the name of Mark Jason Anderson had already written a Linux driver for Wiegand card readers. He used some CPU-specific kernel functions in his code, but luckily he was using the same Atmel AT91SAM9G20 processor that I use for the Rascal. I forked his wiegand-linux repository to my own on Github and modified the code slightly to use pins that the Rascal breaks out to its Arduino headers. I was able to build the kernel driver with the same cross-compiler I use for the Rascal kernel. The details of setting up the ARM cross-compiler are covered in the Rascal build guide.

There was one other challenge-- the card reader idles at 5 V, but the Rascal expects 3.3 V on its inputs. To scale the voltage down, I used a circuit not unlike the 2x voltage divider on the Sparkfun level shifter. The picture below shows the circuit. I used 4.64k and 9.09k resistors to scale the voltage down. In theory, this would reduce a 5 V signal to 3.31 V; I measured it at 3.29 V, so it was pretty close. I suspect that a 5k and 10k resistor would work fine, but I found the other values in my bins first.

Circuit used to scale Wiegand card reader's 5 V down to 3.3 V for the Rascal inputs

The earlier kernel driver build provided me with a driver binary called wiegand-linux.ko. I copied that to the Rascal. For testing, I was able to insert it into the running kernel like this:

language-bash insmod wiegand-linux

After this, the following shows up in dmesg:

language-bash wiegand intialising wiegand ready

To make the kernel load on boot, the binary should be moved into /lib/modules/2.6.36+/ and the full filename, wiegand-gpio.ko, added to /etc/modules.

When a card is held next to the card reader, it beeps, the diamond flashes green, and we see new text in dmesg.

language-bash 1 0 0 1 0 0 0 0 0 1 1 1 1 1 1 1 0 1 0 0 1 0 0 0 0 0 wiegand read complete new read available: 32:65168

The new card data is also available from /sys/kernel/wiegand/read.

In the long run, I'd like the RFID reader to display some confirmation that it's working properly on a display, so I hooked up a 4D Systems LCD that I had from a different project. Here's the whole assemblage.

RFID reader and LCD plugged into the Rascal

The last step is to pull data from /sys/kernel/wiegand/read and display it on an LCD. (Of course, the Rascal should also do something useful like unlock a door or log the card number to a database, but this is just a demo.) I wrote a short RFID monitoring Python script that does this on the Rascal. It would be nice to use the Rascal's Python server, uWSGI, to watch for new cards and trigger the Python so a second script wouldn't be needed, but that would mean writing a libudev plugin for uWSGI. I might do that eventually, but for now, this works fine. If you take a close look at the LCD in the picture above, you can see data from the few test RFID cards that I have.

Onwards!