Onward.. By Iron Will

Well, it's been quite some time since my last entry to this electrostatic thought-log of the world-wide grids. I'll tear off a new sheet and hastily inscribe an entry describing my latest adventures, digital and otherwise.

So on the Iron front, I've been busy adding some new features that will hopefully help users migrate from the official IDE. There is now a notion of a "Sketch", which is composed of two graphs: one for each of the 'setup()' and 'loop()' functions. Just like the official IDE, the setup graph is run once on device start-up, with the loop graph running continuously afterward.

I've also added text fields to variables, allowing them to have numeric values assigned. To be sure a small advance, but a forward one thankfully.

Below is a snapshot of the Setup and Loop graphs with a simple sketch that sets up pins, reads an analog value and maps/constrains it to a range.

The next step is to compile the graph into source code, which is then uploaded and run on the MCU. Wish me luck, dear Reader of the Aetheric Voids. It is truly all about the journey :-)

~M

An Ironclad Premise

I've been busy lately with the library that I'm hoping will form the foundation of my work with Arduino. It is titled 'Iron', and offers various interfaces for physical computing tasks. The library is based around the concept of devices, encouraging the designer to build code in a fashion that mirrors the physical unit they are creating.

There is a strong theme of performance to the code and, where possible, the lowest-level interfaces are used. For example, direct port manipulation is accomplished with template meta-programming, allowing comfortable labels to be used in place of bit shifts:

// Set pin mode as output. Equivalent to: 'DDRB |= ( 1 << 5 );'
//
setMode< 13, OUTPUT >();

// Set pin 13 high. Equivalent to: 'PORTB |= ( 1 << 5 );'
//
setDigital< 13, HIGH >();

The notion of a device is a cornerstone of the library, gathering variables, communication and inputs & outputs in one place. For example, a camera device might be defined as:

// Define device
//
EN_DEFINE_DEVICE(
    (( Camera, "Example camera device", 0xB0, 0x7B, 0xA6, 0x43 )
    (( Input,    shutter, digital_t, Low,     2 ))
    (( Input,    zoom,    analog_t,  512,     A0 ))
    (( Internal, model,   uint32_t,  2389221, None ))
    (( Internal, flash,   bool,      true,    None ))
    (( Output,   led,     digital_t, Low,     13 ))
)


Devices are designed to be interacted with from either the CPU or the MCU. Following is an example of how a camera's shutter might be expressed with Arduino:

// Create device, with MCU view
//
Camera< MCU > g_cam;

void setup()
{
    // Set up pin modes for any mapped attributes
    //
    g_cam.setup()
}

void loop()
{
    // If shutter button is 'HIGH', begin read of image data
    //
    if ( g_cam.is< 0, HIGH >() )
    {
        g_cam.read< Image >( buffer );
    }
}


From the CPU side it is possible to scan a bus for devices, establishing connections where required:

std::vector< Camera< CPU > > devices = scan< Camera >();

for ( auto it = devices.begin(); it != devices.end(); ++it )
{
    select( *it );   // Select a device. Ready for signals, etc.
    deselect( *it ); // Deselect a device.
}


There are many more facets yet to explore in the library, but it felt right to release it now. It is licensed under the GPL: you are free to use it as-is, or hack it to pieces as you see fit :) Enjoy!

https://github.com/engine-develop/iron

The Iron Handshake

After a brief reprieve from the world of circuits (and their bending) I decided to begin work on the codebase for the S1 sensor. The first forays have been into bus communication, with a simple templated foundation in the works. Often the pattern of bus operations is fixed, with variation in the data layout and signals. The library, called Iron, exposes only the essential components, hiding the details (read: gory) of bus management from the user.

For the S1 project the main role of the bus will be the transfer of image buffers. The library scans all serial ports, signalling to any devices that satisfy a signature. A device matching the protocol is connected to, enabling the start of bus operations.

EN_DEFINE_BUS_PROTOCOL( IR, 16, 0xB0, 0x7B, 0xA6 )
std::vector< Device > devs = Bus< IR, CPU >::listDevices( All );
Bus< IR, CPU >::connect( devs[0], baudRate );
Bus< IR, MCU >::write( image);

The video below shows a simple handshake between a PC application with an Arduino using the Bluetooth Serial Port Protocol. The LED blinks once to indicate a successful handshake. The next step is to send some image data from the Arduino, maybe using sensor values... or I bin it ;)

Teeth, Blue

While waiting for some outstanding camera components I decided to push ahead on another front: communication. I'm intending to interface with the S1 via mobile phone, leveraging it's fast processor for image processing. After some searching I decided to go with the HC-05 Bluetooth tranceiver, a cheap and available break-out board.

At first the pinout looked to require six wires, however after some experimenting only three will be required: VCC, GND & TX. The main hurdle for the sensor will be throughput, with 8 lines of image data needing to be sent over the wire. There are projects that have pushed the MCU as far as 2Mbit/s, which is close to the rates I'll need to support stereo image sensors at high resolution.

The next step will be a minimal mobile application to display the transmitted data, a simple test pattern at first. Qt should come in handy here, allowing a single app that will serve as the hub for many sensors. Onward and upward!

Arduino & Qt Creator

I've been re-working the Qt Creator project wizard of late, adding support for the Arduino core library. It's great to be working in a more capable IDE. For Serial Port monitoring there are many alternatives; I've found Ultra Serial Port Monitor to work well:

http://download.cnet.com/Ultra-Serial-Port-Monitor/3000-2094_4-10969502.html

The updated wizard can be found here:

https://bitbucket.org/engine_develop/arduino_wizard

It's What's Inside...

So, far from languishing on the workbench, I've been working on the S1 sensor project lately. I'm attempting to leave a trail of solder-crumbs for daring (read: foolish) souls who may follow.

The physical design of the device is nearly complete, awaiting the arrival of components for a final look at spacing. I was struggling to find a reasonable design for the rotating fins, each of which must house a CMOS sensor, an M12 fisheye lens and related wiring. The challenge lay in finding a way to pass the wiring through to the hand-grip, housing the micro-controller. My first attempt used a solid metal pin that allowed the fin to rotate but meant leaving a hole for the wiring. In the end 3d printing allowed for a hollow pin, reducing weight and keeping all wiring safely tucked away.

On the system side, I've been building a prototype based on the OV7670 camera sensor, a cheap VGA component that is widely available. I'm planning to build a simplified system with final lens, sensor and using Bluetooth for I/O. Once this is in place I will begin work with the final sensor, which should be challenging. The sensor is a Toshiba CK26V1, found in the Nokia Lumia 1020 smartphone. It has a very high resolution of 41 MP (7136x5360), which should give great coverage when two 180 degree images are stitched.

Here is a snap of my Arduino setup to date; all pins are set up and its time to start timing tests:

Speaking of code, I've updated the Qt Creator Arduino project wizard, adding additional library includes, required for my work with the internal I2C Wire library, and USB initialization. For those interested, the repo lives here:

https://bitbucket.org/engine_develop/arduino_wizard

Hack away! :)

Details, Details...

Here is the latest iteration on the S1 design. There are lots of facets to add tension to the lines, something I think is missing in the design of many devices. The triangular palm grip is still growing on me. I'm not certain that the materials will turn out as I'd like: (Shapeways having a limited selection in plastics), but here's hoping.

Most of the prototype components have been ordered (hoo-rah!) and its now about fitting them into the surfaces. The optics will center around Sony's IMX220 CMOS sensor, which boasts a 20.7 MP resolution. Two of these will be mated to 180 degree fisheye lenses mounted in fins to yield stereo imaging. These fins retract to offer the second imaging mode: 360 degree panoramas.

So... would you buy one? :)