15 days ago •
After a marathon programming session, the different modules of the software came together wonderfully for the prototype video nearly two weeks ago -- it's been very exciting to see the Arducorder Mini hardware coupled with an attractive and intuitive user interface:
I tend to think of first prototypes as a sketch -- in hardware -- that's as close to the final project as time and experience afford, but with the knowledge that for a sufficiently complex project there will always be an errata, or list of items that need to be modified or corrected in the next revision. The idea here is to make our mistakes cheaply so that everything has the best possible chance of working the first time -- and to ensure that we have enough wiggle room to tinker with any critical bits that don't work the first time, so we can quickly narrow down any design changes for the next revision.
With PCB turn times taking about two weeks, my recent focus has been revising the few issues that popped up when validating the hardware, and sending these new boards off to be made. It's my hope that if everything validates fine, that these boards will be the first official release candidate for the Arducorder Mini.
I confess that when I designed most of the first revision boards, I failed to include mount points on the motherboard and capacitive touch board that would allow the whole thing to be placed in an enclosure! This was a bit of an issue, since the motherboard is only 2-layers, and so densely populated that I had to increase the size a small amount (4mm in both width and height) to accommodate four M2 mounting holes. If I was willing to increase the PCB specifications to 4-layers the board would have been significantly less dense and made mounting much easier, but I'd like to keep the specifications as low as possible so that the boards can be made inexpensively, and the open source community can easily modify the designs with the free version of Eagle CAD. I remember years ago reading that when Stephen Hawking was writing A Brief History of Time, his publisher told him that his readership would be halved for every equation he placed in the book. I feel the same about open hardware -- for every barrier I place on people easily modifying the hardware -- expensive software, 4 layer boards, etc -- that it will reduce the reach by at least an order of magnitude. So I'm trying to keep it simple and accessible.
Other than mechanical considerations -- the four mounting points, and switching to a connector for the capacitive touch board itself with mounting holes -- there are a few minor schematic changes for the motherboard:
- Added I2C pullup resistors on motherboard
- Fixed VCC/GND pin swap on two sets of the PIC32 pins
- The OLED 13V booster VIN is now sourced from the 3.3V regulator instead of the battery. When sourced from the battery and the booster was disabled, the OLED 13V line would be equal to VBAT, causing a few pixels to stay on, and draining the battery a bit.
These are largely minor changes, and the technical challenge is largely in rerouting big chunks of an existing board for the modifications.
The capacitive touch wheel board also has largely mechanical modifications to allow it to securely mate with the motherboard, and to mount in a case. The parts have all been moved to the underside of the board (except for the two pushbuttons), leaving a flat surface for some acrylic to mate with for the touch wheel. I'm hoping to have the opportunity to camp out infront of the laser cutter at Xerocraft one evening in the next week or so to design an attractive case with the hardware in hand.
To help the indicator LEDs for battery charging and programming to shine through to the front face of the enclosure, I've added the small notch along the length of the bottom of the capacitive touch board. Inventables has some back-surface laser-engravable acrylic that looks very interesting, so I've ordered a few pieces and I'm excited to see what some...
Read more »
a month ago •
User Interface Design
Visualization and user interface design is a hobby that I really enjoy, and I've been lucky enough to have friends and colleagues who are usability and visualization folks that I've been able to periodically soak information up from. The open source science tricorders present a really interesting UI problem -- where most mobile devices have at most a few different sensing modalities, here we have 12 different physical sensors, each of which measures between 1 and 3 different things! What's more, while some of these measurements are single values (like temperature, say 24C), others are vector values (like the three separate 3-axis vectors coming from the MPU9150 -- one vector for acceleration, rotation, and magnetic field strength, giving nine values total, from a single sensor). In the extreme case, the spectrometer returns a vector of 256 values. That's a lot of data! I'm really not aware of any other device that comes close to having so many different kinds of sensing data pouring into it constantly, and while this is very exciting, it's also challenging -- we want folks to intuitively browse and navigate through that data very quickly.
I've spent the past few weeks researching design concepts for user interfaces by browsing popular design websites, and talking to some friends, and I think I've settled on a very intuitive, attractive, and useful interface design. I'll confess that I've been working harder, not smarter about this in recent years -- I'd try and design very complicated things that looked like how other people had done mobile devices and visualization (like android phones), which is a fantastic amount of work for a single human being. Starting this Arducorder mini project almost 4 months ago, and keeping it attractive and capable but tractable has finally helped me work smarter about this, and figure out a lightweight, usable and intuitive interface concept.
I like the idea of live tiles. When done well, it reminds me of Danny Hillis's idea (30 years ago) about maximizing the amount of computing silicon active on a processor at any one time, but attractively applied to data visualization. Instead of having icons that just take up space and give you a name, here you have tiles that display a live updating value. This is powerful from a usability perspective -- instead of having to enter each application to obtain this information (which can consume a lot of time), the most important information is available at a glance from many applications. While this has largely been applied to communication (e.g. messaging), web (weather/news), and I'm sure sensing applications, here we're going to construct an interface made almost entirely of sensor data.
The really interesting aspect (if you're a data abstraction nerd, like me) is that if we consider only this special case -- visualizing sensor data through tiles -- then we can formulate the software engineering aspect of this very elegantly. If each tile has a sensor data buffer behind it, then we can browse it's most recent data on the top of the tile, then activate the tile to display additional (historical) data and different visualizations. If we abstract the sensor data buffer into a few different types, like continuous streaming data (from something like a temperature sensor or an accelerometer) and discretely sampled data (from something like a lightning sensor, that only activates when an event occurs), then we can get rid of the idea of an application. The design concept becomes browsing sensor data buffers first through a high-level tile interface, and then activating an individual buffer and using a suite of generic visualization tools to better explore it.
All of the software engineering aside, what the user sees is very attractive -- tiles with live data that they can browse through very quickly with...
Read more »
2 months ago •
A quick update with lots of progress designing the spectrometer (and thermal camera) board, attaching the radiation sensor board, and beginning to work on the low-level routines for the user interface!
Fast and Efficient Bitmap Rendering
Now that much of the hardware is in good shape (or being fabbed), I've been working on the low-level software and APIs that would support building an intuitive and attractive user interface.
A bit of background -- from my hobby of indie game development in undergrad and participating in the Ludum Dare 48-hour game competitions (a really fun experience!), I've picked up that in a desktop system (and some embedded systems), a graphical user interface is often functionally implemented as a large collection of bitmaps stacked atop each other with transparent layers. This has the benefit of being able to make large changes to the user interface through editing configuration files that describe which bitmap corresponds to which background or widget or font (instead of recompiling code), and also allows the user interface artist to easily use whatever tools they're most comfortable illustrating in to rapidly iterate without having to use middleware, or (even worse) be constrained to building an interface entirely out of low-level graphics primitives like squares, ellipses, and triangles.
This is the approach that I'd initially planned on using, but I'd discovered about a month ago when running a display verification test that the ChipKit SD card library has a read speed of around 100k/sec, which puts the time to load and display a bitmap on the order of about one second -- far too slow for an interface. There are faster libraries like sdfat, but these required more than a solid evening of porting, and at some point you have to put these on the wishlist, accept the constraints, and exploit the benefits of your existing system while architecting it in such a way that you could drop more advanced functionality in later with a minimum of effort.
While loading bitmaps from an SD card is currently slow, the PIC32MX processor that the Chipkit Max32 uses does have 512k of flash memory that (in addition to code) can store bitmaps that can be loaded very quickly. A full screen (128x128) 16-bit (2bpp) bitmap takes 32k of memory, so we can't fit very many in memory, but if we manage our resources and store things efficiently, we should have plenty of space for backgrounds and widgets and icons in ~128k or so.
One way of compressing bitmaps is to reduce the colour depth -- if we can reduce an image from 16-bit colour (64k colours) to 8-bit (256 colours) or 4-bit colour (16 colours), then we can store the image in half to a quarter of the space. The trick is selecting a smaller colour palette so that the final "posterized" image still looks very good.
There are automated algorithms to do this, but they often give non-ideal results, and I want this thing to look /good/. I've been looking at user interface concept art the last few days to get ideas, and I'd had the idea of having a main menu that showcases a space theme by having a scrolling background under an icon-based main menu with multiple pages of icons, similar to Android. I grabbed a copy of NASA's amazing public "earth at night" photograph, downsampled it to 256x128, and used manual posterizing tool I quickly put together in Processing to reduce the colour depth to 4-bit, and store the image as a static array in flash. Despite being 256x128, the image only uses 16k of flash, and the manual conversion (above) is so good compared to an automated algorithm that I would never have known it was poserized if I didn't do it myself! It also scrolls back and forth at about 50fps, which looks really impressive. While I'm still deciding the final user interface concept, it was a good test, and a useful tool to compress the graphic assets into flash so that they're...
Read more »