July 2010: I built this pretty firefly from some paperclips, LEDs and an ATtiny. It lights up when you hold it, and sleeps the rest of the time. When it lights up, though, it pulses pretty firefly patterns using an 8-bit pseudo-random shift register.

August 2010: Jon and I soldered up the first revision of SelWX, which took ages due to some bent pins on the STM32. Sadly we never got around to writing much code for it so while we got it pinging, that’s about it for r1. We’ll probably do an r2 fairly soon with easier hardware and try to get something working.

October 2010: I wanted to make my long coat light up, so I sewed 20 lillypad LEDs into it. It worked, but only very briefly before my power busses broke, and sadly I didn’t get any photos of it in action. I’ve got the parts to redo it for this winter season though =D

January 2011: Jon and I tried to make a small FM radio transmitter, but it didn’t work. We didn’t have much time to investigate why. I also made a nightlight out of epoxy and coloured dyes and LEDs and all that, but sadly don’t have any photos.

May 2011: I took apart this NERF gun to try and mod it to be fully electronically automatic, with a micro stepper motor mounted inside the clip and a small solenoid actuating the mechanism. Unfortunately the mounting hardware involved proved really complex, and a surprisingly amount of force was required to actuate, so nothing really came of this (but now I have some steppers, solenoids and drivers in my spare parts…)

June 2011: I made this breakout board for an ADF7012 radio to test out some new telemetry ideas for CU Spaceflight. It’s not working yet, but hopefully soon…

Anyway maybe now I’ll do some more hardware stuff and actually blog about it in time!

So, exams are finally over and I’ve had time to get playing with something again. Some friends bought me a NERF Vulcan for my birthday (cheers!) and of course I had to mod it up. The gun itself is now running off a 3-cell lipo pack, which about doubles the rate of fire, and has three ammo belts chained together to give 74 rounds in one continuous burst of fire.

I then hooked up an Arduino and servo motor to a series of cabletied pencils, which can pull the trigger on command. The Arduino and a USB webcam then connect to a laptop which is running motion and a small python script which interfaces to the Arduino and plays sound clips from Portal turrets when motion is detected/no longer detected.

The whole thing works very nicely, shooting down anyone who walks into my room with a rapid burst of darts, and terrifying them with the portal turret sounds.

Check out http://www.flickr.com/photos/randomskk/sets/72157624178093055/ for more photos!

I modified Principia Lab’s servo code from here and motion and Portal turret sounds from Valve’s Portal and the code below for controlling motion and the arduino and playing the sound files:

I’m part of CU Spaceflight, and since we have clearance to launch high altitude balloons from a few nearby locations we often do launches for other people. A lot of the time these launches have a radio transmitter on board, so that people around the country can pick up its GPS position and help keep track of the balloon’s location. We were helping with a launch a few weeks back which didn’t have a radio transmitter, but instead planned to rely on a GSM based system to text the GPS coordinates back. Jon Sowman and I decided to whip up a small radio tracker based on some work that had previously been done by Iain Waugh at CUSF. Six hours later, we’d completed Ferret 1!

It consists of an Arduino with some stripboard stuck on top. The strips on the stripboard were cut down the middle with a dremel, then we soldered some pin headers on to mate with the power and lower digital pins on the arduino. We didn’t need any of the higher digital pins, so the alignment issue wasn’t a problem. We then stuck an EM-406a GPS unit and a Radiometrix NTX2 on top along with a few required resistors and capacitors. The radio requires an antenna, which we constructed out of some mini coax soldered to the stripboard, a small square of copper clad board with a hole drilled through and five 17cm long bits of single core wire. Four of the wires were soldered onto the corners of the copper clad board sticking outwards, while the fifth was soldered to the centre conductor of the coax. This results in a quarter-wave antenna with a ground plane, which is great because almost all the radiation goes downwards in a fairly nice pattern.

Antenna done, we hacked up Iain’s code and flashed that onto the arduino and gave the whole system a quick test with a radio lying around the lab:

This was successful, so we put the whole thing in a box, taped it down and were ready to go!

We duct taped it to the main payload and launched it the next morning.

UKHAS Church Hill Site Project Orion
Uploaded by kannasnakka. – More video blogs and vloggers.

The first launch attempt didn’t go so well, with too little helium resulting in us almost taking out some football players. Luckily we were able to grab the balloon and refill, getting a successful second launch. The video above is from Scott James, whose flight we were piggybacking on. He had an actual video and still camera onboard.

Sadly, shortly after crossing the meridian the GPS lost lock and for a while we didn’t get any new data. Eventually, the data picked up again — but with a suddenly discovered bug in the code! We were transmitting the decimal part of the degrees as as unsigned integer when in reality they were signed, leading to some pretty significantly incorrect results. Luckily we were able to figure out how to determine the actual position from the data it was transmitting (thanks, SpeedEvil on #highaltitude on irc.freenode.net!) and the balloon was successfully recovered.

Ferret is on its way back to us in the post now and hopefully will live to fly another day!

P.S. we got hackaday‘d too!

I’m pretty happy with how this turned out, and I can finally say the nixie clock project is finished. I definitely learned a lot for the next clock – like use the RTC with an onboard crystal! I’m thinking of perhaps making a wordclock.

You can check out the Inkscape files I sent to Ponoko for manufacture here (they are released under CC BY-SA 3.0 if you are interested).

In unrelated news, design on revision four of my motor controller is nearing completion, so hopefully the thing will be flying soon!

After a couple of weeks of waiting around, I’ve got all the parts I’ve ordered so far: a basic aluminium chasis from MikroKopter, four 1040Kv/14A brushless motors, four propellers, some 3000mAh 3S lipo batteries, and a whole suite of sensors on breakouts from SparkFun, including an accelerometer, gyroscopes, barometer, magnetometer and GPS. I’ve also got spares of a few parts and a second set of accelerometers and gyroscopes to compare with.

I also bought four normal brushless motor controllers, which take a PWM input and control the motor. They’re fine for prototyping with, but I plan to make my own motor controllers that will take throttle values at a much higher rate over I²C, as well as being capable of reporting information (voltage, current, rpm) back to the main controller. However, I’ve not bought the parts for the motor controllers yet, so for now I’m using the pre-made ones.

To start with, I’m writing code to read all the sensors and check their results. This also means I can plug the sensor values into a simulation on my computer to test filters and control code, rather than having to run it on the quad every time I need to change a parameter. All the code is on GitHub: http://github.com/randomskk/Robot4 and so far I’ve written code for the accelerometer (SCA3000) and the barometer (SCP1000). The accelerometer values are read into memory the whole time over DMA, while the barometer is polled when required as its update rate is about 2Hz so there’s no point wasting a DMA channel. The next thing to do will be the gyroscopes.

I’ll post updates here as the robot progresses…

I proceeded to rip out all its electronics and battery contacts and cover etc, leaving just the underchasis and two motors. I then put my own little 900mAh lipo in the battery compartment along with a small motor driver board (two h-bridges), with all the wires running through the old contact holes. An STM32 dev board went on top and connects to a Sharp IR rangefinder and xbee radio.

All I had it do to start with was drive forwards, then when the ADC detected the voltage from the Sharp sensor went over the limit that indicated an obstacle was ahead, an interrupt fired which caused the car to reverse back and to the left slightly. This was enough to avoid most collisions so the car could pretty much drive about as it wanted. Later I added remote control from a computer over the xbee, with the same interrupt code for collisions. I was planning to put a GPS and some other sensors on the car, but shortly after making it I ordered all the parts for my upcoming quadcopter, which is going to take the limelight for now.

I decided I wanted something with a lot of interface peripherals, so broke out USART1, 2 and 3, I²C1 and 2 (also USART3) and SPI1 and 2. Additionally a USB plug is connected to the USB peripheral, and JTAG is available. The 6pin header for USART1 is compatible with the FTDI cables/breakouts which makes interfacing with an FTDI cable for programming (the bootloader listens on USART1) or with an xbee on one of SparkFun’s breakouts is very easy.

So far I’ve used one of these boards for Robot3 (an upcoming post) and plan to use the second to start prototypes with my quadcopter UAV. They’re pretty useful, uploading code to them is quick and easy with the bootloader, and having that many peripherals available and capable of running at pretty high speeds makes these boards handy to have around.

Eagle files and a PNG here.

Everyone has to make a nixie clock at some time, and as I had 12 IN-14 type tubes lying around for quite a while after ordering them from Russia, I decided I should go ahead and make one. PCBs were designed in due course and sent off to Gold Phoenix for manufacture, and eventually I got back a whole load of PCBs and fabbed up the clock.

There are three main parts: the power supply unit, the control board, and one driver board per two nixie tubes.

Power Supply
I borrowed heavily from http://desmith.net/NMdS/Electronics/NixiePSU.html in both the schematic and PCB layout, as I don’t have much experience in fast or high voltage layout and didn’t want to make any crucial mistakes. I did make a few modifications to suit what components I could get and in a few cases routings I thought could reduce via count or otherwise shorten traces. The design works very well, and successfully drives the nixies at sufficient brightness.

The power supply takes around 12V DC input and converts it to around 220V DC output in a switch mode design. Essentially, the microchip opens the FET, current flows through the inductor and then through the FET to ground, then the FET closes. As the current in the inductor still has a kind of ‘momentum’ (the magnetic field it created tries to keep the current moving) but nowhere to go the voltage rises and goes through the fast diode to charge the capacitor. Once the voltage reaches the desired level, the FET is switched back to ground again and the process repeats. The output is a relatively smooth DC. (NB: this description could be very wrong, it’s just how I believe it works – please leave a comment to correct me!)

Control
The control PCB contains an ATmega168, the DS1307 real time clock IC and a whole load of buttons used for setting the time. The RTC IC is set with a time once and then keeps it as accurately as it can, using the onboard battery backup to provide a tiny amount of power when the mains electricity is removed. The buttons make setting the time fairly easy; you just hold down the time item you want to change (hour/min/sec/day/month/year) and press the up or down button to adjust, holding it down to make large changes.

Driver
The driver PCB contains two nixie tubes, two old 7414N logic chips (actually I used Russian equivalents) and an 8bit shift register. The control board shifts out BCD (binary coded decimal) to the shift registers, four bits per display digit. The shift registers then output this to the 7414Ns which decode it and pull one of their ten outputs to ground. That output is connected to one of the numerals in the nixie tube, causing it to light up.

Overall, I’ve found it to be a really neat clock. I plan to make a nice case for it at some point in the future, but making nice cases is not a strong point for me, so I’m not sure when exactly this will happen. For the moment, the clock sits on a shelf next to my desk where I can easily see it from anywhere in the room. The digits are bright enough to see clearly, but the clock turns off the display between 00:00 and 07:00 so I can get to sleep! Turning off the tubes also helps extend their lifetime. Just before turnoff, each tube cycles through all of its digits for a few minutes to prevent cathode poisoning, where little emissions from lit numbers coat the unlit numbers and make them dimmer. Finally, clock accuracy leaves a little to be desired – it is routinely out by a minute or two every couple of weeks. It is easy to adjust and a minute isn’t that big a deal, but I would have hoped the crystal would be more accurate.

At the end of the day though, it’s a fun clock and is my favourite for checking the time!

All the Eagle files as well as PNGs of the PCBs are available here: https://randomskk.net/projects/nixie_clock and more photos are available on Flickr here.

(YouTube video)

I’ve finally got around to writing up this project! What you see above is a small robot with a gooey ARM Cortex-M3 STM32 core, a teensy embedded camera from SparkFun, an OLED and an LCD screen, three LiPo batteries, some modified servos and a one-piece (unibody!) aluminium case. The robot uses the camera to track colour, moving towards it.

This project was actually a final year school project, so I didn’t even have to pay for it, which is good – the PCBs were ordered as a panel from China, I went through several of the ARMs, and some of the other parts did not come cheap. At the end of the day, though, it works! It took a long time to get there, though…

1. Prototyping

I’d never used an ARM before, which means I wanted to try one out before going for the real thing. However, I wanted to try with the chip I’d actually be using, and getting one on a premade PCB seemed like a pointless expense (how I regret thinking that…), so I made a simple breakout board and soldered one on. By hand.

Incredibly, this actually worked. It took a long time to get openocd installed and talking to the programmer (an ARM-USB-TINY from Olimex), and about as long again to actually program anything to the chip. Eventually I had that cracked and moved on to compiling my own code instead of just uploading a sample hex file. Many hours of struggling later I had a working Makefile using the Codesourcery GCC port. It was time for a more complicated Hello, World:

With this out of the way, I moved on to:

2. Design

Since this is a school project, design is important – I had to actually write this stuff up! (a 69-page A3-size Powerpoint file.) First up was schematic capture, which I did in EAGLE and involved separate designs for the main board, the camera, the OLED carrier and the SD card carrier. This is where I made a few crucial and stupid mistakes, like wiring the ARM’s analog ground to Vcc and the analogue supply to GND:

The PCB design took a few days but eventually I’d made up a design for each of the boards, and panelised these with GerbMerge to be sent off to Gold Pheonix. I even got to pick black soldermask!

The case design, while straightforward, was fun. Normally we’d use vacuum formed plastic or MDF at school, so stretching to some sheet aluminium was exciting. It’s just normal aluminium with some holes drilled into it for the PCBs to mount to, though. The design was done in ProDesktop.

Schematic and PCB designs are linked at the end of the post.

3. Manufacture

Once the PCBs and components arrived I decided to try out reflow soldering, instead of just hand soldering all these components. It worked really well – I got some solder paste, put a little blob on each pad, placed the components and then shoved it under the grill on full heat until it reflowed.

In the end I used up every one of the control boards until I finally got it right at the end – there were a few problems with the reflow soldering after someone moved the tray down one position to grill a steak (and yes, I’ve heard all the steak and chips jokes ) and that threw off a few boards. The required fix for the swapped AVcc/AGND pins on the ARM wasted a few more. In the end, I got one right and that’s the one that’s now in the robot.

4. Programming

Programming this thing essentially involved an awful lot of C calling the libraries that ST provide and a bit of assembler for that speed-critical reading data from the camera. This part took ages to develop, as the camera basically just sends data as fast as it pleases and there’s no simple way to manage this when your microchip has less RAM than one image from the camera. I ended up getting a logic analyser to help out, and was soon able to pick out what the camera was sending:

A logic trace from the camera

I was trying to see what the camera was showing, but this was really difficult to accomplish – there was no way to send data to the OLED screen fast enough, and no way to store the entire image in memory. I suddenly realised I could use one of the tiny LCDs from SparkFun – they work over SPI, which I’d already broken out for an SD card (that ended up unusued), and they even took the same data format the camera was sending! They turned out to be absolutely perfect for the job. All I had to do was read in each line of data, store it in memory, then trigger the DMA controller to copy that out over the SPI port. It only took a few lines of assembler and suddenly the LCD was showing exactly what the camera sent. Perfect!

From there I was quickly able to add the colour tracking part – for each pixel, it checked if it was close enough to red, and if so it used a simple centre-of-mass calculation to determine the average red position in the camera’s field of view. This technique worked pretty well.

I added a simple menu on the OLED – you can toggle turning, driving and lights.

The nav switch is a handy little SparkFun switch that works really well for this application.

5. Summary

There was a lot more to this thing’s development – like how to route power from 3 batteries to the two servos and the main logic, making the small breakout PCB for the LCD that included its own vreg and some status LEDs, endless cursing of various bits and pieces of the build environment, trying to affix two servos to a flat piece of aluminium and playing with supporting FAT on the SD card (harder than it might appear), to name just a few. Talking about all of them would take forever, though, so instead I’ve written what I hope is a more interesting to read summary.

6. Resources

The C/ASM code is available on GitHub: http://github.com/adamgreig/followingrobot which includes the build environment, makefile, etc etc. This might be pretty useful if you were trying to program one of these chips.

The EAGLE sch/brd files are available here: https://randomskk.net/projects/robot2/robot2_eagle.zip which also includes the SparkFun LCD breakout board and footprint, which could come in handy.

If you’re really interested, the humangous PPT that contains a lot more detail on pretty much every stage of making this thing, as well as more photographs and logic traces and such (and also a few boring waffle pages I have to include) is available here: https://randomskk.net/projects/robot2/robot2_coursework.ppt

Finally, here’s the Flickr photo set: http://www.flickr.com/photos/randomskk/sets/72157607851550306/

Please do post a comment if you have any questions!

And just to whet your appetite: the nixie clock PCBs have been sent off for manufacture and all the components have arrived! I should have a writeup of that in a few weeks once it’s all been put together.

It’s been a while since I’ve posted anything, so I’ll drop a quick update. Hopefully by the end of the coming week I’ll have finished on my current great big time-consuming project and will be able to write that up.

I’ve been playing with a few things besides that project, though. The first is stress testing my small and somewhat dodgy NIXIE PSU, which amazingly has managed to drive eight tubes:

I plan to finish off designing a somewhat more powerful power supply so I don’t worry about it exploding in my face every time I try using it. A better way to control it than a plain RTC would be nice too – I’m thinking of using a GPS module.

(p.s. yea, I accidentally set the 8 on instead of the 9 and didn’t realise — oops!)

The other thing I’ve recently been playing with is an accelerometer I got for Christmas. It’s the LIS302DL from Sparkfun, a super cheap 3-axis accelerometer that can output on SPI or I²C, has interrupts for freefall and things like the user tapping it or double tapping it, and adjustable sensitivity – 2g or 8g. All that for $20 on a breakout board is pretty incredible!

I hooked it up to an Arduino and after some messing around, was able to get it to read the acceleration data from the sensor over I²C, and then send it to the PC with a timestamp over serial (itself over USB). Then I whipped up a quick Python script to plot the data and decided I’d test something that’s now been thoroughly battered into me: in simple harmonic motion, the acceleration on a particle is proportional to its displacement, which can be shown to mean it is a sine wave. I figured that’s as good a way as any to test the sensor, and so I took the Arduino and swung it as a pendulum from its USB cable.
I then had Python generate the magnitude of the acceleration – the single value showing the resultant acceleration on all three axis. This was plotted against the millisecond value from the arduino and hey presto – a (nearly) perfect sine wave!

Not bad! The accelerometer itself:

(p.s. be sure to view the full sized image for tons of lovely macro sharpness)

arduino_loguino – the arduino code (CC BY-SA 3.0)

python_loguino – the python code (Public Domain)

For bonus points: Given that the Arduino was on the Earth’s surface, and that the millisecond data is accurate, how long was the USB cable the Arduino was swinging from?

]]> http://negativeacknowledge.com/2009/02/nixies-and-accelerometers/feed/ 0