DPHP 15 - HUD: Headcase Under Duress

In the last post I detailed how I get commands into the system.  Now to discuss how the system gets commands out to me.  Ok, ok, not so much commands but information as status, the other half of the UI pyramid.

Going back two posts, you saw some early images of my UI.  I knew that I was designing the project to be so complex that I needed some form of status monitor so that I didn't have to memorize what the helmet was doing at any one instant.  We are visual creatures.  We can process a lot of information in a very short amount of time by simply looking at something.  So rather than design something with a convoluted series of beeps, whistles, and vibrations like modern smartphones, I needed something visual.

Lets pull up an image from two posts ago:



Pay attention to the left hand side. You see a couple of sketches. The top is an idea I had to use fiber optics to remotely locate status LEDs. The color and pattern would be used to indicate what's going on. Not exactly pretty or easy to remember.

The second design from the sketchbook is a alphanumeric display/7 segment reflected into the periphery of the eye. This mirror served to give greater flexibility of the placement of LED box, and potentially adjust the perceived size through lensing. A bit better than the fiber optic option, since it could be more recognizable symbols and letters. But still very limited in it's capabilities.

There was also one key problem with both ideas: vision. The lack of vision though the helmet to the outside world. Back in this project's infancy, I assumed I would use a transparent sub-visor and I would see between the LEDs. Well, that went by the wayside pretty quick as the dot pitch of the LEDs got closer and closer together and I realized the shear amount of wiring that would be between my eyes and the outside world.

I got around this problem by using the CMOS camera, combined with some video goggles and of course the on screen display chip. But that now meant I had to design a proper heads up display. And I came up with this:



So what are you looking at? Well:

1) Display Status Bar.  This shows what is currently running on the display.

2) Randomize Indicator.  This indicators whether or not the display is set to randomly select a new animation after a certain amount of time.

3) Current Power Consumption.  Show in watts.  This is to helpme judge the power draw of the system, and whether I should take actions to reduce power consumption.

4) Remaining Time.  At the current power consumption, how much time is left in the battery.

5) Battery Bar.  Battery icon like you find on almost any battery powered device.

6) Run Time.  The clock showing how long it's been powered up for.  Always useful for keeping track of things.

7) On/Off Indicators.  Indicators symbols for various ancillary devices.  More on these devices in posts to come.

8) Error Messages.  A place for various error messages to occupy.

9) Menu Soft Buttons.  These are soft buttons that correspond to the 8 buttons on each gloves.  I use a fairly straightforward menu tree to organizer everything.

10) Temperature Indicators.  Readings from various sensors on the status of me and my cooling system.

11) Climate Control.  A bunch of settings for the climate control system.

12) Side Bars Status.  What's currently running on the side bars.

All in all, pretty comprehensive.  It's had a few minor evolutionary steps, but mostly has followed this setup since I first laid it out.  This should also give you some indications of sub-systems and components I will detail in the future.

DPHP 14 - Star Trek Inspires Everything

It's long been known that Star Trek has inspired a number of technologies over the years.  The cell phone, voice recognition, even the 'hypospray' has a modern day, needless equivalent.  I'd like to start with this image:

And what does this have to do with anything?  The hologram?  Is the helmet a virtual one as well now?  Not really no.  This next picture is another clue:

Getting the idea now?  Yep, this is the idea behind my user interface.  Gloves.  Gloves that are the primary input.  Gloves with buttons built into them.  If you look carefully at the Star Trek image of a game of Strategema, you'll notice the little thimbles that act as the input controllers for the game.  Did Star Trek inspire me to use things mounted to my hands as the input for the Daft Punk Helmet Project?  Probably not, but it was an interesting parallel I stumbled across.

I had the original idea to use gloves as a sort of 'shortcut' buttons that could be used to quickly pull up commonly used animations or images.  Then I discovered the OSD chip that would evolve into my heads up display.  With the ability to have a menu system in place that  I could see and not have to memorize, I could use the shortcut buttons instead as actual input buttons, much like the soft-buttons on cellphones and car stereos.

But how are these gloves going to work?  Well that's were the Peregrine Gaming Glove comes in.  See, regular tactile switches mounted to the side of a glove would be painful to operate, both from the 'poking' factor of the solder joints, and the pain of pressing the switches themselves.  Once I actually tried to press a tactile switch sitting atop my finger nail (my original idea) it was excruciating uncomfortable.  I knew that wasn't going to work.

I tried a few different ideas, including hall effect sensors (magnet sensors) and bend sensors, but wasn't happy with the complexity of the first or 'false positives' the second would introduce (what if I just wanted to pick something up that required closing my hand?).  Finally I came to a rather simple solution: just closing electrical circuits and sensing that input.  Each 'button' would be pressed by the thumb, so replace the button with just a wire acting as an input, and use the thumb to connect the circuit and change the voltage on the 'button' wire.



Originally I was going to do this with conductive thread 'traces' and conductive fabric 'pads' but that was when I discovered the Peregrine gloves.  They use a similar method of electrical connections to generate keyboard pressed for gamers.  The cool part is the components they used.  Instead of conductive thread, they use small diameter stainless steel springs.  Brilliant.

I haven't finalized the design, or even built a completely functional prototype yet.  But the gloves are a winner.  They will be fairly hidden and unobtrusive, adding to the "suspension of disbelief" factor.  They should be pretty easy to use.  They should be error resistant, except grabbing a metal railing in just the wrong way, and my simple tests say that 'way' is a very unnatural and uncomfortable way to grasp something.  They should work a charm.

DPHP 13 - UI Design, aka Ungodly Intricate

So it's been the better part of 2 months since I last wrote a post.  Most probably won't accept that I have been on business trips for all that time, working 12-18 hour days, fighting dragons, etc etc etc.  I don't even really care to be honest, except for the fact that I can finally get back to the interesting stuff on this project.

One of the earliest areas where I could 'stretch my legs' was the design of the user interface, i.e. how the hell I was going to control all this and also know what the hell it was doing.  I still knew nothing about how I was going to do the electronics, but I was sure going to make my life as difficult as I figured I could make it.  Lets try that sentence again, shall we.  I came up with ideas for the user interface based on what I thought I could design and 'make work.'  As I did more research and learned more about more components/code/methods, that design for the user interface evolved and changed.  Lets get stuck in.

Here's something new for everyone, some actual excerpts from my notebook.  Appologies for the shite quality, I used my phone since I'm too lazy to use the scanner.



Good luck understanding the hieroglyphs I call hand writing.



This one is a bit more interesting. On the right, You have the layout of an 'arm controller' design that I came up with. Obviously, this was more in keeping with the original costumes, which used arm mounted control panels. Needless to say that has it's difficulties.

On the left is something rather interesting. Probably my first stab at the idea of a 'heads up display.' It's a bit hard to see, harder still to understand, but the idea was to use a handful of RGB LEDs as status indicators. The real interesting idea was to use fiberoptic strands to 1) allow for remotely locating the LEDs based on the space constraints in the helmet, and 2) reduce the brightness somewhat by having the fiber not pointed in the eye but more of a 'peripheral glow.' Also I had the idea of using a 7 segment display or a alphanumeric segment display and a mirror to provide a peripheral indicator. I actually got that idea from the SEGA laser tag guns once upon an age ago.









Eventually, this concept evolved into what you see above.  The idea was two arm controllers.  One for controlling the display, and one for controlling the playback of sound (since sound was one of my major goals).  I had a handful of ideas on how I could use the buttons on the display controller, one being binary 'combinations' that's very much like dip switch inputs.  The first button would select the group, the second would select the dominant feature, the next would alter that feature, so on and so forth.  Needless to say it was going to involve a lot of memorization of button combinations.  And of course, I had linear potentiometers, because everything is better with sliders.

That was the most comprehensive, and complicated, interface I came up with.  It was like the what the relay did before the transistor was invented (or mass deployed).  You'd be surprised how complicated a circuit you can built with switches and relays.  This was like that.  It was nested menu of button presses and combinations, without giving clear feedback of what was going on.  An old analog aircraft cockpit compared to the modern 'glass cockpit' digital display designs we see today.

This interesting setup got replaced with the design I field currently.  I'll give you a hint, it's infant concept is present in the overall design.  It's just an immature version of it.  We'll cover that in the next installment of DPHP.

DPHP 12 - Design on a Dime... Apparently that's a TV show

Since I've run out of videos to comment on, and I'm not quite where I want to be with the build before I become 'current' and start discussing that, I've decided the next selection of blog posts will be talking about the design process on the various subsystems of the project.

I design.  A LOT.  I spend hours and days in my notebook, PowerPoint, SolidWorks, whatever the design tool of the hour.  Why?  Because design time is free, at least as far as personal projects are concerned.  It lets me mull over, and over, and over, and over a project.  I suffer from Hyperactive Imagination Disorder (self diagnosed, and no it's not a real affliction).  One of my favorite dialogs with some friends went thusly:

Friend: "Scott, I best describe you as a circle."
Other Friend:  "Why, because he's 'well rounded'?"
Friend:  "No, because goes on an infinite number of tangents."

So why that tangent?  Well, if left to my own devices, ideas spin and spin and spin in my head and I'd never get anything done.  So my design time is more or less just getting all these random tangents down on paper (or sometimes files).  I take all these errant buzzing visions and see if they are practical and meaningful.  This is probably a large contributor to my 'one-upping projects endlessly' problem, I have too many good ideas.  It's going to be expensive now that I know I can actually do the 3D modelling, the electronics, and so on required for said ideas.  But anyways...

So yah, welcome to the musings of my mad head.  Should be fun.

DPHP 11 - Technologic Rehashed

And that's my last video. I readers will be pleased. I should be current from here on out, right?

In this I decided to redo my Conway's Game of Life simulation.  The last one was flawed, it ran for a finite number of cycles and did not have any 'end condition' detection.  So, it was perfectly possible for the screen to hit a repeating or frozen state.  So I fixed that with some interesting use of 'lifetimes' that was linked to the hue of the cell, and some interesting use the neighbor function to detect repeating or frozen screens.

But the bigger 'behind the scenes' change was the use of a new firmware for the rainbowduinos.  Funnily enough, this firmware is very similar to one of the failed firmwares from way back in the infancy of the software development.  My janky original firmware uses multiple send and receive 'sessions' because there is a limit to the size of the send buffer.  As a result, there are largish delays introduced because of the need for the multiple sessions and having to wait after each data transmission.  Well, apparently, when I tried to up that buffer back in the day, I changed only one of the two numbers I was supposed to change to get it work.

Either way, I'm using a new firmware that is far more robust.  It did require a rather large 'going over' of my code, especially the oldest stuff that was coded at a very low level to save on operating memory.  Fun to do?  Not in the slightest.  But everything works so much nicer and faster now.  I haven't done any refresh rate testing yet, but early 'camera testing' doesn't cause any of the usual weirdness like you get when you point at a TV, or like in my very first videos.

So, guess I need to start planning these posts out a bit more, now that I'm out of videos to use as a starting point.  Bugger.

DPHP 10 - Making the Robot Rock... Again

Yep. Bad song title pun. Haven't I done enough of those? Not in the slightest. I pride myself on my pseudo-English heritage and mad attention to Top Gear, so I should be able to sprout random one liners til the sun goes down.

Anyways...

So I did sound.  Again.  Why?  Well the first setup, with the Processing sketch and the laptop, would be cumbersome to deploy on the real thing, to put it mildly.  I went so far as to track down the exact model of UMPC (ultra mobile PC) I would have used to run the script and provide the music.  Namely, the Viliv S5.  I was even somewhat willing to pay the ~$500 for the unit.  It'd be a nice toy anyways.  But really, it wasn't really a practical idea.  It meant another device with another battery that would need to be kept charged.  It would mean even more cables.  Not practical.

I learned enough in signals and systems (the class I hated the most in school) to know the theory of what I wanted.  I wanted a discretely calculated (because floating point numbers take a lot of process time on arduinos) FFT (fast Fourier transform).  And I knew that I didn't have the wherewithal to do it myself.

So, I stumbled upon a pre-built FFT library one day on the interwebs, dropped it in, and off we go.  I now have a locally calculated FFT that gives me some pretty lines that dance to the music.  It has some problems.  It probably only registers up to 500Hz and even then it seems to have a ton of noise built into the signal path.  The arduino ADC (analog to digital converter) only reads the positive side of an AC signal from an audio source, so about half the signal is missing.  I did try to get round this with a coupling capacitor and some other circuitry, but the result still isn't perfect.  The typical signal from a MP3 player maxes out around 2.5V, which means your signal is at best 1/2 the voltage you want it to be, and small voltage signals means more noise and more problems.

But I got it done locally on the micro-controllers.  $500 saved.  Job done none the less.

And this brings us to the second half of the video.  Almost more impressive.  Or certainly a more lengthy discussion.  Oh boy.

The side lights.  They're a hug part of most builds, because that's the extent that most others go for with their lights.  Simple reason: you need to see, that gets rid of the front display.  I've gotten around that with the camera and video goggles.  I didn't get around to the side lights until rather late in the game here.

I must one up everything, that's a given.  So, no cellophane covered LEDs here.  Nope, instead I'll continue the RGB trend and give each bar 3 RGB LEDs.  All kinds of coolness ensue as a result.  As you see in the videos, you have scrolling rainbows in the horizontal, in the vertical, and diagonal.  How cool is that?  It basically an extension of the display itself.  Tons of flexibility, limited only to the code I bother to write.

But like everything, there has to be some caveats and some problems.  This is where my new best friend (he who is building another copy of the helmet, otherwise known as ThreeFF) comes in and his innate ability to ask questions.  Plenty of times they're questions and problems I've thought out (like how do you see in the dark: headlights), and I explain as much.  But it's very helpful when he calls out the bits I haven't thought of.

He points out, simply, that if I used a rainbow, like you see in the video, I'm essentially using 1/6 the power of the main display (1 rainbowduino instead of 6) to light up roughly the same surface area with the side bars.  Yah, problems.  This eventually turned into an epic saga, in which I became knowledgeable about almost every off the shelf LED lighting system in the hobby electronics scene, from shiftbrites, BlinkMs, bliptronics, etc.  But as always that's discussion for other another time.

DPHP 9 - A.I. = Attenuated Intelligence

Yep. Pong. Seriously, why wouldn't you?  The hard part?  Faking being human, and failing like a real human.  I mean, I could do the MONOCRON thing and have it tell time our just count up in increments, but wheres the fun in that?  No, I wanted some AI's that would play against each other, relatively evenly matched.  Apparently it's the sign of a good AI if it can play itself and stay relatively matched.  Bonus points if it manages to use different tactics and still score very close.  But anyways, evenly matched AI's are mostly likely to just volley endlessly, which isn't very sporting, or interesting, or technically challenging, or going to sound impressive in programming circles, etc etc. 

The breakthrough came when I included some 'random tiring' where one of the AI's would reduce in skill over time.  Theoretically, this could lead to an interesting situation where a paddle would 'negatively follow' the ball and move in the opposite direction, but hasn't happened yet.  I will worship the day that it does though, especially if both paddles manage to go negative at the same time.

Also, Pacman sprites fit on my display.  Neat.  I wish more of the Megaman sprites fit.