Slow but steady...

A project log for TextEye: Raspberry Pi (Zero) Mobile Textreader

A mobile text scanner/reader for people with severe visual impairments

Markus DieterleMarkus Dieterle 03/21/2016 at 09:060 Comments

It's high time for another update on the progress for this project. The progress is slower than I'd like it to be, but at least It's moving in the right direction, or at least it seems to be for now.

Hardware status

With the exception of the Pimoroni pHat DAC audio board (which is only needed for the Pi Zero), I've now got all the additional components I need: switches, resistors, breadboards, a small speaker, the Powerboost breakout board, a rechargeable battery and - last not least - an additional RGBW neo pixel stick. I've added this last item in order to provide additional lighting for the camera when taking a picture. It's not as bright as a flash, but it should still be helpful for providing more contrast - that's another thing I'll have to test though.

I also went ahead and soldered some standup pins to the 40 GPIO pins on the Rasperry Pi Zero, so I can connect it to the T-cobbler breadboard connector for testing:

I might also get a small USB HUB for further testing which would allow me to connect the Pi Zero to my network while also connecting it to the USB webcam. For now, I can just switch over to the Pi 2 Model B for that.

As for the Pimoroni pHat DAC audio board, that currently seems to be back in stock in the Pimoroni online store right now, but the supplies seem to be dwindling fast. I just checked my outstanding order in the online shop where I ordered the board a month ago, and that shows the board with an availability in 5 to 7 business days. So hopefully I'll get that not too long after the easter weekend.

Just in case, I am also investigating other audio options for the Pi Zero.

Ladyada already did a great job of recreating the basic audio hardware of the other Pi models for the Pi Zero and making it usable by using the GPIO PWM output with some hacking - you can read about the details here.

Another option that in my mind should be viable here is the following:

For the speaker audio output, I can use the same setup that Noel and Pedro Ruiz from Adafruit recently used for their Raspberry Pi PipBoy 3000 project. They connected the audio output of the Pi to the 2.5 watt mono amplifier breakout board and hooked that up to the flat mini speaker in order to have a direct sound output without using external speakers or headphones. This can directly be used for this project if we use a Pi Model A+, B+, 2 or 3.

For the Raspberry Pi Zero, another component has to be added that provides the basic sound output. I'm currently thinking that a basic mini DAC breakout board like Adafruit's 12bit DAC board should work here. These can be hooked up to a microcontroller board or to a Raspberry Pi using I2C/I2S connection. There is already a short tutorial on the Adafruit Learning System on how to do this.

By adding the "pulseaudio" software package to the mix it should be possible to "reroute" the standard audio output to the I2C/I2S-connected DAC board - at least in theory. I'll have to do some additional research and testing in this area.

The only other option I can see right now would be to add a mini 2- or 3-port USB hub and an equally small USB sound card to the Pi Zero. If the components are small enough, and taken out of their default enclosings, they might not take up that much more space compared to the Pimoroni pHat DAC board, especially considering that they can be spaced out a little more freely.

All things considered though, I guess the easy option would be to just use a different model of the Raspberry Pi instead (as all other Pi models already have a working audio hardware), and only add the mini amplifier and speaker. But then again, I usually choose the different, more complicated way in most areas because you just learn so much more - even if you fail.... and if it works, it's just great and should provide some benefits as well.

Software status

I put some thoughts into the software and created a simple framework for what my application needs to do, and then put that in a class. Rather than just write some single file code - which would have been enough for prototype testing - I wanted to create a more reusable codebase, one that can be used for similar projects even if this mobile text reader project does not work out as planned.

The code isn't finished yet as I haven't got around to put in enough coding time, but the basic structure is pretty much established. Hopefully I can get around to completing it over the easter weekend, so I can start to test it with the breadboard prototype hardware setup.

As the image quality issue hasn't been resolved yet, I might resort to just testing the software with some images that I pre-produce with the help of my flatbed scanner. I know that this works quite well, and since I also know that taking a picture also works, I can test everything else (including basic image processing) as a complete workflow.

Model 2 design

In my last log, I already mentioned a different, optional design approach for the TextEye project - basically the same basic hard- and software, but attached to a more capable digital camera instead of a simple webcam.

When I did some research on this, I found only a few digital camera hacks where people actually opened up a camera and added some additional electronics. In some cases, this was just some separate circuit like some LEDs for additional lighting effects, but I also found a few pictures and infos on camera shutter buttons, like this , this or this great one from LucidScience that also contains some important security hints for anyone who's ready to disassemble a digital camera - be extra careful with the big capacitors on cameras with a build-in flash!

The basic electronic and mechanic shutter button design seems to be very similar on most digital cameras so far, as the basic interface mechanic - do a half-press on the button for autofocusing, and press it down completely to take a picture - has become a standard for all digital photo cameras by now.

While the wiring can be different - PCBs, flex connections etc. - there are usually separate lines for the half-press and the full-press signal. So it's possible to connect to this and use it as a trigger signal for some action on an attached Raspberry Pi or Arduino (or similar boards).

However, I haven't found anything about the SD card slots in cameras so far. But as SD cards follow an official standard, the connections of the read/write unit also follow this standard. So even if there is no online documentation about how the SD card slot is connected to the hardware of a specific camera, the actual connector pins of the SD card holder could be connected to a small SD card breakout board, where the original SD card connector on that board can be desoldered. This way, we can use known, preferably open source hardware to read and write the SD card which is actually inside the camera.

I need to do some more research about how to properly connect to and access such an "external" SD card reader from a Raspberry Pi. Basically, this should be configured as an additional physical or logical device, and added to the file system of the Pi as an additional mount or symbolic link. At least that's what I hope, as this would make it easy to read the images produced by the camera and further process them before the OCR and text-to-speech conversion.

Ok, that's all for now....