|Masud on Joule Thief (now with Pan…|
|thouton on Nixie Tube Necklace|
|tekarain on Nixie Tube Necklace|
|RustyBolt.Info - 201… on Nixie Tube Necklace|
|Closing in on Nixie… on Nixie Tube Necklace|
Quick post for today. This is my take on the Nixie Tube necklace, inspired by the original that turned up on the Makezine and documented a little on flickr. I haven’t seen any remakes of this lovely idea, so I wondered how well I could emulate the aesthetic (as always, feedback welcome). Visually I was aiming for something like a light bulb, pointing slightly upwards to illuminate the wearer’s neck and jaw. This is a front looking tube and as such is ill suited to a front facing design as it would protrude strangely away from the body, another reason why an upward/forward facing design was selected. The two wires really do carry the power (1.5 volts) and the two contact bolts carry the power inside the enclosure. The boost converter is contained within the aluminium housing.
This type of tube has a number of interesting symbols such as ~, +, -, %, A, V and omega. There is no audible whine that can sometimes be heard with this type of boost converter – the low load probably has something to do with this. On a single AA battery this design should stay illuminated for several days (I will test this when I find a single AA battery housing that I like).
This design took about 3 working day evenings from reverse engineering the camera flash circuit, dismounting the components, creating a new compact board, shaping some corks, cutting the tube and mounting it all together. I’d imagine that if you knew exactly what you were doing you could have one done in three hours or so assuming no hiccups.
This robot is called Strategus_Aloeus, largely because I’m not great at naming things (also, it looks kinda beetle-esque and the Ox beetle looks kind of squareish). It is a four motor walker which means that it uses just four motors as part of it’s gait. It is currently powered and controlled by (don’t wince – it is a prototype) an Arduino. Each motor is an unmodified servo. After some research I ‘d like to move from C to something more exciting involving neural nets.
The Strategus_Aloeus platform was made for a number of reasons, non the least of which was a desire to investigate this fairly odd way (four motors, one for each leg) of creating a walking robot. I’m not too keen on designs that need dozens of high powered precision servos to get moving like hexapod and octopod designs (most with upwards of 18 locomotory degrees of freedom) – they need intense processing and power just to move and while they are impressive engineering feats they are also delicate and demanding. In short I’m not convinced that designs with fewer moving parts aren’t worthy of study.
A key advantage of this design over more complex designs is it’s low cost and parts count – it can be made from four servos, and Arduino and needs little else. I wouldn’t be too worried about it’s safety if I left it to explore a desk or floor.
One of the main advantages of this design over two and three motor walking robots is that there is considerable scope in the design for changes in body position or “angle of attack”. This could be exploited by the robot in competitive fighting – in much the same way that some horned beetles fight to knock or push each other off something or turn each other over. The angle of attack of the body can be changed while maintaining a forward moving gait, although currently the robot does not do this (it’s something that I will develop later).
Currently the robot is operated by a tether to an Arduino to reduce weight and complexity. Apart from the servos the robot consists of simple leg pieces (plastic) and two flat chip boards bolted together. The servo mountings are friction fit with strategically placed rubber pads on the chipboard. The completed robot will contain some very simple sensory equipment to investigate how little sensory data is needed to (autonomously) competently navigate an environment (or not as the case may be). My suspicion is that measuring changes in body position (e.g. with an accelerometer) while walking is all that is needed to detect things like varying terrain depth, voids, slippery surfaces and so on.
When designing and building Strategus_Aloeus I was aiming at creating a platform with which I could look at some unusual fixed leg/hip quadrupedal gaits. To this end you will notice that Strategus_Aloeus diverges from classic four motor topologies in one important aspect – the leg alignment (axis of rotation) is not parallel across the robot and yet the robot is still strongly directional. As far as I know previous designs focus on either forward leg alignment and strong directionality or symmetric leg alignment and omni-directionality.
This topology maximizes the “yaw” (side to side) component of the gait. This is advantageous because this allows the robot to project it’s front legs forward further when walking while reducing the torsional stresses experienced at each joint. Needless to say this topology also makes the robot much more stable on its side axis (tipping it over sideways is harder). This also allows us to tinker with the amount of torsion that the robot exerts throughout it’s gait.
I have used “gait” to refer to a cyclic series of static positions applied one after the other that, when applied one or more times result in forward movement (verbosely, lets call it a “transient static gait”). A more apt description might be a “static gait” however this definition diverges from the accepted meaning of a static gait insofar as each static position is not guaranteed to be gravitationally stable. At this early stage I have been able to identify 3 separate gaits for this topology, each with benefits and costs associated with it. Each gait can be operated on a range of step widths and body attitudes relative to the ground – which may allow the gait to perform differently. Other ‘active’ gaits such as running, jumping, skipping or hopping cannot be demonstrated in the current model, largely due to the limitations on the speed of the servos used and the in-elasticity of the leg materials.
The most high speed walking modes (irrespective of actual gait, in other words electing for short leg travel range) require the flattest terrain and any small features in the terrain strongly effect direction of travel. Larger (lower speed) modes are afflicted with a high forward motion coupled with a high reverse motion to each step cycle, but typically have much greater odds of surmounting an obstacle.
A video of the rotary screen project in operation is now available. The issues until now were getting a nice balance between brightness and exposure, which was made all the harder by lack of manual controls for these factors in video mode. With variable speed now implemented, the screen can be slowed right down for photography and sped up for readability.
In other news the code is still being tidied as I systematically hunt down every last undocumented method, uncaught exception and random bug. The “bar chart” mode is now complete and looks quite good – it allows a bar chart of up to eight pixels height to be inserted anywhere in the text stream (also shown in the video).
Ever since I saw the “Death Calls the Tune” project by Lab Binaer (via Make and Hack a day) have wanted to get in on the Phosphorescent screen coolness. As luck had it a broken record player showed up in the local pawn shop (someone had torn out the needle assembly, also damaging the USB/sound board). For the princely sum of £1 I was thus the new owner of a skytek tec-3100.
Note: I know the images show the text on the screen to be illegible, I cannot capture with my camera a decent photograph of the screen. Please take my word that it is much more readable in person than the images would seem to indicate.
It doesn’t work by witchcraft, in fact the principle is very simple. Glow in the dark paint (I’ll just call it glow paint) reacts to UV, effectively UV light will “charge” glow paint. When given a very brief flash of UV the paint persists in glowing for a few seconds but the brightness rapidly dwindles. By placing an array of UV LED’s above a moving sheet of glow in the dark material we can draw images and text. Since the paint is brittle the object it is painted on cannot be allowed to warp (or else the paint will eventually flake off), which means that we can either use a spinning disk or other spinning shape that is symmetric about a plane of rotation (like cylinders and cones). A disk is by far the easiest method of achieving the desired effect, and record players already spin disks at a slow steady rate – quietly and very reliably. I decided to use the felt “under mat” that came with the device as the canvas for the paint, largely because the thought of ruining a perfectly good record might upset someone.
Internally tec-3100 was impressive. Control for the stylus arm was all run from a central wheel which had groves that would actuate the movement of the reading arm with a series of control rods, a truly lovely piece of engineering (as you might be able to tell I love smart design like this). Despite the use of USB and micro controllers the stylus arm control was done by mechanical computer to presumably keep costs down. Unfortunately since all this was useless to me I stripped out all of the control rods leaving just the table rotating motor, the power supply and the front switch for speed selection. Happily the damaged USB/sound circuit board was only connected for power (~12v) to the separate “power board” and was removed without fuss.
Movement of the stylus arm is controlled by a tiny (and cheap) servo motor, unit price was roughly £5. Since I cleared out all the control rods and gears there were plenty of mount points for the servo. The connector between the servo horn and the record arm is actually a wooden skewer (with the point cut off). I found that this gave a certain amount of flex that would reduce the stress caused by fast movements of the servo (also it is a nice and cheap, replaceable point of failure in case the arm is subjected to undue stress).
The build went exceptionally smoothly; there are 4 small circuit boards that I had to make, largely because this modular approach allowed me to breadboard and test everything was working board by board. But also because the number and spacing of screw pegs inside the device, and the awkward crevices and nooks lent itself to this approach too. The boards are;
I realised fairly early on that there would simply not be room in the flash of the attiny2313 to contain all the data necessary to render a 8 by 5 fixed width font (and currently I do not have any Atmega devices to hand.). So this data is piped over the serial connection. As a bonus this means font can be dynamically switched if necessary. As a bonus bonus the font does not have to be fixed width. As a bonus bonus bonus you can handle symbols and icons, the only constraint is that the height is limited to 8 pixels. All in all I would say the draw backs with this design are that;
The general principle is that the device operates in one of three modes; output to stylus, move stylus and command mode. In command mode the device waits for a new mode to be given via serial. In Stylus write mode the device outputs every character given to it over serial (if it gets a zero then it clears the output and enters command mode). In Stylus move mode the stylus is moved to any position (0..255) and then returns to command mode. The Stylus movement is limited in software to stop the servo pushing too far and breaking something. Since the “mode” is echoed back over serial the computer can tell if something has gone wrong with the modes and endeavour to fix it. As a side note, more modes can be added if needed with minimal fuss, a provision that may be useful if switching to a more capable platform like an atmega series device.
The computer side “device manager” program reads a “font file” (an XML file with definitions for each character) then connects to the screen and sends instructions to move and write. This device manager is itself connected to by a socket. This allows anyone on the local network to put messages on the screen via the socket. Currently the only functionality is to write text to the screen, and the screen manager moves the cursor and handles font conversions. The current implementation is a proof of concept, I expect to make continuing modifications (see Future section) to bring it up to a release standard.
I’m fairly happy with the result. I would have been happier with access to SMD UV LEDs (alphabet soup!) but the 5 mil LEDs have worked fairly well. I have now realised that the “Death Calls The Tune” project have a very slow rotation on the platform. Currently my implementation is readable but it could be better, and it is certainly not as readable as the project that inspired it. I have no idea how to slow the motor down further, I have hacked the motor to run much slower than it’s default speeds, however it is still marginally too fast. I suspect that limiting the voltage available to it may do the trick. The motor is not a standard stepper/DC motor it appears to have an internal speed controller designed specifically for record players (lowering the voltage may cause it to fail and the motor to stop entirely). I may have to replace the motor, which is a shame but not undo-able.
With all this said the first time the display printed “hello world” I was on top of the world, and I am very happy with the project. Currently I am working on bringing the computer side interface up to scratch, but aesthetically the project is pretty much there, apart from exceptions noted in the “Future” section. The clarity of phrases is limited and the most legible “ring” is the middle ring, the inner ring text is a little warped by being so close to the point of rotation. Conversely, outer ring text is barely distorted at all, but the speed that the table rotates at means you need to be a fast reader. The latter could be mitigated by reducing the table rotation speed, the former by reducing the LED size. The trick to reading the outer ring appears to be to let your eye’s natural reading “skip” reflex to take over and track the words…this is somewhat disconcerting at first and it is easy to fall behind and miss words.
I plan to make some further hardware and software updates;
If anybody wants to do something similar I would be more than happy to help, swap notes and so on. I’m happy to share the code with individuals, however until the project reaches v1.0 stage I can’t say it would be reliable or indeed very good, so I wont release publicly until I am happy with stability and extensibility. The source and any designs still need some tidying. In short the project needs a little more work before I sign my name to the designs, so to speak. Please check back to my blog for updates, source releases and new info.
Since this is the first post I’ll just cover a simple-yet-effective idea. The flat motors from floppy disc drives are commonly referred to as pancake motors (due to their shape). I’ve always wanted to do something with the stators from pancake motors, simply because I think they look fairly good, as components go.
These motors are very good for hacking. They normally have their own board that is mechanically separated from the rest of the drive which makes them highly accessible (I had to unscrew a sum total of 6 screws to get at each of mine – and three of those held the stator down). The boards themselves sometimes have motor drivers and position sensors (and so forth) that in this case are not used, but in other projects could be useful. Removing the coil from the board without breaking the wires is an exercise in patience and care. I find that applying gentle upward pressure and repeatedly heating each pad in turn is the most successful method. Remember that if one or two wires break, the situation can be recovered because we only need 2 sets of coils (the stator pictured has three sets).
I used two of the three sets of coils to make the toroid component of a joule thief circuit. The LED is supported by its legs and extends out from the middle of the stator and points back on itself to illuminate. Since I am no electronics expert I work largely by trial and error, in these cases the resistor needed for the joule thief is typically ~ 0.1kohms but since it is so variable I suggest using a variable resistor (0 to 5kOhms will suffice) to work out where the resonance is, measuring the resistance and replacing it with a fixed resistor of approximately equal value.
With pancake motors I think the effect is fairly good for a minimal outlay of components, effort and time. Also the flower/sun like resemblance is promising for decorations, jewellery etc. Versions of the Joule Thief circuit utilising motors present in small (CPU) fans and laptop CD drives would be ideal embellishments to clothing. Although there is not really much to working out which wire is which on the stator I will write an instructable detailing how to do it (in a short while). In the mean time, more pictures (Bear in mind that these pictures are taken at a long exposure in the dark, results may vary);
Update: I realise that the red version appears very different to the yellow version in the pictures, with the red seeming much more “hazy”. I believe that this is caused by the camera, both units looked pretty much the same by eye, and both photographs were taken using the same equipment. The pictures of the yellow version are a much more accurate representation of their actual appearance (Just imagine it in red ).
Update: The instructable has been published. It is accessible at this address.