It seems that we've had a massive amount of interest in the Invisible Instrument Kits already, so if you're not able to get your hands on one (either at the event, or through the BuildBrighton website) here's a list of what you need.
All the components are available through Farnell.
They've just launched a hacker/maker community called element 14 and are really helpful towards the design/prototyping community. And you can order stuff today and get it by 10am the next morning!
As well as the PCB (you can etch this yourself) you'll need:
1 x PIC 18F2455
2 x 14-pin MCU socket (optional, or replace with 1x28 pin socket)
1 x USB B-type socket
1 x 470nF capacitor
1 x 20Mhz crystal
4 x LDRs (light dependent resistors)
4 x 1M linear potentiometers
And of course, some firmware for the PIC microcontroller.
Here's a pre-compiled hex file you can burn to the chip using any PIC programmer:
http://www.nerdclub.co.uk/files/invisible_instrument_simplified.rar
That's it for the simplified kit. If you want to use the LED indicators (which light up as each input detects and triggers a sound) you might want to use
4 x 5v LEDs
Alternatively, you can use the invisible instrument to play up to 4 sounds per input, and instead of LED outputs, use the same sets of pins to connect pushbuttons to, in order to turn the extra sounds on or off. In which case, you'll need:
4 x push button switches
Happy shopping!
Sunday, 29 May 2011
Invisible instrument - simplified details
As the Brighton Fringe Festival draws to a close, BuildBrighton are hosting a drop-in "Noise Toys" workshop at Hectors House (strictly speaking, it's not Hectors House anymore, since it was recently taken over by a community arts/maker group, but everyone still knows it as that).
We've submitted a simplified version of our invisible instrument that has been made into kit form, so people can make one up and try it out in just a few hours. We've removed the LCD, LEDs and buttons and MIDI output, making it much more like the original prototype.
Build Bright On Invisible Instrument
A datasheet and instructional guide is available here on Scribd. Schematics (printable at 100% to make your own) are below:
Invisible Instrument Simpified
We've submitted a simplified version of our invisible instrument that has been made into kit form, so people can make one up and try it out in just a few hours. We've removed the LCD, LEDs and buttons and MIDI output, making it much more like the original prototype.
Build Bright On Invisible Instrument
A datasheet and instructional guide is available here on Scribd. Schematics (printable at 100% to make your own) are below:
Invisible Instrument Simpified
Thursday, 26 May 2011
Invisible instrument - simplified
As part of the Brighton Fringe (and partly why there's been little blog activity of late) the BuildBrighton group are hosting a daytime workshop followed by an evening gig filled with 8-bit bleeps and electronic music.
I've made a simplified version of the invisible instrument - removed the character LCD and buttons and LEDs, so it's just a voltage divider going into a microcontroller. The idea is to have up to twenty people making their own (from kits) at the workshop, then having a go playing them together! So I've been busy etching PCBs all afternoon.
Here's a shot of what 20 home-made invisible instrument PCBs look like:
They still need drilling (28 pin mcu + 4x2 legs on LDRs + 4x3 legs on potentiometers + crystal + cap + vias) over 50 holes per board. I think that's a job for the power tools at the Skiff this evening.
Now with just a few hours left, I need to write some simplified firmware (with the new pin input mapping) and software for the PC to make it play tunes...
I've made a simplified version of the invisible instrument - removed the character LCD and buttons and LEDs, so it's just a voltage divider going into a microcontroller. The idea is to have up to twenty people making their own (from kits) at the workshop, then having a go playing them together! So I've been busy etching PCBs all afternoon.
Here's a shot of what 20 home-made invisible instrument PCBs look like:
They still need drilling (28 pin mcu + 4x2 legs on LDRs + 4x3 legs on potentiometers + crystal + cap + vias) over 50 holes per board. I think that's a job for the power tools at the Skiff this evening.
Now with just a few hours left, I need to write some simplified firmware (with the new pin input mapping) and software for the PC to make it play tunes...
Sunday, 22 May 2011
No updates for a few days
But that's because we're bang in the middle of the Brighton Fringe Festival and there's so much going on around the city that there's not much time for nerding about!
That said, after wandering past the Theatre Royal earlier today, we came across the amazing Paka and His Mechanical Horse video from an earlier performance - hopefully one from the 2011 Fringe Festival will get posted to YouTube soon enough!
Unlike these performances the crowd was really close to the horse - the guy controlling the robotics did a fantastic job and the rider had his hand close to the emergency off switch on more than one occasion - it was so close that members of the audience were reaching out and patting the horse on the nose!
Thankfully the Fringe Organisers refuse to let Health and Safety get in the way of the performances: in just about any other place I suspect these sort of things would be barred or severely toned down!
More nerdy goodness towards the end of the month.....
That said, after wandering past the Theatre Royal earlier today, we came across the amazing Paka and His Mechanical Horse video from an earlier performance - hopefully one from the 2011 Fringe Festival will get posted to YouTube soon enough!
Unlike these performances the crowd was really close to the horse - the guy controlling the robotics did a fantastic job and the rider had his hand close to the emergency off switch on more than one occasion - it was so close that members of the audience were reaching out and patting the horse on the nose!
Thankfully the Fringe Organisers refuse to let Health and Safety get in the way of the performances: in just about any other place I suspect these sort of things would be barred or severely toned down!
More nerdy goodness towards the end of the month.....
Sunday, 15 May 2011
Loads of servos!
Just a quick post showing the latest version of the USB servo controller board, driving six independent servos at a time (it was going to be eight, as we'd originally ordered six servos off eBay to go with the two we've been testing with. They finally arrived yesteryday, but two of them don't seem to work properly - the servos chatter and sound terrible, whatever position they're moved to - so we've left them off the video.)
But as a proof-of-concept, it works pretty well:
The two (older) servos on the right seem to move in the opposite direction to the smaller, newer 9g ones. Maybe because they're by different manufacturers? Or maybe they're meant to be mounted the other way around - who knows??
For anyone interested, here's the full script of the animation being played out:
label 900,1
servo 1000,8,150
servo 1000,9,150
servo 1000,10,150
servo 1000,11,150
servo 1000,12,150
servo 1000,13,150
servo 2000,8,60
servo 2000,9,200
servo 2000,10,60
servo 2000,11,200
servo 2000,12,60
servo 2000,13,200
servo 3000,8,150
servo 3000,9,150
servo 3000,10,150
servo 3000,11,150
servo 3000,12,150
servo 3000,13,150
servo 4000,8,60
servo 4000,9,60
servo 4000,10,60
servo 4000,11,60
servo 4000,12,60
servo 4000,13,60
servo 5000,8,200
servo 5000,9,200
servo 5000,10,200
servo 5000,11,200
servo 5000,12,200
servo 5000,13,200
servo 6000,8,150
servo 6000,9,150
servo 6000,10,150
servo 6000,11,150
servo 6000,12,150
servo 6000,13,150
servo 7500,8,60
servo 7000,9,60
servo 7100,10,60
servo 7200,11,60
servo 7300,12,60
servo 7400,13,60
servo 8000,13,150
servo 8100,12,150
servo 8200,11,150
servo 8300,10,150
servo 8400,9,150
servo 8500,8,150
tloop 8600,1 'goto label 1
end 15000
But as a proof-of-concept, it works pretty well:
The two (older) servos on the right seem to move in the opposite direction to the smaller, newer 9g ones. Maybe because they're by different manufacturers? Or maybe they're meant to be mounted the other way around - who knows??
For anyone interested, here's the full script of the animation being played out:
label 900,1
servo 1000,8,150
servo 1000,9,150
servo 1000,10,150
servo 1000,11,150
servo 1000,12,150
servo 1000,13,150
servo 2000,8,60
servo 2000,9,200
servo 2000,10,60
servo 2000,11,200
servo 2000,12,60
servo 2000,13,200
servo 3000,8,150
servo 3000,9,150
servo 3000,10,150
servo 3000,11,150
servo 3000,12,150
servo 3000,13,150
servo 4000,8,60
servo 4000,9,60
servo 4000,10,60
servo 4000,11,60
servo 4000,12,60
servo 4000,13,60
servo 5000,8,200
servo 5000,9,200
servo 5000,10,200
servo 5000,11,200
servo 5000,12,200
servo 5000,13,200
servo 6000,8,150
servo 6000,9,150
servo 6000,10,150
servo 6000,11,150
servo 6000,12,150
servo 6000,13,150
servo 7500,8,60
servo 7000,9,60
servo 7100,10,60
servo 7200,11,60
servo 7300,12,60
servo 7400,13,60
servo 8000,13,150
servo 8100,12,150
servo 8200,11,150
servo 8300,10,150
servo 8400,9,150
servo 8500,8,150
tloop 8600,1 'goto label 1
end 15000
Thursday, 12 May 2011
Invisible instrument - different modes
click to view larger image with readable text!With the introduction of a 16x2 character based LCD display, and a dial (ok, in this instance a slider, but it should be a rotary dial) and some buttons, we can set the device into a number of different modes.
when tuning the input channels, the LEDs light up to show when a channel has detected a shadow and raised a "hit" value. In this case, because the LDRs were not inside their black tubes and the light is coming from behind, the camera actually cast a shadow onto the device, triggering two inputs!Here we've set the device into "tuning" mode. It basically reads the input value from each channel/LDR and displays a message telling the user which way to "tune" the device. In an ideal world, each input should be around the half-way mark (reading a single-byte value of 128) so that changes in ambient light can be easily detected.
In this example, the display is showing that the "at rest" value is greater than 128 and so the user should adjust the pot on the first LDR. When the ideal value is reached (120-140) the LCD display will read "OK" and the user can use the slider to choose another channel to "tune".
It is important to use linear (not log) potentiometers for the tuners.
In fact, I didn't have linear pots to spare, and used log pots, but tuning is difficult because there is very little movement between too high and too low. A linear pot would be preferable here!
Assembling the invisible instrument
Here are some shots of the invisible instrument undergoing assembly.
It took a number of failed boards before we settled on this design (and even this is a bit messy - we still need to move a few 5v and ground pins to stop the cables for the LCD display getting everywhere) After a couple of failed boards, we finally managed to get one working that we were happy with! The main problem with the original PCB layout was the LDRs were mounted with the legs running east-to-west. No big deal? Not until we put the black tube covers over them and tried to bend them into position.
Because of the way the legs were facing, there was no give in them, to allow them to bend - they happily moved backwards and forwards, but not left-to-right.
This has been corrected in the latest PCB layout.
See photo (below) for the correct way to mount the LDRs:
Note also that the LDRs are unlike other components - they are not mounted flush to the board, but a few millimetres left on each leg. This allows the LDRs to be bent into the correct position once the black tubes are put into place.
Here's the board with all the cables for the LCD screen in place too.
We added the screen to allow the user to interact with the device (set ambient light levels, change chord sequences/scale modes etc) without having to refer back to the PC. The idea behind this was to allow the device to be converted into a MIDI instrument in future.
Note: the green LED does nothing special - I just ran out of 5v red ones!
We're off to BuildBrighton tonight and hope to spend a bit of time on the laser cutter there, making up a cool enclosure from 3mm acrylic. Then it's just a case of a few firmware updates, and another project will be officially complete!
It took a number of failed boards before we settled on this design (and even this is a bit messy - we still need to move a few 5v and ground pins to stop the cables for the LCD display getting everywhere) After a couple of failed boards, we finally managed to get one working that we were happy with! The main problem with the original PCB layout was the LDRs were mounted with the legs running east-to-west. No big deal? Not until we put the black tube covers over them and tried to bend them into position.
Because of the way the legs were facing, there was no give in them, to allow them to bend - they happily moved backwards and forwards, but not left-to-right.
This has been corrected in the latest PCB layout.
See photo (below) for the correct way to mount the LDRs:
Note also that the LDRs are unlike other components - they are not mounted flush to the board, but a few millimetres left on each leg. This allows the LDRs to be bent into the correct position once the black tubes are put into place.
Here's the board with all the cables for the LCD screen in place too.
We added the screen to allow the user to interact with the device (set ambient light levels, change chord sequences/scale modes etc) without having to refer back to the PC. The idea behind this was to allow the device to be converted into a MIDI instrument in future.
Note: the green LED does nothing special - I just ran out of 5v red ones!We're off to BuildBrighton tonight and hope to spend a bit of time on the laser cutter there, making up a cool enclosure from 3mm acrylic. Then it's just a case of a few firmware updates, and another project will be officially complete!
Speed up etching times
Like many people who post on the internet, I've used online guides for etching my own PCBs. I use press-n-peel blue and a laminator (a big chunky metal thing built by Alphatec which is just perfect) to create toner-transfer etch masks. Like most other people, I put my ferric chloride into a shallow, flat container and etch by gently rocking it from side to side, so that the etchant "washes over" the PCB:
The other day, after making up three failed Invisible Instrument PCBs and putting all my messy PCB making equipment away I decided to quickly throw a board together to try out a new idea. Instead of pouring the ferric chloride into a shallow tub, I suspended the board on a piece of wire and just dunked it in and out of the etchant (I always replace my ferric chloride into a large coffee jar - the batch I have at the minute has been reused regularly for about 12 months and is still going strong!)
The peculiar thing was the board etched in no time!
Normally I heat up the etchant by placing the shallow tub into a larger container filled with hot water. This time, I etched "cold" but inbetween dunking, lifted the board completely clear of the etchant. It's well known that agitating a copper board in ferric chloride speeds up etching (and that heating the etchant gently also reduces etching times). What I hadn't realised until now was that exposing the board to the air during etching also seems to improve etching times too.
In fact, I noticed that the board etched from the top, down. i.e. the parts of the board that were out of the ferric chloride for longer actually etched quicker. While this seems counter-intuitive, maybe some chemistry genius will explain how oxidisation (or something) improves etching time.......
Anyway, it works for me. And from now on, my ferric chloride will stay in it's large coffee jar - my brown-stained plastic tubs have been junked and if anyone asks, I'll tell them I'm a dunker, not a rocker.
The other day, after making up three failed Invisible Instrument PCBs and putting all my messy PCB making equipment away I decided to quickly throw a board together to try out a new idea. Instead of pouring the ferric chloride into a shallow tub, I suspended the board on a piece of wire and just dunked it in and out of the etchant (I always replace my ferric chloride into a large coffee jar - the batch I have at the minute has been reused regularly for about 12 months and is still going strong!)
The peculiar thing was the board etched in no time!
Normally I heat up the etchant by placing the shallow tub into a larger container filled with hot water. This time, I etched "cold" but inbetween dunking, lifted the board completely clear of the etchant. It's well known that agitating a copper board in ferric chloride speeds up etching (and that heating the etchant gently also reduces etching times). What I hadn't realised until now was that exposing the board to the air during etching also seems to improve etching times too.
In fact, I noticed that the board etched from the top, down. i.e. the parts of the board that were out of the ferric chloride for longer actually etched quicker. While this seems counter-intuitive, maybe some chemistry genius will explain how oxidisation (or something) improves etching time.......
Anyway, it works for me. And from now on, my ferric chloride will stay in it's large coffee jar - my brown-stained plastic tubs have been junked and if anyone asks, I'll tell them I'm a dunker, not a rocker.
Monday, 9 May 2011
Shadow Harp/Invisible instrument
With the USB servo controller board pretty well complete (well, the hardware and firmware at least - there's some software to do, making animation creation simpler, but for now, anyone with Notepad can create a simple animation script) thoughts are turning to the BuildBrighton music gig at the end of May, as part of the Brighton Fringe Festival.
With a working prototype already in the bag, and an enclosure design already planned, if not drawn out yet, it's time to put the whole thing together onto a PCB and get soldering!
Here's the first version of a PCB. It's not been tested yet, but has been built with reference to the schematics posted earlier.
Shadow Harp v1 Pcb
As always, print at 100% landscape orientation for press-n-peel toner transfer to make your own version of the invisible instrument
Refer to the schematics and follow the silkscreen layout below for help placing components on the border before soldering:
With a working prototype already in the bag, and an enclosure design already planned, if not drawn out yet, it's time to put the whole thing together onto a PCB and get soldering!
Here's the first version of a PCB. It's not been tested yet, but has been built with reference to the schematics posted earlier.
Shadow Harp v1 Pcb
As always, print at 100% landscape orientation for press-n-peel toner transfer to make your own version of the invisible instrument
Refer to the schematics and follow the silkscreen layout below for help placing components on the border before soldering:
This layout has been updated, to include the USB socket on the board but more importantly, the orientation of the LDRs has changed. On this board, the LDRs will not bend easily side-to-side, which is important for setting up the device to play! An updated layout will be posted shortly!
USB servo board - almost done?
This is looking like the final version of the servo board and includes a number of cool enhancements:
At any point in the script, the user can place a label.
This is marker point from where you can play back sections of an animation.
Users can place GOTO commands in the script, such as "goto 1500ms" (the animation jumps to the point 1.5 seconds into the animation) or "goto label 4". It is this second GOTO command that makes the servo board so useful:
We've also updated the firmware so that one or more of the servo pins can be used as input triggers. Simply tell the board how many input pins you want to use (0-8) and when the appropriate input pin is pulled low, the animation playback jumps to that label number.
For example, pull the first input pin (normally servo 20) low and playback immediately jumps to label 1. Pull the second input pin low (normally servo 19) and playback jumps to label 2. Because our servo pins have ground on the outside and signal on the inner (the middle pin is always 5v) the button in the video simply bridges the two outer pins, to pull the input pin low.
Here's the full script, as used in the video above:
'this is the first animation
'it can also be triggered by sending PORTB.7 low
label 500,1
servo 1000,9,50
servo 1000,10,50
servo 2000,9,220
servo 2000,10,220
servo 3000,9,50
servo 4000,10,50
servo 5000,10,220
servo 6000,9,220
tloop 7000,1000 'go to time point 1000
'this is the second animation loop
'triggered when PORTB.6 goes low
label 10000,2
servo 10000,9,150
servo 10000,10,150
servo 11000,9,220
servo 11000,10,50
lloop 12000,2 'go to label 2
end 15000
At any point in the script, the user can place a label.
This is marker point from where you can play back sections of an animation.
Users can place GOTO commands in the script, such as "goto 1500ms" (the animation jumps to the point 1.5 seconds into the animation) or "goto label 4". It is this second GOTO command that makes the servo board so useful:
We've also updated the firmware so that one or more of the servo pins can be used as input triggers. Simply tell the board how many input pins you want to use (0-8) and when the appropriate input pin is pulled low, the animation playback jumps to that label number.
For example, pull the first input pin (normally servo 20) low and playback immediately jumps to label 1. Pull the second input pin low (normally servo 19) and playback jumps to label 2. Because our servo pins have ground on the outside and signal on the inner (the middle pin is always 5v) the button in the video simply bridges the two outer pins, to pull the input pin low.
Here's the full script, as used in the video above:
'this is the first animation
'it can also be triggered by sending PORTB.7 low
label 500,1
servo 1000,9,50
servo 1000,10,50
servo 2000,9,220
servo 2000,10,220
servo 3000,9,50
servo 4000,10,50
servo 5000,10,220
servo 6000,9,220
tloop 7000,1000 'go to time point 1000
'this is the second animation loop
'triggered when PORTB.6 goes low
label 10000,2
servo 10000,9,150
servo 10000,10,150
servo 11000,9,220
servo 11000,10,50
lloop 12000,2 'go to label 2
end 15000
Saturday, 7 May 2011
USB servo board update
We're getting close to finishing the 20-channel USB servo controller board.
This latest update has the servos in the correct place on the board (previous versions of the firmware numbered the servos according to the pins/ports they were on, but the PCB layout made them appear to be randomly placed!)
This latest update also includes a surface mount Flash eeprom, rather than an 8-pin DIP. This means that the 8-pin chip appears reversed when the PCB is printed (pin1 is top right, not top left) but when toner-transferred, will appear the right-way around. We had to swap a few pins around on PORTA to simplify the layout for the PCB so a new schematic is included below.
Also to note is that on this board, the SMT memory chip will actually be on the underside (where all the pins are soldered to the copper board).
Servo Usb Smt Eeprom Schema
Servo Usb Smt Eeprom
Print at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this USB servo controller board with SMT eeprom chip
We're also working on one last final revision of the firmware, to allow the user to place "labels" along the timeline, and to have the servo controller board jump to specific points along the timeline. This will become clearer as screenshots of the software become available....
This latest update has the servos in the correct place on the board (previous versions of the firmware numbered the servos according to the pins/ports they were on, but the PCB layout made them appear to be randomly placed!)
This latest update also includes a surface mount Flash eeprom, rather than an 8-pin DIP. This means that the 8-pin chip appears reversed when the PCB is printed (pin1 is top right, not top left) but when toner-transferred, will appear the right-way around. We had to swap a few pins around on PORTA to simplify the layout for the PCB so a new schematic is included below.
Also to note is that on this board, the SMT memory chip will actually be on the underside (where all the pins are soldered to the copper board).
Servo Usb Smt Eeprom Schema
Servo Usb Smt Eeprom
Print at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this USB servo controller board with SMT eeprom chip
We're also working on one last final revision of the firmware, to allow the user to place "labels" along the timeline, and to have the servo controller board jump to specific points along the timeline. This will become clearer as screenshots of the software become available....
Friday, 6 May 2011
USB servo board animation playback - edit
One last amendment as the playback routines are written.
All our animations are simply lists of events that happen a specific time after the user has pressed a button (or sent a signal) to start the animation playback.
The PIC keeps a running timer of the time elapsed since playback started, and a list of events and when they need to happen. The list is already sorted into time order (by the host PC before downloading).
The PIC microcontroller simply compares the current time to the time of the next animation in the list. If the current time is greater or equal to the time of the event in the list, it plays out the animation (moves the servo) off the top off the current "stack" of animations, then moves onto the next one.
This approach allows the PIC to catch up with any missed "frames" - in fact this is an important approach, since three things happening at exactly the same time will actually be processed in sequence, one after the other, but very quickly.
Anyway, this leads us to the latest amend:
Timecodes are stored as two-byte values (any number from 0 to 65,535).
At the minute we're storing times as milliseconds from the start. While this is pretty accurate for playback, in reality, we're more likely to want things to move within seconds or half-seconds of each other, not 1/1000th of a second.
If we stick to storing our animation timecodes as milliseconds, the maximum value we can store is 65,535 milliseconds - 65 seconds. The longest animation would be just over a minute long.
By simply storing timecodes as 1/10th seconds (so one second is represented by 10, two seconds by 20 and so on) we can perform animations with timings as low as 1/10th second, but also increase our playback times incredibly.
If the maximum value possible is 65,535 represents 6,535 seconds, this is a massive 108.916 minutes - or 1hr 48min and 55sec of animation!
The software and PIC firmware will be updated shortly with this amendment.
Following the examples given in a previous post, the data written as
servo 500,09,120
servo 500,10,120
servo 2000,09,050
servo 2000,10,200
servo 4000,09,200
servo 5000,10,060
tloop 6000,1000
...is now converted into
0,5,0,9,120 (500 milliseconds = 5 * 1/10th second)
0,5,0,10,120
0,20,0,9,50
0,20,0,10,200
0,40,0,9,200
0,50,0,10,60
0,60,1,0,10
All our animations are simply lists of events that happen a specific time after the user has pressed a button (or sent a signal) to start the animation playback.
The PIC keeps a running timer of the time elapsed since playback started, and a list of events and when they need to happen. The list is already sorted into time order (by the host PC before downloading).
The PIC microcontroller simply compares the current time to the time of the next animation in the list. If the current time is greater or equal to the time of the event in the list, it plays out the animation (moves the servo) off the top off the current "stack" of animations, then moves onto the next one.
This approach allows the PIC to catch up with any missed "frames" - in fact this is an important approach, since three things happening at exactly the same time will actually be processed in sequence, one after the other, but very quickly.
Anyway, this leads us to the latest amend:
Timecodes are stored as two-byte values (any number from 0 to 65,535).
At the minute we're storing times as milliseconds from the start. While this is pretty accurate for playback, in reality, we're more likely to want things to move within seconds or half-seconds of each other, not 1/1000th of a second.
If we stick to storing our animation timecodes as milliseconds, the maximum value we can store is 65,535 milliseconds - 65 seconds. The longest animation would be just over a minute long.
By simply storing timecodes as 1/10th seconds (so one second is represented by 10, two seconds by 20 and so on) we can perform animations with timings as low as 1/10th second, but also increase our playback times incredibly.
If the maximum value possible is 65,535 represents 6,535 seconds, this is a massive 108.916 minutes - or 1hr 48min and 55sec of animation!
The software and PIC firmware will be updated shortly with this amendment.
Following the examples given in a previous post, the data written as
servo 500,09,120
servo 500,10,120
servo 2000,09,050
servo 2000,10,200
servo 4000,09,200
servo 5000,10,060
tloop 6000,1000
...is now converted into
0,5,0,9,120 (500 milliseconds = 5 * 1/10th second)
0,5,0,10,120
0,20,0,9,50
0,20,0,10,200
0,40,0,9,200
0,50,0,10,60
0,60,1,0,10
USB servo board animation playback
After a late night at BuildBrighton last night, we finally got the PIC microcontroller talking to the Flash-eeprom. It turns out that the first SMT-to-DIP board wasn't soldered up properly. So after a few hours debugging some code (that eventually turned out to have been working all along) we fixed the dodgy lines and managed to read and write data to/from the Flash device.
So now we need to consider how animations will be stored in memory.
The first, and immediate, use of the Flash memory was to store data in a sequence of 4-byte chunks.
500,09,120
500,10,120
2000,09,050
2000,10,200
4000,09,200
5000,10,060
We started building an app to allow users to write their animations to the eeprom chip. Then, after a cup of tea and a biscuit, we decided to make a DLL to simplify the whole process, allowing end-users to create their own animation software and integrate it with the servo board. The final solution we came up with (and decided to stick to) was to read a simple text file, made up of the 4-byte chunks, and stream this data over USB to the usb-servo board.
Full details of how the servo board works will be published later (once we've agreed on the communication protocols!) so that other users can contribute their own animation-creation software in future.
After a bit of thought, and trying out a few animations, it became apparent that the eeprom chip has massive amounts of storage which likely to go unused. It also became apparent that most robotic animations are actually repetitions of relatively small animations. For example, walking animations are just cycles of simple, smaller movements (irrespective of the number of legs involved!).
Our final animation decision was to increase the chunk-size to five bytes:
The text file containing these values is updated to an easily-understood format:
servo 500,09,120
servo 500,10,120
servo 2000,09,050
servo 2000,10,200
servo 4000,09,200
servo 5000,10,060
tloop 6000,1000
and these commands are translated into the following byte sequence:
1,244,0,9,120 (500 = highbyte 1, lowbyte 244, third byte=command byte)
1,244,0,10,120
7,208,0,9,50
7,208,0,10,200
15,160,0,9,200
19,136,0,10,60
23,112,1,3,232
The last entry is of particular note.
The command tloop is represented by a 1 in the third byte and in this case means "reset the timer as if it were 1 second after the start of the animation".
As a result, the servo board resets the internal timer, starts at the beginning of the list and reads through the commands, until it hits the appropriate one in the sequence. The result, in this case, is that the last five commands in the list are repeated over and over again.
So now we need to consider how animations will be stored in memory.
The first, and immediate, use of the Flash memory was to store data in a sequence of 4-byte chunks.
- The first and second bytes represent the time in milliseconds to have elapsed.
- The second byte is the servo channel number
- The third byte is the movement value (where 100=1m/s, 200=2m/s etc)
500,09,120
500,10,120
2000,09,050
2000,10,200
4000,09,200
5000,10,060
We started building an app to allow users to write their animations to the eeprom chip. Then, after a cup of tea and a biscuit, we decided to make a DLL to simplify the whole process, allowing end-users to create their own animation software and integrate it with the servo board. The final solution we came up with (and decided to stick to) was to read a simple text file, made up of the 4-byte chunks, and stream this data over USB to the usb-servo board.
Full details of how the servo board works will be published later (once we've agreed on the communication protocols!) so that other users can contribute their own animation-creation software in future.
After a bit of thought, and trying out a few animations, it became apparent that the eeprom chip has massive amounts of storage which likely to go unused. It also became apparent that most robotic animations are actually repetitions of relatively small animations. For example, walking animations are just cycles of simple, smaller movements (irrespective of the number of legs involved!).
Our final animation decision was to increase the chunk-size to five bytes:
- First and second bytes are time in milliseconds
- Third byte is a command byte which changes how the fourth and fifth bytes are interpreted
- If command byte is "move servo", the fourth byte is the servo number and the fifth byte the movement value
- If the command byte is "jump to timecode", the internal servo timer is updated to a (two-byte) value represented by bytes four and five
The text file containing these values is updated to an easily-understood format:
servo 500,09,120
servo 500,10,120
servo 2000,09,050
servo 2000,10,200
servo 4000,09,200
servo 5000,10,060
tloop 6000,1000
and these commands are translated into the following byte sequence:
1,244,0,9,120 (500 = highbyte 1, lowbyte 244, third byte=command byte)
1,244,0,10,120
7,208,0,9,50
7,208,0,10,200
15,160,0,9,200
19,136,0,10,60
23,112,1,3,232
The last entry is of particular note.
The command tloop is represented by a 1 in the third byte and in this case means "reset the timer as if it were 1 second after the start of the animation".
As a result, the servo board resets the internal timer, starts at the beginning of the list and reads through the commands, until it hits the appropriate one in the sequence. The result, in this case, is that the last five commands in the list are repeated over and over again.
Wednesday, 4 May 2011
USB servo board first PCB prototype
After a few weeks away, it was nice to get back to Nerd Towers and start etching stuff and messing about with copper boards and solder again.
After lots of development and testing on breadboards, it's finally time to try the usb servo board out for real - here's the first set of etched PCBs for the controller.
We've tried to keep the board as compact as possible, but still allow room for an 8-pin DIP (or one of our spanky new SMT-to-DIP boards) as well as all 20 servo channels.
Phew! That's a lot of holes to drill with a hand-operated push-drill!
How the controller board looks, from the "business side".
After lots of development and testing on breadboards, it's finally time to try the usb servo board out for real - here's the first set of etched PCBs for the controller.
We've tried to keep the board as compact as possible, but still allow room for an 8-pin DIP (or one of our spanky new SMT-to-DIP boards) as well as all 20 servo channels.
Phew! That's a lot of holes to drill with a hand-operated push-drill!
How the controller board looks, from the "business side".
Tuesday, 3 May 2011
USB servo board eeprom
The little eeprom chips arrived today. I forgot that they were SMT when I designed the USB servo board for PCB manufacture, so the board has an 8-pin DIP socket, and the eeprom chip is SMT. Bugger!
To get around this, I created a simple SMT-to-DIP converter for 8-pin chips:
The SMT chip goes to the left of the 8-pin DIP connectors. I'll put two rows of 4 x 0.1" header pins where the DIP chip would normally go, effectively turning the SMT chip into an 8-pin DIP.
SMT_to_DIP_8PINPrint at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this SMT-to-DIP converter
If you're making one of these yourself, note that the PCB design has been mirrored (normally we don't bother mirroring designs, as they are reversed on the bottom of any through-hole mounted board anyway). With this design, however, the copper part of the board will be face up, with the SMT chip soldered onto the copper side (rather than the through-hole components being mounted on the top and soldered underneath).
Because of this, the design is mirrored (but when you use press-n-peel/toner transfer to get the image onto the copper board, it'll end up the right way around).
Dont forget to mount the pin headers on the bottom (non-copper) side of the board, with the shorter legs soldered to the top (copper-side) of the board.
The usb servo board was designed to accommodate either a regular 8-pin DIP or our modified SMT-to-DIP board
To get around this, I created a simple SMT-to-DIP converter for 8-pin chips:
The SMT chip goes to the left of the 8-pin DIP connectors. I'll put two rows of 4 x 0.1" header pins where the DIP chip would normally go, effectively turning the SMT chip into an 8-pin DIP.
SMT_to_DIP_8PINPrint at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this SMT-to-DIP converter
If you're making one of these yourself, note that the PCB design has been mirrored (normally we don't bother mirroring designs, as they are reversed on the bottom of any through-hole mounted board anyway). With this design, however, the copper part of the board will be face up, with the SMT chip soldered onto the copper side (rather than the through-hole components being mounted on the top and soldered underneath).
Because of this, the design is mirrored (but when you use press-n-peel/toner transfer to get the image onto the copper board, it'll end up the right way around).
Dont forget to mount the pin headers on the bottom (non-copper) side of the board, with the shorter legs soldered to the top (copper-side) of the board.
The usb servo board was designed to accommodate either a regular 8-pin DIP or our modified SMT-to-DIP board
Sunday, 1 May 2011
PIC programmer with ZIF socket
Just a quick shared post - I work a lot with the 18F2455, 18F4550 and 16F628A series of PIC microcontrollers (if you really want to know why, I'll post reasons later!). I usually have a dedicated breadboard made up with the programming pins mapped to a 5-pin header, that works with my PICKit2 Clone iCP01 programmer (from piccircuit.com).
I recently ran out of breadboards and had to dismantle my programming board and immediately regretted it! I can never remember which wires go where, so I made up a ZIF-based PIC programmer. This board has been tested with and works with the chip mentioned above, but will probably work with a whole load more as lots of PICs share the same pinouts for programming data, voltage and clock lines:
Zif Pic Programmer
Print at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this PIC programmer
Note the yellow bars at the bottom - these are wires connecting two pads/vias.
Below the ZIF socket is a 5-pin header to connect the PIC programmer to.
At the top of the socket is a three-pin header, onto which you should place a jumper, to connect either of the outer-most pins to the central pin. This is how to change between 18F and 16F microchips. (the 18F position is marked on the board).
To program a PIC microcontroller, place it into the ZIF socket ensuring that pin1 is always in the top-left hand corner.
I recently ran out of breadboards and had to dismantle my programming board and immediately regretted it! I can never remember which wires go where, so I made up a ZIF-based PIC programmer. This board has been tested with and works with the chip mentioned above, but will probably work with a whole load more as lots of PICs share the same pinouts for programming data, voltage and clock lines:
Zif Pic Programmer
Print at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this PIC programmer
Note the yellow bars at the bottom - these are wires connecting two pads/vias.
Below the ZIF socket is a 5-pin header to connect the PIC programmer to.
At the top of the socket is a three-pin header, onto which you should place a jumper, to connect either of the outer-most pins to the central pin. This is how to change between 18F and 16F microchips. (the 18F position is marked on the board).
To program a PIC microcontroller, place it into the ZIF socket ensuring that pin1 is always in the top-left hand corner.
Servo board PCB layout update
Just a quick update on the 20-channel USB servo board with eeprom playback:
this new PCB layout includes the eeprom chip (Atmel's AT45DB041D). Another slight change to the earlier design is that the USB 5v/power supply now goes to the 5V output pin of the regulator rather than the input. This allows the user to connect 4xAA (or 4xAAA) batteries to create a 6V supply or even use a single PP3 (9V) battery to run the device, but safely connect the USB cable at the same time. The original design required the user to disconnect the batteries before connecting the USB cable to download more data to the device. With this new layout, the batteries can safely remain connected and the board still be connected to a PC to download more data.
(a future board with 3.7V rechargeable lipo is in the planning stages but is still some way off!)
Note in this silkscreen and current version of firmware, the servo pin numbering is a little peculiar. This will be addressed in the final version of the firmware!
Subscribe to:
Posts (Atom)