So, I mentioned that the driver board for controlling the dorsal keyboard panel shorted out on me. Well, I have decided to not rebuild it from a prototyping board but instead get a printed circuit board manufactured so this does not happen again. This way there is no chance of a home mead header pin folding over as the traces should be sealed and I will be using a real head block this time like the kind present on the Arduino.
I have only ever built home made printed circuit boards before. I have never used CAD software to create them and I have never designed a multi layer board before so this was quite an education. Here is a little bit about what I learned.
Seedstudio will manufacture five copies of a 2 layer 5x5cm board for around $10 by sending it out to China. I am in no hurry and this is a great price. Element 14 recommended Sunstone Circuits who can do a single prototype for $40 and get it to you faster.
All of these manufacturing houses require something called Gerber Files which it turns out have nothing to do with baby food at all but are actually a set of documents that describe the layers of your board such as the silk screen, top layer, bottom layer, connections between layers (called vias) and where holes need to be drilled.
I needed a way to create these files and I discovered a free to use CAD program that will help you lay them our called Eagle. Eagle is not as simple to use as a lot of modern drawing software and harkens back to old unix workstation engineering packages a little bit but there are a great set of tutorials on how to use it by Jeremy Blum. This was pretty much all I needed to create the PCB board design shown above.
This board was pretty simple to design since all I really had to do was draw out the entire circuit diagram.
From this, it created a sample PCB and I moved the components to where I wanted them to be located. Since this board does not carry any high frequency signals I did not really have to worry about shielding or bends in the tracing but the tutorial addresses these issues as well. Next, it auto routed two layers of copper for me and then let me tweak the routes and add my own text to the silk screen layer. With the help of Jeremy's videos I rendered the gerber files and am about to place my order with Seedstudio. When the boards show up, I will talk more about how well the whole processes turned out.
I have moved my source code from a private repository to a public on on github.com . Keep in mind that it is a work in progress and I think the most use it will have at this point is to provide me a way to link to source code I want to talk about in this blog. The source code can be found here.
What is currently in this repository is the Arduino code for the dorsal control panel and a Raspberry PI Python source for a daemon to control the Arduino and in turn the switches, light and LCD display. There is more than one way for a Raspberry PI to communicate with an Arduino (such as I2C) but I have chosen, at least initially, to use USB . The PI is the master decision maker based on messages it receives from the two Arduinos in the system. The Arduinos, in some cases, can simplify and filter the inputs into more meaningful messages to reduce traffic over the bus.
The format of the over the wire data is JSON. Even though there is no Javascript in use, I am just more comfortable reading and working with JSON. The Arduino has a JSON library (aJson by Marcus Nowotny) and so does Python so I am not in the business of parsing data, only interpreting it.
A simple set of commands and events has been created that allows the dorsal panel to be controlled and to emit keyup and keydown events. Here is an example.
{"lightcode":3} // Turns on the first two panel lights (ie 2^0+2^1 or 1+2) {"backlighton":true} // Turns on the LCD backlight
{"line2":"Hello","line3":"World"} // Display the text hello on LCD display line 1 and world on line 2
These commands can be typed to the Arduino's in the Serial Monitor for easy testing as well. You can take a look at the Arduino sketch in its current state here.
The Arduino emits JSON back to the PI to let it know when events such as key presses occur. Right now it generates events such as:
{"key8":"down"} {"key12":"up"}
To process these events I am working on a python script that listens on the USB device representing the Arduino and connects the keydown events to light sequences on the control panel as a proof of concept. This script runs as a daemon started by the PI's init daemon when the PI boots up. Its job will be to coordinate button pushes with button lights and allow the user to make LCD menu choices.
Alas, I demo-ed the light animations and had them trigger against different buttons on the keyboard a couple times but failed to make any videos. I went to make a video just for this blog post and when a powered up the board, I had an expected short that seems to have burned out all the transistors. This is both a curse and a blessing. It is blessing because 1. it did not burn out the Arduino and 2. It gives me an excuse to create a PCB to replace it. I will talk about the PCB board creation process in a future entry and will update this entry in the future when I get the demo running again.
This is one of the more complex components that has to created. I wanted it to be functional, not just a light show. By functional, I mean that these buttons should be able to be used to communicate with the Raspberry PI and it should be able to control them as well.
In addition to the twelve colored buttons, this panel also contains a red display, separated into two segments. I wanted this display to be backed by a multi line liquid crystal display. This display could act as a simple console like the kind often used in laser printers that lets you access its features. The buttons could act as a keypad to respond to menus presented on they keypad. This meant that I would have to make a change to the display from the original prop. I will be removing the segment in the middle.
Both the LCD and the twelve key keyboard will be controlled by their own Arduino. This arduino will communicate serially with the Raspberry PI. This will require analog pins A4 for data and A5 for the clock for I2C communication for the LCD display. We will also need 12 digital inputs to tell if a switch has been depressed and 12 digial output to actually light the lights in the switches. This is a problem as most Arduinos only have 13 digital i/o pins total. A shield will be required here to drive this board.
Enter the Numato Lab's IO Expander Shield. It will add 28 more digital i/o pins to our Arduino that will be I2C controlled as well. We now have our required 24 digital i/o lines with some to spare which we may want to use later.
I am assuming here that the dorsal control panel box has already been constructed from the plans I have linked to in past entries so lets talk about the hardware needed to create the LCD display and keyboard. Since I am basing my K9's drive system on electric scooters, I will have a 24 Volt primary power supply from the batteries taken out of the scooters. The lighted switches I need will require 24 volts to light up and will have to signal the Expander shield with a 24 Volt signal as well. What colors you want to use are up to you because I have found no consistency in any of the prop pictures. Here is a shot of the actual hero prop I got from the K9 builder's Site. I could not match the switches perfectly but I came pretty close.
I purchased everything off this list except the Numato board directly from Amazon but as this article ages, the links I have included may go bad so I have tried to include extensive descriptions as well.
You may also want to purchase a wire wrapping tool as well as pre made female to female cables work very well but some of the connections (like the ground and +24 volt busses) are easier to do with a wire wrap tool.
Now lets discuss the actual circuits that are required to drive the keyboard. To be able to light the lights inside each switch on demand they must be hooked up to D0-D11 of the Numato board. They cannot be directly connected because 5 volts is not enough to light the light and the Numato board can only supply 25 mA of current max. We need a circuit that will switch 36mA at 24 Volts from a signal under 25mA at 5 volts. It is shown below. 12 of them are required, one for each of the D0-D11 pins.
I built my first version of this board before I discovered the magic that is the Single Row Male 1x40 Pin Header Strip so you will see where my connection points are spread all over the board. Eventually, I will replace this with a home made printed circuit board. My prototype looks like this (left - in progress. right - complete) :
Next is the circuit for reading the state of all twelve switches and reporting them back to the Arduino. This circuit uses the 24 Volt power supply from the battery and switches it through voltage divider circuit. Basically, when you push the button down, you are delivering 1/5 of 24 volts to the digital input pin which places it in the range lower than 5 volts which is the maximum permitted to turn the digital pin to the on state and only requires about 4mA to operate a single switch when pressed. We will also be able to detect when multiple sets of switches are pressed as well. The capacitor is present to prevent the switch from bouncing. You will need one of these circuits to detect when each switch is depressed on the keyboard.
Here is a picture of the finished product with only the d22 wire connected.
I am not crazy about the layout and I may have to put some hot glue in to stabilize the capacitors to prevent shorts but I really need to make this a printed circuit board anyway.
Shown below is some of the wiring in progress for the actual switches. All of the bulb positives and commons are all wired to 24 Volts +. This is shown below with wire wrap wire. The colored lines are the control signal to light the lights. The signal sent back to the Arduino indicating a switch has been pressed is yet to be connected to each Normally Closed (NC) terminal. These are wired into the printed circuit board shown above.
I have almost finished testing reading when a button has been pressed and forwarding that information back to my Raspberry PI. Once I do I look forward to implementing the game Simon just for fun, The software control of this keyboard is really a whole additional blog entry as it is somewhat complicated so I will save that for next time. In closing, here is the last self test I recorded which I used to make sure the lights are working.
Another thing you may have noticed is that my actual wooden shell for the control panel is too small compared to the actual picture of the real prop shown above. I am going to have to build another one a move all the part into it to correct this mistake. What is it they say, measure twice, cut once.
I was reading the other day about Mike the Headless Chicken. Mike was one of a crop of Chickens that had their heads chopped off prior to being served up as someone's meal but unlike the other chickens, Mike didn't die.
Mike lived on far longer without his head than anyone though he could. His body lived on, was fed and actually traveled the world performing in side shows for 18 months after his decapitation. He was a miracle to behold because when he was decapitated, the farmer left most of his brainstem intact and that was all he needed to run his basic bodily functions. An amazing true story that I hope does not parallel Apple Inc's performance since the passing of Steve Jobs.
What got me thinking about this was trying to help someone with their iCloud notes synchronization of all things. Let me explain. I have been a Macintosh developer almost since the product was released. I got my first Mac in 1985 as part of the second crop of freshmen who received Macs as part of their school tuition at Drexel University. I dove right in and tried to learn everything I could about software development on the Mac. My first two full-time jobs after I graduated were both Mac development jobs. I was excited for the future.
What I did not realize at the time was that Steve had left Apple in 1985 and in retrospect, Apple had started to coast, much like Mike. Innovation has started to turn into incremental improvements. Stagnation had set in, most likely due to risk avoidance. The same kind of risk that Steve Jobs pursued during his tenure was diminishing every year.
Slowly, my day job turned from Mac development to Windows development. Customer demand for Windows products was up and Mac demand was down and I moved on, not really noticing the reasons for this shift at the time.
Now on to 2005. After spending years developing for Windows and becoming intimately familiar with its warts and bruises, I had moved on to pure Java development. After Apple's migration to Intel hardware I decided to take another peek at Apple computers. Performance on Power PC macs was lagging behind most Intel systems at that point and it looked like the time to see if this was a platform was now worth switching back to.
What I found was a reliable, engaging platform that was fast and gave me the kind of flexible command line that I could only find previously on Linux boxes. It was easy to use, much less troubled by viruses and did not slow down over time. I was back and times were good. I would tune in to Apple keynotes like Macworld in January and look forward to new innovations like the iPhone and iPad. These also brought with them new development challenges and endless new Apps. Times were good again.
Now I am beginning to wonder if the Mike analogy is appropriate again. Here is why. Remember MobileMe? I do. It was a disaster and Steve gave it the mercy killing it deserved. It was replaced by iCloud which I had a lot of hope for but this hope is fading in the light of competition and the lack of continued improvement or innovation. When I think about it, I use dropbox more, on Apple platforms than I ever use iCloud storage. iCloud is everywhere (on my Apple devices) but not anywhere else. Is free storage size is small and Dropbox is everywhere, on all platforms.
You might come back and say, "But it is so simple, I don't have to think about it." But you do. The first thing I noticed about iCloud synchronization is the annoying feature of having a local and cloud based store of information. You can have local calendars and notes that don't synchronize and it is easy to start using them, only to discover your stuff isn't everywhere. I know this is a feature but more than one person has come to me asking why their content is not syncing and the answer always is these local data stores. This is not something that should ever get turned on by default.
My other complaint about iCloud is it's app centric philosophy. Drop box just cares about files. I can put a file in it and its on all my devices. I don't ever have to think about it. When I go to iCloud.com I don't see my files, I just see apps that can edit them. I guess this is ok, but the test of time has proven to me that I want to see are my files because I keep falling back to dropbox. Just try to make a file public on iCloud so that anyone can download it. You just can't do it.
Next is iTunes. I pay my $20 a year for streaming privileges and when this feature came out it was half baked. It would fill my phone with streaming content to the point where I would have to delete my iTunes library just to install a new app. No one wanted it to work that way and they finally made it simple streaming. Time has moved on and now Google will stream all my music for free and will import my iTunes library anywhere. Where is my iTunes app on iCloud.com? Its not there. Can I watched amy video I purchased there? No. When are they going to stop charging me $20 a year for something I can get for free. They probably won't stop. Things will just go on the way they are because nobody is going to make the same call Steve did with MobileMe.
The iPhone was amazing when it first came out. No other device could do what it could do. Every year it got better and better. I would expect innovation to slow down on this product eventually but all two quickly the changes became incremental. Now new phones are starting to populate the product line that don't really make sense. Did the iPhone 5c remind anyone of the days of the Macintosh Quadra's and Performas? A proliferation of a product line that just made no sense? Who wants to buy the second best new iPhone? It turned out no one did.
And what about Siri? It progresses painfully slowly. Born in the final Steve era, it still can be classified as useful when it feels like it. One day you can ask it something and it works and the next you can ask it the same thing and it fails. Don't ever try to use it without a good network connection because it just won't work. Google has caught up because it has advanced so slowly. There speech recognition is now better and from what I can tell, we are approaching the turning point for new software innovation transitioning from IOS to Android any day now.
I read Steve's authorized autobiography. One thing I remember is that he did not ever want anyone to ask themselves, "What would Steve do?", after he was gone. What they should ask is what is the next opportunity to innovate. Steve appointed Tim Cook, his former head of operations to replace him. I though this was an odd choice. I was hoping for someone more drastic or Mercurial. Operations is kind of like the brain stem of a company. It gets resources where they need to be and keeps the body moving smoothly. In general, Apple's stock price is still high. Innovation comes in small jumps. My iPhone now has a thumbprint scanner but Mike lived for 18 months before his body finally failed. Are we seeing the radical innovation we were used to or are we seeing the body live on without the head?
So now I find my self looking to the future. Will there be an iWatch? Will the AppleTV finally open itself up to Apps and Games? Where is the Apple brand TV that Steve mentions in his autobiography? Will we see something no one expected or will I find my next laptop is running Linux and I am developing for Android? I am waiting for a sign. I hope I see one soon. Can this chicken grow a new head?
Nothing is set in stone yet but I have been thinking about this for a while and decided to map out what peripherals I will be including in this project. I have spent a lot of time building the shell but I am just starting to build the electronics that will integrate my Raspberry PI into it. Below is an overall map of the systems that will be connected to the PI.
Where possible, I try to include what resources they will use in terms of ports or pins and nothing is connected directly to the PI's GPIO as of yet. This may become necessary if USB access for sensor data is too slow.
So where on the actual shell will these systems be located? Here are some callouts that will give you a general idea.
LEFT SIDE
RIGHT SIDE
FRONT/REAR
These diagrams come from the original BBC plans with my callouts added to show equipment location. I will attempt prevent these real life peripherals from altering the normal appearance of the original prop.
I have already constructed some of these peripherals including the dorsal control panel and LCD display which will need to have a post all its own when it is completed. Here is a short video showing it performing one of its first self tests.
Keep in mind that the surface of this piece has only been primed and will not show the rough line marks that a visible now when it is completed. Here you can see the display light individual lights by generating powers of 2^n as integers. It is capable of lighting any combination of the twenty four lights simultaneously. Once the switches are wired into the Arduino, I will be able to use them to interact with menus displayed on the LCD screen.
There is already as small body of Arduino sketch and python code which controls this control panel and I have been thinking about putting this on GitHub in the near future. I will also start including parts lists and diagrams which are probably to detailed to post in my blog in case anyone gets the idea to try this project themselves in the future.
