The Creative Process

Now that I have quite a bit more time and energy that I didn't have before, I've been filled with creative energy, or at least the drive to be creative.  This has it's ups and downs.

Engineers have an unusual combination of the creative extrovert and the calculating introvert.  We're often called upon to figure out novel solutions to problems that don't have an obvious, straightforward answer, and yet we need to back up that decision with numbers, facts, and predictions.  Recently, I've only really had the energy for the later and at times I felt like was being coaxed in that direction by my work tasks.  It's probably very true in fact, because a common sentiment in R&D work is "don't waste the time doing the work to make something new/better until you find someone who will pay you to make something new/better."  From a business point of view, that makes sense, but it can be stifling for an engineer.

One of the guys I've been in the same building with at my temp job had this quote:

"Big companies, especially defense contractors, have a habit of making good and great engineers into bad engineers."

I think part of this is restraining the creative process that engineers have.  The other part is the bureaucracy, politics, and 'business sense' stuff that seem to mire people.  I'll be the first to admit that management, especially good, great, and fantastic management, is critical to success.  But management certainly doesn't need to be the disastrous metaphor that is the Office Space movie (as much as I hate the movie, it is the metaphor of the times).  All that stuff gets in the way of what an engineer wants to be, which is to be creative.  We want to come up with the next great widget.  We want to prove how great it is with math and science and reams of statics.  It proves that we're right.  I don't mean that narcissistic way, because anyone with pride in their work is 'doing it right.'

So back to being creative.  As I've illustrated above, being creative is a part of being and engineer.  And it's definitely the seductive, morale lifiting part of the process.  Sometimes finding the solution with the math and the modelling and the science can be engaging and seductive and fulfilling  I think it's initial brainstorming sessions that engineers covet, when there are no boundaries and no obstacles; the 'real world' and 'real math' have not dampened or constrained the idea ye.

Being creative, making new ideas, new drawing, new stuff, is definitely seductive, intoxicating, and addictive.  But eventually, you will need to convert that creativity into getting stuff done to make it real.  You have to convert creativity into productivity.

I had a work colleague tell me about an artist friend of his.  Most people think/ask an artist how much they love their work and craft.  Apparently, his response was:

"I don't do it because I love it.  In fact I hate it.  But I can't not do it.  It's my religion."

-Unknown Artist Person

It's a complicated idea to say that a job, creative or otherwise, can be seen like a religion.  I assume it's along the lines of an unquestioned belief or desire, one that can't be explained.

And that need, that desire that is 'religious' in nature can be lacking in an engineer.  I think we're pragmatic enough to not let the 'creative energies take over' because eventually I will get hungry and want dinner.  Or I'll want a break, or I'll want to be social, or do accounting (sometimes I have weird catharsis in pastimes).

I'll admit that drive is one of the things I struggle with on my personal projects, especially the DPHP.  It's such a long, complicated project to implement.  Thinking up and including all these nifty features in the design part is quick and easy, but carrying out the laborious parts is painfully slow.  And being an engineer during work hours doesn't help, because often you do the design work and someone else has to do the tedious part of making the widget hundreds or thousands of times over.

Perhaps I should start finding some short and quick projects to help wit the creative/productive momentum dichotomy.

Smart Batteries

Smart Batteries are a wonderful technology.  Let me explain:

On a laptop, you know the battery status information, like percent, time remaining, and so on?  Well, all that data is actually calculated by a chip built into the battery itself.  Therefore, if you can figure out how to talk to the battery itself, you can get all this wonderfully useful data about how much your power consumption is, and how long you have left before you need a battery change.  Nifty ey?

So I did just that.  I researched the protocol used by smart batteries in laptops, and turns out it's just a subset of I2C.  Spiffy.  So next I researched and found an example of someone who had figured out how to talk to the laptop battery he had.  Nifty.  Then I wrote my own library based on that example, and got it working on one of my laptop batteries.  Excellent.  So I have smart batteries working with the DPHP!

That looks like a comfortable shape, doesn't it?

But one of the things that bugged me is that laptop batteries, especially the Thinkpad ones I'm using, are designed to fit in a laptop.  What that means is a long and awkwardly shaped battery with a boxy, uncomfortable shape, sharp corners and mounting sprues and all.  Someone has to have put all the capabilities of smart batteries in a more uniform and simplistic shape, right?

Well, eventually I stumbled into Inspired Energy.  And guess what?  They do exactly as I thought, they put the guts of smart batteries in a more universal housing that can be used by anyone that wants to.  They do the manufacturing, testing, and especially certification for you.  The certification part will get more important as lithium shipping rules get more and more stringent.

A rounded, simple shape, Wohoo!

So once I can afford a set of these, I'll probably being using them instead of my current setup.  Much less risk of an electrical short, ensuing fire, and hospital visit.

Prospects: Arduino DUE

Yes, it's finally out, and I definitely scrambled to be one of the lucky to get one from the Maker Shed.

I've been waiting for this thing for over a year.  At the beginning it was just the prospect of more hardware ports (namely serial and I2C) that I was interested in, but as more specs and details were revealed, I was pleased and intrigue.  What follows in the specs that I'm most interested in and how they apply to the DPHP.

525% Faster

Specifically, the clock rate of the DUE is over 5 times that of a normal Arduino/Mega/Teensy/etc.  This doesn't include some of the operation efficiency increases because of the 32 bit processor.  I'll probably do some calc time comparisons once I get the code base going.  I can also comfortably use a single processor, where some of my previous designs with the Teensy had one processor for animation work, and another one for HUD and system management.

12x the RAM

While the minimum variable size has gone up, the DUE still has 3x the memory by comparison to a Mega or Teensy.  This means that I can make the trade for higher memory usage,  and get faster code operations.  Normally, the more numbers you can store, the less you have to manipulate the number 'in place' or with multiple operations, which takes more steps and longer overall.  More efficient code and faster processor means more time to do more things or more complicated tasks.

Two I2C ports

This is the big one that first got me all excited.  The DPHP uses Rainbowduinos to drive the main display, and these rely on the I2C protocol for sending display data to each of the Rainbows that make up the display.  Most large scale LED display use SPI because of the high data rate, however I2C for the rainbow and the 12 bit color it uses is quick enough.

The only problem has been that I2C is also a great protocol for connecting multiple Arduinos into a 'local network' for the various ancillary components that make up the suit for the helmet.  Specifically, the Arduino Wire library is one of the few one out there that enables 'slave mode' so that the 'main' controller can recieve 'pushed' updates from any of the other controllers on the network.  The alternative is a 'pulling' system that is normally used, whereby peripheral I2C devices are polled for updates or sensor samples.  This way, when there is an update to the system, like a button has been pushed or power system has a problem, it can 'push' relevant data to the main controller, rather than the main controller wasting time polling all the devices looking for updates.

So back to the problem.  One I2C port is really needed for full time 'display' duty, and likely will be at or near data saturation.  With a second port, where the other devices are more likely to send updates and thus the controller is primarily a receiver.  The second port the DUE helps keep that bus relatively open for the random point in time that update will arrive, where with everything on a single bus would mean more chance of collisions.

Four Serial Ports

Really, the Arduino DUE and Mega have more like 3+1 serial ports.  One of the ports is your serial port to the computer, and it's generally a good idea to leave the port open for debugging purposes.  You can use it, but I make it a habit on the more capable Mega/DUE/Teensy to not use the port for talking to anything but the computer.

Where I see the biggest advantage is in talking wireless devices.  I have grand plans for XBee radios talking to some wireless projects in the future.  I had planned to impliment the XBee with the Teensy++, but that chip only has one Serial port on it (the second port is a through the USB only for the terminal and programming, it cannot be used to talk to a device).  But that would be the only serial device I could setup.

Something I think would be interesting to impliment would be WiFi.  It would be less proprietary and more cross capable than the XBee radio.

Form Factor

Funily enough, the form factor of the DUE might be helpful compared to the Teensy++, even though the Teensy is a smaller component.  The problem I was having with my board layout is that I had to fit two Teensy's on the board, and that put a large density of through hole via into the middle of the board.  These via took up a good deal of space and made routing traced around them quite difficult.  The DUE will put all the signal pins on the periphery, and may make packaging easier.  Time and trying it out will tell.

Audio

This was deifinetely something I wasn't expecting.  The DUE supports playback of .WAV files.  I may be able to integrate a 'simple jukebox' that is easyily controlled from the DUE and the HUD since I won't have to interact with an external device.  I've considered devices like the MP3 Trigger from Sparkfun for this role, but that particular device is quite large.  With the internal audio library, I'll just need the footprint of a microSD card.  Testing will tell what the processor usage is for this particular feature.

Built in Scheduler

Also a nice feature I wasn't expecting.  Arduino has put in provisions for running multiple LOOP functions, allowing for a level of protothreading from what I understand of how the code works.  I probably won't be using this option over the threading library I discovered recently, as that one has the ability to add and remove threads during run time, which the Arduino library doesn't seem to support.  That is a particularly useful feature for adding/removing animations based on user input.

Overall, should be a fun piece of kit to use and more suited to what I'm trying to accomplish.

My Shapeways Shop: Three Name Design

So I'm finally opening up my Shapeways shop with the cufflinks I made from the Guy Manuel and Thomas helmet models that I've generated.



I plan to create more in the future, but for now, the cufflinks are great opener for the shop.

Please feel free to head on over to the shop and buy some!  I've made 4 versions of the cufflinks, a Thomas/ Guy Man, and left/right handed version of each.  That way you can mix and match and get the style/hand/material of your choice.  I'm a glutton for selection and I'm sure plenty of people are.  The defaults are of the logical choices of course, gold for Guy Man, and silver for Thomas.

Enjoy!

And Now for Something Completely Different: Halloween Edition

More brownie points for the person that get's that quote in the title.

It's been over a year since the last post?  Well bugger.

What's the reason?  Work.  A job that seemed all consuming and left me with little time or energy for anything but the basics of eat, sleep, clean, exercise, and work.  A job that I have since been release from.  "It is what it is" is the phase I've chosen when describing the ending of that vocation.  What does this mean for me, my projects, and the slow trickle of people who follow my blog?  Not really sure yet, I only got let go about 2 weeks ago.  I'm still trying to figure out what I do now that my former job no longer controls the lions share of my life.

So moving on.  This post is about something I threatened from the beginning, but never pulled the trigger on: topics and projects other than my helmet build.  Luckily, Halloween turned out to be a good vehicle for something completely different to work on.  Yes, I know Halloween was the better part of a month ago.  Please give me a break, I only got my free time back 2 weeks ago and well, I hadn't taken a vacation in a year.  I forgot what lazying around the house felt like!

So during Halloween week I was invited to 2 Halloween parties.  Halloween truly is the Makers and Hackers holiday, and I'm sure the subculture existed and thrived on the holiday far before the modern trend surrounding Make Magazine, Arduino, Makerbot, Instructables, and the like.  For each party I wanted to do something with electronics (naturally) and LEDs (naturally) since everything is better when it glows in the dark (and makes everything else in the dark glow as well).  These projects ended up being the "2 Hour" and the "3 Hour" Halloween costume projects mostly due to poor planning on my part.

2 Hour Halloween Costume: RGB Hands

This was definitely and exercise in "ok, what can I throw together before the party in... oh crap."  Yep, that's almost exactly the words of my internal monologue 2 hours before I had to hit the road.



In the end, I threw together an Arduino (a old pre-Uno 328 I had laying around), a pair of Shiftbrites I had laying around from testing for the DPHP, a USB 5V cell phone extender battery, probably 8ft of ribbon cable, and some finicky direct soldering.  Definitely one of my janky-er builds.  And the arduino was WAY underused.  The LEDs both cycled the same color, and it was just a rainbow hue cycle effect.  Pretty boring.  Definitely ran out of time to do any real or even interesting coding on this one.



The only remotely spiffy thing about it was I put the LEDs in my palms, under some cut up gloves also left over from DPHP prototyping.  It made for a kind of fun way to illuminate my beer bottle and that's about it.  One other trick was sticking the LED through my shirt cuff button hole, resulting in a kinda interesting cufflink.



If nothing else it as a decent flashlight, that was one dark party!

3 Hour Halloween Cosutme: Tony Stark

I decided to honor the alma mater and go as Stark for the second party

Yah, I'm sure you believe that line. Stark is the ultimate fictional playboy and what all us intelligent, nerdy engineer people wish it was like for us in the real world.  Basically, this involves making your own arc reactor.



Once again, I pulled together some old prototyping parts for this job.  I have some LilyPads arduino boards, which happen to be round, and some leftover rectangular white LEDs from the cheek EQs on the helmet.



My first idea was to really quickly solder the LEDs to the Lily with both the cathode and anode going to a pad each, but this wouldn't work because the lilypad is 22 pads (not including power) and so would give you an odd number of LEDs on the board (not very balanced looking).  So instead I went with 10 LEDs and putting a 'ground ring' of wire jumpers for the final design.  The 'housing' was a clear plastic contain lid of the right size, and the LEDs were super glued to the plastic.  The Lilypad 'hovers' hanging from the positive leg of all 10 LEDs.  Some long wires and a 2 AA battery pack later, and you have a really quick and dirty arc reactor.



Code was pretty simple.  I put in a 'start up' series of flashes when the thing was turned on.  I also put in some really simple animations with a 'fill in, drain out' and 'alternating flash' effects.  Then I put all the animations on a radomizer timer so that 'most' of the time the thing was on just on, but occasionally it would 'act up'.

The costume for this ended up being incredible simple: black jeans and lightweight black 'breathing base layer' T shirt from REI I've had for ages.  I'm already bearded so I didn't have to to anything there, although I am blond so not exactly Tony there.  I wasn't going to dye the beard, I've heard some horror stories on that one.

'Attaching' the reactor to me was less than comfortable.  To stop the soldered LED legs and board components from poking into my chest, I put a backing sheet of plastic taken from a button/pin kit.  That was held in place with double stick foam tape.  I had planned to use some magnets, tape, and few other ideas to hold the reactor to my shirt.  But, my shirt was way too stretchy and there was no good way to support the weight without it shifting or handing at a funny angle.  So I went with the 'worst case' backup in the form of super glue.  I really, really don't recommend that option.  My inebriation made the removal more acceptable, but it wasn't pleasant.  Just don't do it, kids.

So there you have it.  Two LED based Halloween projects that took less than 5 hours start to finish.

DPHP 17 - It's hot, hard, and dangerous... I need to stay cool

Brownie points for whoever gets that quote.

Probably one of the shorter design focused posts I'll do.  I'm going to be talking about the cooling system.

I

RUN

HOT

Fact and case in point.  I've always had a hot metabolism.  I grew up in one of the more 'miserable' climates of Europe and you know what, it suited me just fine.  But the hot, sunny, humid, and even arid places I've been to since then have made me appreciate the power and wonder of central air.  I'm particularly sensitive to the heat.  I'm prone to dehydration, both from my own damn fault (not drinking enough) and my metabolism (I loose a lot of water sweating imperceptibly and perceptibly).  I've had heat exhaustion several times in my life, and probably heat stroke in some of those cases.

So you can imagine, the last thing I want to do is wear an enclosed helmet with maybe 50W of heat generating equipment built into it, while wearing full leathers.  Throw that into the high energy atmosphere and attention of a convention and I probably won't last 15 minutes.  I need something more than just good hydration.  Once again days of google research ensued.

Plenty of options are out there, and I found scenarios for plush encased mascots, to Storm Troopers, to renaissance fair armor.  It all fits into two main categories: evaporative cooling, and phase change cooling.

Evaporative cooling is basically augmenting our bodies normal means of cooling itself: sweating and letting the sweat evaporate.  Despite what lower school science told you those decades ago, water will evaporate at less than 100deg C.  It depends on the air temperature and humidity level, but evaporation below 100deg C does happen.  As that water evaporates, to help it reach that gas state, the water will suck in as much of the surrounding heat energy that it can to help it along.  And that's how it cools you.  If you don't believe me, it's kept you alive up until this point.

Evaporative cooling systems normally work by wearing a fabric that will hold a lot of moisture without feeling particularly 'wet.'  Slowly, that stored water will evaporate to the surroundings and take some heat energy with it, cooling the fabric and you.  However, as anyone who's lived in a swampy area will tell you, it doesn't work very well when humidity is high.  This is because the air is already saturated with water, so there isn't anywhere for evaporating water to go.  So evaporative cooling works great in the desert, but that's about it.

The other system is phase change.  It sounds more complicated than it really is.  Phase change, when talking about personal cooling, really amounts to ice melting.  As ice changes from solid cubes/blocks/chips to water, that process absorbs heat energy.  But another aspect of phase change cooling is that, typically, you start with ice below the freezing point.  So first, your ice warms up to the transition temperature, in this case 0deg C.  Then it starts melting, absorbing more energy.  But now, you still have 0deg C water.  That cold water actually takes more energy to heat 1deg C than the ice does.  Because of these three stages of heating, ice water can in fact absorb a lot of energy.

The commercially available phase change cooling clothing normally amounts to nothing more complicated than ice packs sewn into clothing.  Some have replaceable ice packs, so you can wear one set, use it up, and change it out for another set.  The problem is in fact these packs.  Depending on the outside temperature, your level of activity, and so on, those packs will 'run out' and need to be replaced more often.  You could end up needing a lot of ice packs for any reasonable (or unreasonable) length of costume wearing.  And those cost money.  And they ad a good bit of bulk to your person depending on their size.

Neither of these options are particularly ideal for the design and spirit of my project.  But there is a third option.  I'm not sure when in the days, weeks, and months of research this option turned up, but it did and it's what I'm going with.

The system I've decided to go with is essentially a portable implementation of the type of cooling systems used for race drivers.  These systems use circulating ice water from a reservoir, pumped around the core of the body via a shirt with small capillary tubing sewn into it.

I like this system for a couple of reasons.  First, it has the level of complexity that I enjoy on this project.  Anything simpler just wouldn't 'fit' as well with what I'm trying to accomplish.  Second, it's fairly low profile, both size wise and the impact it will have with the other systems in the project.  The shirt isn't much thicker than a normal shirt, and the reservoir can pretty much be any size.  Third, it's essentially 'free' to operate for any length of time.  If I use up the current batch of ice water, a trip to the ice machine, or even the bar, will provide the refill I need.  All done without the need to for special ice packs.  Forth, it's expandable and interchangeable, meaning I can use a number of different reservoirs depending on the situation.  Fifth, I can run a 'thermostat' to cycle the pump on and off, improving the comfort and level of cooling depending on my activity, and potentially increasing the duration of a supply of ice water.  As you can tell, I like this solution.

Guess that wasn't as short as I thought it would be...

DPHP 16 - OOP: Object Organizing Pandemonium

For once, I'm going to talk about something current: my move to code base version 3.0.

I decided a while back my code running on the UI controller was a mess and in serious need of an overhaul.  I'm making some minor changes and structure modifications as I do the recode from scratch, but mostly it's about one thing: moving to object oriented programming (OOP).

For those that don't know, OOP is changing the base metaphor of writing computer code.  Normally when you think of code, you think of variables, if statements, for loops, all combined to make functions and eventually whatever code you're trying to write.  It's a pretty straightforward concept and something that plenty of people could probably figure out in a weekend.  OOP is quite different but leveraging the same base tools.

In 'regular' programming you have two type of 'stuff' in your code that's pretty easy to understand: data, and structure.  Data is all variables you calculate, predefine, and so on.  It's hard numbers stored somewhere on the device while it 'does the math.'  Data typically has a specific format depending on the variable you're trying to express.  There are integers for when you only need store and process whole numbers.  There are floats for when you more accuracy and the use of decimal points, but on microcontrollers float processing tends to be rather slow.  There are smaller and bigger versions of these two main types, depending on how big (or accurate in the case of floats) you need your numbers to be.  There are arrays which are just a specific way of defining a big set of variables you want to group together.  Ok, that's fair enough to understand.

Structure is all the stuff you're telling the computer to do with those bits of data.  There's the 'ifs', the 'fors' and also the math you put together to write your code.  The functions you write and the 'main' statement are all structure.  They have a specific format, often known as the 'syntax,' depending on the language you are using (c++, java, etc).  This formatting is critical to the 'compiler' to understand you code; the compiler that makes your code run on your microcontroller or computer.  It's a common, poor mans comparison, but computer code much like the human language can mean different things with minor differences.  For instance "that's a sweet-ass car" means something quite different from "that's a sweet ass-car."  And Yes, that was an XKCD reference.

Ok, I've been babbling on about that stuff for a while, back to the interesting stuff.  So if data is basically just numbers and structure is what you wrap data in to make it do stuff, then what does OOP do differently?  here we introduce objects.  Objects blur the line between where data ends and structure begins.  Objects in code can be like objects in life as well, with numbers and parameters that define and describe them.  Maybe not so clear as life is what else you can put in an object: bits of structure.  Specifically, it's like adding the tools you need to change that object or make it do something.  You're 'baseball' object might have a 'bat' function that makes it fly through the air, for instance.

Where I find Objects useful is in a concept of 'abstraction.'  Most people will tell you a lot of written code is a 'black box' that you put stuff into (inputs) and then it churns for a while and gives you the stuff you want (outputs).  A lot of the time, you don't need to know what happens in the black box, only that it works and it gives you what you want.  That's abstraction: making the stuff you don't really need to know more hidden from you so it doesn't get in your way.

In my UI code, I have tons of what I can 'tracking' variables, variables that are used to keep track of what's running, when it's running, how, etc.  If you want to pass those variables between different functions, those have to be 'global' and visible to all of your functions to work.  But they often have a narrow set of uses to specific bits of code, but they still end up floating around getting in the way of your code when your trying to add other features or debug other problems.  And when you make changes you have to go back and double check that you didn't break a bunch of things you didn't mean to change in the process.

How about a visual example.  On the left is my new code, and on the right is the old code, both starting with setup() at the top:



Just looking at them, you wouldn't know that the left example is actually doing a lot more things, with a lot more new features, and doing it a lot more efficiently and directly. Heck, the new code base takes up fewer lines for the setup() and loop() functions than the old setup() had.

It's true, you can generally do the same thing both with and without OOP code.  In fact, I'm hardly using any of the true power of OOP, as you can probably tell from the depth of my description.  But moving to an OOP code base does have generally have an advantage even when you aren't using it's full potential, besides abstraction and tidying things up.  You won't know it until you try it, but OOP tends to suffer less from bugs and problems as you decide to 'upgrade' your code and add new features.  Because you generally have to take the time to lay out you objects and what/where/how they do things, you generally end up with better 'black boxes.'  Other parts of your code don't care about what happens in the box, just the inputs and outputs.  And because that is the case, you can change what's inside the box to your hearts content, because you can only break what's inside the box, not the inputs and outputs that your other code relies on.  Yes, you can make those numbers wrong and irrelevant, but you can't really break the structure of one object with broken structure in another object.  With non-OOP coding, you're probably ending up with big, all encompassing bits of structure that when part of it breaks, all of if breaks.  Eventually you want to stab out your eyes rather than debug something like that.

Long term, the move to OOP has a key advantage in the arduino language: per arduino specs, all libraries are essentially objects, and more commonly/specifically: pre-initialized objects.  I'm not in a rush to release all my code to the public, but I'm pretty sure I will have created some libraries and tools that people will want to have access to for their own projects.  We shall see, but for now I need to make sure that my black boxes work in the first place.