I recently got my first Sphero and I have to admit as with any new product I was skeptical in the beginning. However just after few minutes of playing with it I had to admit – boy, this stuff really works and is  lots of fun !  Sphero is a simple ball (well, not so simple on the inside) robot that you can control via your tablet or phone via bluetooth (major devices supported). There are many available apps on the market besides the stock control app. It also has a nice SDK that allows to use Sphero for your own projects. Because it contains an IMU sensor inside, Sphero can be used as controller for a game or application.

Only few years ago Shpero was just a crazy idea. Now Ortobotix is a company with dozens of employees. As it happens with many new projects Sphero was not perfect from the start. At their lowest point the founders (Ian Bernstein and Adam Wilson) admit they were so depressed that they were contemplating to pull out of CES 2011 at the last moment. Then something magical happened and the team was able to sort out all problems making it a hit at 2011th CES ! Morale of the story – never give up!

To find out more about the Sphero’s success story read up here:  http://www.gosphero.com/tag/startup/ .  Sphero is available on Amazon and other retailers. Get yourself one, I guarantee it – it’s not just a toy but also a great research tool if you’re into electronics or robotics !

//s//

In this article I will review the Tenma 72-7740 Multimiter which aims to provide most of the functionality of an advanced multimeter , but at a lower price. So let’s see how well it does it.

First let’s have a glance at the specs of this device:

These specs are not the best you can get , but very reasonable for the price tag you pay (around $72 at element14). For instance a Fluke 87-V could give you a DC Accuracy of 0.05%+1 but at a much higher price tag.

Next let’s go through some features of this millimeter and examine them in more detail.

Box Contents

The box contents are: the multimeter, a set of probes (sharp ends and decent quality) , a temperature probe, the manual and the battery.

Basic Operation, Look and Feel

The multimeter seems well build, no flimsy parts , the dial does not have well defined detents so it is actually possible to move it to a position between two points. The stand is solid an you can operate the dial and buttons with one hand while the multimeter is resting on stand.

Autoranging  Feature

I tested the auto-ranging speed of this multimeter in Voltage mode and it seems to lock within 2 seconds – pretty impressive and much faster then I expected. The lack of a bargraph that you would find on a higher end multimeter is however a minus and you might miss some fluctuations that cannot be represented by the digit display. Other measurements such as Resistance and Capacitance seem to be slower to lock but still fairly fast.

Voltage Measurements

Perhaps 90% of measurements you do with a multimeter are voltage measurements. And this multimeter does it well and within specs – no complains here. If you don’t like the autoranging feature you can switch to a fixed range by pressing the “Range” button.

Resistance Measurements

Seems to be within specs, however if you touch the leads of the probes the multimeter will start with a value that seems to be the true resistance of the probes (~0.4Ohm) but then will slowly decrease to (0 Ohm). This seems to be a very odd behavior, perhaps some “clever” way to compensate for the resistance of the probes,  but I would prefer it showing the true value of the leads resistance, rather then trying to compensate for it. If I would want to exclude the resistance of the leads , I could press the REL button while touching the leads, thus nulling out the leads’ resistance.

Current Measurements

In current mode this multimeter has a considerable internal resistance, this is particularly noticeable in the low-current ranges. So be aware if you measure small currents this multimeter might actually affect your current by as much as 10% based on my tests.

Temperature Measurements

Seems to be within specs, however while the rating of the multimeter is “up to 1000C”, the black insulation on the supplied probe will start to melt at about 300C – it seems to be a regular shrink wrap tube.  So if you’re planning to measure anything near 1000C you will need a different probe.

Capacitance Measurements

Seems to work well. I recommend pressing the REL button before measurement to compensate for the capacitance of the leads. One annoying fact about this multimeter but also others is the lack of the pico-farad range.

Frequency / Duty Cycle Measurement

Seems to work as advertised – a very useful feature if you don’t have an oscilloscope available for basic frequency/duty cycle measurement , however when I fed a certain round number frequency like  1000Hz from my frequency generator , it always seems to show one least significant digit lower like 999.9Hz. Since these are digital measurements I don’t think it is so hard to be spot on … especially on lower frequencies.

Backlight

The backlight is non-uniform, the diffuser seems to fail doing its job. The green color is very “retro”. However honestly,  if I ever find myself using a multimeter in the dark I wouldn’t complain much as long as I can see the numbers .

Teardown

The multimeter is held together with two screws that are hidden behind the rubber feet. However to completely remove the cover you need to reach two plastic latches with a flat screwdriver on the other side. There’s a basic shield, that is basically a piece of foil laminated in plastic – not sure how effective it is especially because the shielding is only on one side. The screws are self-tapping type , no metal inserts. The buzzer is mounted on the cover and two springs on the PCB are used to make contact with the buzzer. Input protection has two fuses – you need to remove the cover to replace them, it would be better if they were accessible from the battery compartment. There are no hanging wires – which is good , battery connectors are mounted on the PCB. The bottom part of the PCB has some calibration pots.

By removing more screws and flipping over the PCB we can reveal more components:

The main processor is a CS7721CN (by SEMICO). I couldn’t find the datasheet for this chip however an interested reader could fish it out on Google with some more research. The other 8-pin chip is marked as 220Z3 , again couldn’t find any info on it but I suspect it is either an ADC or an op-amp chip.

The assembly quality seems to be decent – mostly SMD parts. As you can see the input protection is very basic, no serious PCB isolation, or blast protection walls on the case. Although the multimeter is rated CAT IV 600V / CAT III 1000V, some might not be conmfortable using it at such high voltages given the very basic input protection.

Conclusion

The Tenma 72-7740 is an affordable multimeter that has some advanced functions that can be found on higher end multimeters. It is a good compromise for those constrained by budget. It certainly does its job in the voltage measurements department, but some of the add-on features need some more refinement. Still a good value for the abundance of features that you get for the price.

Thanks:

Many thanks to element14 for providing this sample for review. For the full line of digital multimeters that element14 has to offer please visit: http://www.newark.com/digital-multimeter.

//s//

I’ve been experimenting for quite a while with different configurations of Multi-Copters and RC Helicopters, basically looking for a stable robotic platform that can be used for my machine vision or other sensor-enabled flying robotic projects. RC helicopters have been around for quite a while, however (with the exception of some 3-Channel helicopters) they are not easy to fly, not very stable and not too precise in maneuverability – in other words not exactly good match for a flying robot. Then came the quadcopters and everyone loved them, talked about them , and eventually wanted to or actually built one.  I built a few – and what I learned is that  they have a great lifting power, great maneuverability (basically equivalent to a 4ch or 6ch heli), however   they rely entirely and heavily on relatively expensive IMU sensors  to achieve this stability.  I a QuadCopter you basically have four “monster” motors on each beam than must be synchronized precisely. Because you’re controlling so much power with your IMU sensors – any small deviation or lack of callibration and your platform is no longer stable. That’s why the sensors are crucial in a quadcopter  – without them the quadcopter will not fly at all ! 

After many trial designs – my conclusion was that a suitable flying robotic platform must not rely too much (or at all) on its sensors to be stable while hovering. It must be mechanically symmetric, preferably with it’s center of mass in the center.  At the same time it must have the maneuverability  capabilities of a quadcopter –  and namely I wanted it to fly sideways, forward & back  and rotate around its axis. Although the solution I came up with might seem to some (including myself) a little strange  and out of the ordinary –  as turned out it flew surprisingly well , was very stable and maneuverable, and best of all – had a very low price tag due to the fact that it was easy to built from the off-the-shelf toy helicopter replacement parts.

Without further adieu – below is the picture of the machine that I called “QuadHybrid”:

My very first QuadHybrid prototype.

Below you can see some flying test video:

So What Exactly is a QuadHybrid ?

Let’s have a closer look at QuadHybrid’s pictures. A simple way to look at it is:  a co-axial helicopter on top of a quadcopter – it’s actually as simple as that.

In total QuadHybrid has 6 motors and 6 propellers (2 large one center from the helicopter + 4 small on each arm from the quadcopter).

The two large center propellers in the center consist of 2 heli-type blades – they provide all the lifting power needed. They spin in opposite directions to compensate for the yaw rotation introduced by any rotating propeller and are stabilized by an optional vertically mounted MEMS gyroscope  (the only sensor used in this design). The slight difference in speed of the top and bottom blades is used to control the desired yaw rotation.  Thus the center motors provide the throttle and yaw control of the QuadHybrid – in other words ability to fly up/down or rotate about its center vertical axis.

The four small rotors on the four arms are actually small tail motors from a 3ch helicopter, they provide the remaining maneuverability  functions – pitch/roll or – or in other words the ability to fly  forward & backwards or shift sideways  (right / left) . 

The resemblance to a quadcopter and a helicopter can be seen in the picture below where they are put side by side.

How Does a QuadHybrid Work and How to Build One

QuadHybrid has all the maneuverability of a 4 channel helicopter or a quadcopter (throttle, yaw, pitch and roll). A 3 channel helicopter as we know it – only has 3 controls (throttle, yaw and pitch). The problem with a co-axial 4CH helicopter for instance is that it relies on a swash plate and servos to achieve the pitch/roll control. Basically it is a servo mechanism for tilting the axis of rotation of the bottom rotor – it is not easy to fine tune and it needs frequent maintenance. A 3CH toy helicopters on the other hand relies on a tail rotor to achieve the pitch control – and this is one of the ideas I used for QuadHybrid – basically I multiplied the tail boom and rotor on a 3CH helicopter by four.

This is how a typical 4CH helicopter is build. Please note that the bottom blade can be tilted by using 2 servos that tilt the swashplate. In the QuadHybrid design we are going to eliminate the servos and the swashplate and replace them with 4 small motors mounted on 4 arms (beams), just like on a quadcopter.

I built my QuadHybrid, from spare RC or “toy” heli  parts. They are widely available and thanks to the fact that manufactures copy each other in some cases bluntly, these parts are compatible in many cases  so I was able to mix-and-match. I took the electronics from a E-Sky Lama V3 helicopter  – that is a 4 channel heli so it has a swashplate and 2 servos to control the pitch and roll. Because I didn’t wanted the swashplate (the roll/pitch on QuadHybrid is controlled by the 4 small quadcopter style rotors), I used the frame and blades from another toy helicompter  – Syma S001 and I was able to fit the Esky motors into that frame which are bigger and more powerful than the S001 stock motors. 

To clarify the design let’s look at the guts of the E-Sky Lama V3 helicopter . I actually used all electronics in this 4CH helicopter, except the servos (as will become clearer in the next diagram):

The main idea of the QuadHybrid design is: to achieve a better Pitch/Roll  control I replaced the servos with a custom control board called “QuadHybrid Controller V1”. This board basically takes the servo RC signals (Pitch and Yaw) as inputs and controls the 4 arm motors using a set of 4 transistors. This allows QuadHybrid to fly just like a quadcopter in “+”  or “X”  configurations (for explanation of “+” or “X”  flying configurations  see for example http://technicaladventure.blogspot.com/2012/09/quadcopter-stabilization-control-system.html).

On the mechanical part – the swashplate on the bottom blade was replaced with a fixed blade mount from a 3CH helicopter. This made the bottom blade of the 4CH fixed. Normally on a 4CH heli it is being tilted by servos that are connected to the swashplate using 2 links.

This is a swashplate assembly on a 4Ch helicopter it is the black disk under the blades mount. It is connected to the blade mount with two links. Two servos that are controlled by the RC receiver are able to tilt the swashplate and thus alter the axis of rotation of the bottom blade. This is how the roll and pitch is controlled in a 4 channel helicopter. It is far from perfect and requires frequent tune-ups.

A gyro-stabilized co-axial 3 channel toy helicopter is fairly stable, as opposed to a 4CH helicopter- it uses the tail rotor to control the pitch (flying forward or backward). Note the bottom blade is fixed , just like on the QuadHybrid.

QuadHybrid Controller Board and Software

Below is the schematic of the QuadHybrid V1 controller (the blue board on the diagram above that controls the 4 motors). This is the only custom component that is not available from RC toys parts.

At the heart of the QuadHybrid V1 controller board is a PIC16F1825 microcontroller – it’s main task is to capture the servo signals received on ports RA5(ROLL) and RA4(PITCH) and convert them  to 4 PWM signals that control the 4 rotors mounted on arms. The motors are driven using 4 NPN transistors – these can be any NPN transistors as long as they have a current rating of at least 1A (or the maximum current of your arm-mounted motors) and a low Collector-Emitter resistance (< 0.3Ohm or so).  MOSFET could be used instead of NPN transistors, with slight schematic change – however I found hard to source them in an easy to solder and light-weight TO-92 package so I used NPNs instead.

QuadHybrid V1 controller board operates by default in “+” configuration. If you want to operate it in “X” configuration then connect the X_CONF jumper – this will give you better control with smaller motors , since for example flying forward will activate two motors at once (3 & 2). The only thing to keep in mind when flying in “X” configuration is that the “Front” is a imaginary line between arm #0 and #1 .

QuadHybrid V1 PCB was created as a all through-hole design so that anyone can assemble it and covert a toy RC helicopter into a QuadHybrid:

For anyone wishing to spend time on creating their own QuadHybrid V1 controller board – source code and Eagle files are available on the SVN repository, otherwise easy to solder kits will be available in my Store.

If you would like just to peak over the source code here is a direct link:

https://code.google.com/p/quadhybrid-v1/source/browse/trunk/%20quadhybrid-v1/src/main.c

As you can see it is a fairly simple project a(for anyone familiar with C  and microcontrollers) and a good placeholder for further improvements and add-ons.

Mechanical Construction

On top of QuadHybrid prototype is basically a stripped down frame of a 3ch helicopter and namely it comes from Syma S001:

Under the frame are 2 aluminum tubing pieces that form the 4 arms. At the end of each arm I attached a tail rotor from the same Syma S001 helicopter model:

Then, to house all the electronics and battery I just sandwiched two perforated  boards with nylon spacers (Tip: most bolts,nuts and spacers used in this design are nylon-made to lower the weight) :

For landing gear I just used a RC helicopter training kit that consist of a round bracket attached to the bottom deck, four carbon fiber rods and four (orange) ping-pong balls:

Please note that: although all the mechanical parts are from a 3Channel helicopter (Syma S001), you will need electronics from a 4Ch helicopter! The main reason for using a 3CH helicopter for mechanical part is because the bottom blade bracket was already fixed (3Ch helicopters have no swashplate):

It might be more economical to get a 4Ch helicopter (mainly for its electronics that support pitch & roll not just pitch as a 3Ch helicopter) and then just remove the servos and the swashplate and then fix the bottom blade bracket using screws and/or glue.  As I did in the photo below (E-Sky Big Lama parts shown):

As an alternative to fixing the bottom blade bracket, you can also get a fixed blade bracket from a 3CH helicopter – it must be same inner diameter as the one from your 4CH helicopter. The diameter of the outer drive shafts are typically 4mm ( and 5mm , 6mm and even 8mm for larger helicopters).

Esky helicopters are best to use in terms of electronics because they have standard signal RC protocols in their transmitter / receiver boards that you can tap-into to get the Pitch/Roll signals needed for the QuadHybrid controller board. Syma helicopters integrated boards are harder to hack into – however some people have managed to hack into them and reverse engineer the signals.

Conclusion: What are The Advantages and Disadvantages of the QuadHybrid Design over a traditional QuadCopter or a RC Helicopter

While building the QuadHybrid  I selected the best features of a quadcopter and a helicopter and put them together, this resulted in a machine that took the best of the two worlds:

- QuadHybrid is mechanically symmetrical and stable. As opposed to a QuadCopter it does not rely on sensor to achieve this, the main hovering stability comes from the co-axial design and the centrifugal momentum of the fly-bar (the black bar on top of the blades with two weights on each side) – this is basically the same principle at work as in a mechanical gyroscope.

- QuadHybrid only requires two lifting “powerful” motors, the other 4 small motors are used for steering and are not crucial for device stability. There’s no need for motors to be brushless, and no need for brushless ESC controllers, they can be cheap RC-type brushed motors that can be driven by MOSFETs or transistors, there’s no need to reverse rotation of any motors, however it will be a feature in V2 of the controller board. Also there’s no need for CW and CCW propellers for the motors mounted on arms. All this vastly reduces the complexity and cost of the design.

- Partial or complete failure of any motor will still keep device in the air and give the operator/program a good chance to land it safely. In the worst case scenario – if a driving motor fails , the device will loose lifting power and will spin in the air, but will still at least stay on it’s vertical axis. In case of a quadcopter – failure of any motor is fatal – it will basically flip the quadcopter, or make it fly sideways with great chance to hit something. This is of course debatable, but in any case statistics tells us that the probability of one of the 4 motors to fail is twice of that of one of the two motors to fail (and economics tells us it’s also cheaper to get two motors than four).  Failure of any arm-mounted motor on a QuadHybrid is not critical, the device will still hover in the air and can be landed safely.

- Safety (we all know it should be first). A QuadCopter without  shielded high-powered rotors is a pretty dangerous device,  its propellers are spinning with an incredible force and are ready to cut into anything that falls in their way – they can do a lot of damage to humans, pets or property. QuadHybrid only has four low-powered motors on its arms since they are only used for steering, not lifting. The center driving propellers on a QuadHybrid are shielded away by its arms, also they have a folding design, so if they hit something it will somewhat make the impact less destructive.  Overall QuadHybrid is more suitable for indoor applications such as schools , universities or research facilities. Make no mistake though – QuadHybrid  can  still do damage and safety procedures must he observed at all times !

Few advantages of Quadcopters over QuadHybrid worth mentioning may be:

- because they have four powerful motors, Quadcopters  have greater lifting power. However this is more of a “brute-force” advantage – one could always get more powerful motors and battery for a QuadHybrid to achieve the desired lift power.

- Quadcopters can do some serious aerobatics (if you’re a good pilot)  including fly upside down or do 3D stunts. This is not really an advantage for some people, specifically when you are actually trying to build a nice and stable robotic platform – on the contrary it’s more something you try to avoid. 

In conclusion: although this first version of QuadHybrid was not designed to do 3D stunts or fly with high speeds –  it has a great hovering and maneuvering stability. I think it will find most of its use as a highly stable and controllable indoor flying robotic platform. However similar spin-offs could be expected to be developed for flying outdoors and/or with higher speeds.

//starlino//

This article is dedicated to all my math and science teachers !

Everything worked well until I suddenly discovered that while sending data over the CDC port from the computer to the device, the device would *sometimes* receive garbage data instead of what I sent. This wouldn’t be so discouraging if the data received would be the same, or at least this would happen always not *sometimes*.  The bug was caught in the act on the screenshot below, the arrows show the data I actually sent ‘stop’ followed by LF (0xA) char and the character codes (in decimal) actually received. This is garbage because 92,162,62,180 are note the ASCII chars for ‘stop’.  Please note that this will only occur *sometimes*, however I could almost consistently repeat it after several retries of sending a command to the device.

The tracking of this bug turned out to be so adventurous and involved that I decided to write a tutorial about it. It involved some tools that I didn’t use often before, but now they proved indispensable in locating this furry and fuzzy code pest . As you’ll see at the end of the article the bug was pretty obvious at least for me (I already made this mistake many times , but forgot about it), however it might be really useful for someone just starting working with microcontrollers,  C and/or  interrupts. It also provides an opportunity to review some tools I used in the process.

So where do we go from here ? Same data is send over a USB CDC Serial Emulator Port  but sometimes the microcontroller receives garbage instead of the original data. A general rule of thumb is – start at the source and go up. Let’s identify the possible problems:

#1  – the computer terminal, or USB driver has gone crazy, it is sending something else instead of what was typed
#2  – there’s a hardware noise problem on the USB lines
#3  – there’s a bug in the Microchip USB Stack
#4  – there’s a bug in my code

Ok so we start with #1 , how do we see that the terminal is actually sending the correct data ? We need a way to see the actual packets send via USB. For someone who had a hardware USB protocol analyzer it would be a good time to power it up. Unfortunately these devices are really costly (let me know in the comments if I am wrong and you know any affordable solutions), and luckily for us there are decent software USB protocol analyzers that we can use instead. The tool that I used and that I highly recommend is USBTrace. It is not free , but still affordable and a great value that will pay off if you value your debug time. The reason I like USBTrace is that is so easy to use. You know a good product because after you start it you don’t have to read a manual to perform a basic function. Once I started USBTrace on the left side I was able to find a list of all USB devices, it was easy to track down my virtual CDC Serial port because in the bottom panel I could see the device descriptors. Please note that I also had connected a FTDI serial converter that I could have confused with my device. However my device had some strings in the descriptor that I recognized from my firmware such as “CDC RS-23 Emulation Demo”. Once I checked my device I was ready to click the green Run buttons. And the packets started pouring in …

Wow , that was an overwhelming number of packets! My device was in streaming mode and sending a lot of data to the EndPoint #82. I only needed data that I send to device so how do I do that ? Again USBTrace was great and very intuitive , clicked on the funnel icon (Filter) and I got following dialog:

Here I was able to set the Direction of the packet – OUT. Please note that for USB packets , by convention , the direction is as looking from host – so OUT from computer to device. I also set the CDC OUT endpoint as specified in my firmware #2, finally I set the request type to BULK_OR_INTRRUPT_TRANSFER.

Now all I had to do is to send the ‘stop’ command couple of times until the bug happened again, that was easy to spot since the streaming would not stop once garbage was received. And once it happened, I checked the contents of the last packet in USBTrace, and what do I see:

The data is completely correct, so my first guess is ruled out. Let the bug hunt continue. Moving on to #2.

#2 – there’s a hardware noise problem on the USB lines

I had a look at the cables, I had a look at the device, I knew the hardware setup worked perfectly before. If I had a hardware USB analyzer I would hook it up. But I didn’t so I took a leap of faith and I skipped #2. This wasn’t by the books. However it was all I could do in reasonable time. So moving on to #3.

#3 – there’s a bug in the Microchip USB stack

Once you download the USB stack, and integrate into your project , it becomes part of your project. So tracking Microchip’s bug was no different than tracking my own code bug. So I moved to #4 and handled #3 in the same step.

#4 – there’s a bug in my code

Ok so here we are in the MPLAB IDE 8.83. My PIC device is capable of up to 4 Hardware breakpoints. This means that the MCU can halt on specific memory locations, it also can halt when a specific memory location is written or read.  By scanning through the USB Stack code, I found that it stores the incoming  USB CDC data in the cdc_data_rx[] buffer . From the .map file I was able to determine that this buffer address is starting at 0xE08. The MAP file is basically a file the compiler creates and where you can find all your variables and code and at what address they are stored, look for it in the same folder where you output .hex file is.

Setting a memory breakpoint is accomplished by clicking on the “ADV.B”  blue button in the debugger toolbar, this brings up a dialog like this:

I just punched in the address of my buffer, selected access type as Write. Now when the first byte in the incoming CDC buffer is written with good / or garbage data the code should break and point me to where the data writing happened. Again I stared sending data, and I had to click on the green debug run icon couple of times, to skip through good cases until the bad garbage write happened. The MPLAB debugger didn’t stop every time the bad case happened , I am not sure if this is a limitation of the debugger or something caused by my code bug, but finally it stopped at a place where I defined some code that was executed inside an interrupt.

This is the code for receiving the data over the other port the TTL USART, not the one having problems CDC Serial !  It basically fills out a buffer called usart_rx_buf, but this not the cdc_data_rx buffer so how could they interfere?  Eureka ! Buffer overflow – the index used to access the buffer byte  uasart_rx_pos was going crazy out of bounds. Indeed I looked at how usart_rx_pos was declared:

The only other place where this variable was used was in this non-interrupt code:

Now this is a big problem, let’s look at the last statement

usart_rx_pos = 0

If we look at the disable of this instruction, on a PIC 8 bit controller we can see that it takes actually 2 instruction to complete it:

This is because this is a 2 bytes variable . Now think what would happen if the interrupt happens between these two instructions. The interrupt mentioned above modifies the variable. So while the main code thinks it has “0” in usart_rx_pos, in fact it only sets to 0 the second part of the variable the first one could have been modified by an interrupt! Thus the unpredictable behavior … usart_rx_pos becomes a random variable which causes the buffer overflow. Data is written at random locations in program memory . Scarrrrrry !

So how did this happened , even if  “I’ve been there done that” many times ? Well the timer interrupt code was not inside an interrupt initially , I later migrated it to an interrupt and forgot to do a sanity check of variable types. In fact I don’t need an int for usart_rx_pos (the buffer is smaller than 255). So I changed it’s declaration  to:

Now that writing of one byte is done in single instruction there’s no risk of corruption by an interrupt updating same variable. However as we’ll see below this is only part of the solution. Below is the disassembly code of writing 0 to a one byte variable:

Please note that I also added an important ‘volatile’ specification in front of all variables modified by the interrupt code.  Actually the lack of ‘volatile’ was my second guess why the bug happened. Without ‘volatile’ compiler might think that there’s no other place where the variable can change besides the spot it compiles. So it might optimize the code in weird ways. Here is an example, if a variable is not volatile the compiler could theoretically update this code

x =  1;
y = 0;
x = 1;

to simply

x = 1;
y = 0;

It removes the second assignment of x since it considers it redundant, while in fact if you have an interrupt executing let’s say before y=0 , and modifying x=0 thus in this case the  x=1 at the end is necessary ! So ‘volatile’ basically tells the compiler that a variable can change suddenly ‘out of the blue’ and it should take care while optimizing the code and not to remove any assignments even if they look redundant.

I’ll now present my final solution to ensure the interrupt code does not modify usart_rx_pos and usart_rx_buf  while we’re processing it in non-interrupt code.  The solution is to prevent the interrupt from happening during that time. No worries, if interrupt has to happen while it was disabled by us -  there ‘s usually  a flag set and the interrupt will happen eventually once we’re re-enabling it. Because the processing in session_new_char() might take a while (and you don’t want to disable USART receiving interrupts for a long time) my strategy was to declare two SAFE non-volatile variables and copy data over quickly then re-enable the interrupt. Please note that this code would work fine even if usart_rx_pos was an int (dual instruction assignment) :

Please note that I didn’t have to disable all interrupts, it was enough to disable only the interrupts that would cause our variable to be modified (the USART Receive interrupt). It’s enabled  or disabled by the RC1IE flag in PIE1 register.

After testing this new code, the problem was gone. So now I am thinking “everything is for the best” , I spent some time tracing a bug, but I learned along the way and sure thing  I wrote this tutorial so I never again forget that interrupts can modify variables when you don’t expect to !

Bottom line:

A.  Declare variables modified in interrupts as  ‘volatile’ to stop compiler doing nasty things to them
B.  Disable the interrupts that can modify those variables, while working with these variables in a non-interrupt code (both reading and writing), this will create a so called ‘atomic’ code, called so because it cannot be split by an interrupt.
C.  Keep ‘the atomic’ code short – the interrupts can wait , but not for too long in some cases.  For example the hardware USART buffer on my device only has 2 bytes – so it would get filled and lost soon if the processing done in the interrupt   would be halted for too long.
D. Have fun. Life is beautiful even when debugging

/starlino/

I was looking for a way to make the adjustment for my power supply more precise and easier to dial let’s say to a voltage like 3.3 , but without a built-in fine tune potentiometer this was difficult so I found one of those foam rings that are always on top of a CD box, and it fit perfectly over the dial making it bigger and now easier to dial any voltage. This works based on the “gears” principle  – with the larger “gear” attached , finger has to travel a longer distance to make same change, thus easier to dial anything in between that was before harder.

Plain and simple, but just thought to share the non-warranty voiding trick – acceptable choice if you can’t really open up the power supply and add a new potentiometer in series with the main one.  I am also glad I finally found a use for those CD foam rings If you’re curious what power supply it is on the picture, it is a Tenma budget 10A linear power supply works well except the above mentioned lack of fine-tune dial.

I finally got a minute to play with the MSP430 LaunchPad Kit I received, well almost for free from TI and immediately got some feedback to share with the development and marketing team.

First overall I think Launchpad is a great product and I am looking forward to seeing it improve, secondly my understanding is that its targeted market is starting engineers , hobbyist and alike … and I am speaking from that perspective.

I know you might hate me for this and maybe this is a banned word in your company but you should really look at Arduino and try to understand why it became so popular, in a nutshell let me break it down:

- the secret is in details, you might have a better product at a better price but if you can’t present it correctly it will not catch up with developers
- simplicity , simplicity , simplicity, too much information is as bad as no information, getting started manual DOES NOT have to be 182 pages long, half of which are telling about the entire TI lineup and various clock setup , get straight to the point show us the fun part !
- people don’t want so many options, so you must make choices for them , for example – choose a fixed clock mode (crystal or internal clock) and make it standard, let advanced users hack it if necessary, this will also make Launchpad programs more portable if you choose and “official” operating clock speed.
- make a free compiler and IDE : it makes no sense to have a paid compiler and charge a developer “pennies” compared to what that developer can bring you in hardware sales if he uses your chips , instead of spending money on giveaways and free lunches at trade shows , etc, just give the developers a free unlimited IDE and compiler, best promotion you can make and best boost in hardware sales for the future ! It is no coincidence Arduino was based on AVR the only major MCU manufacture to have multi-platform free compilers and IDE (both Microchips and TI’s free editions are limited and crippled).
- give free and no “string attached” MCU samples as Microchip has, same reason as above , you can’t cook dinner with MCUs if someone is ordering them they are an engineer and they might make a product that will use millions of your chips in the future, if you don’t make samples easy and fast , he might choose Microchip because today he is a student and he is broke, call it fate or whatever – unfair but fair ..
- in coding hide all the ugly details like the clock setup , in worst case scenario make a “launchpad” header file to contain all the technical stuff, if you make the “blinking led” program a one or two line program than you know you’re on the right way !
- make changing pin direction (output / input) prettier and more straightforward and avoid the | (OR) bit assignments, in worst case you can use some macros (as I explain here http://www.starlino.com/port_macro.html) , this style of assignments is confusing for beginners

Well that’s it for now, i might add more ideas … so check back or contact me directly if you’d like more feedback.

Microchip started marketing an Arduino clone called chipKit. Is this a correct decision to clone an open source platform as opposed to Texas Instrument's decision to create it's own platform LaunchPad ?

By the way the TI's platform is really cheap, I would say cheaper than components and PCB + shipping. Obviously TI wants more people to use it, however what it is lacking is the relaxed open-source crowd around it.

Is Arduino really something to follow ? What do you think ?

This article is a continuation of my IMU Guide, covering additional orientation kinematics topics. I will go through some theory first and then I will present a practical example with code build around an Arduino and a 6DOF IMU sensor (acc_gyro_6dof). The scope of this experiment is to create an algorithm for fusing gyroscope and accelerometer data in order to create an estimation of the device orientation in space. Such an algorithm was already presented in part 3 of my “IMU Guide” and a practical Arduino experiment with code was presented in the “Using a 5DOF IMU” article and was nicknamed “Simplified Kalman Filter”, providing a simple alternative to the well known Kalman Filter algorithm. In this article we’ll use another approach utilizing the DCM (Direction Cosine Matrix). For the reader that is unfamiliar with MEMS sensors it is recommended to read Part 1 and 2 of the IMU Guide article. Also for following the experiments presented in this text it is recommended to acquire an Arduino board and an acc_gyro_6dof sensor.

Prerequisites

No really advanced math is necessary. Find a good book on matrix operations, that’s all you might need above school math course. If you would like to refresh your knowledge below are some quick articles:
Cartesian Coordinate System – http://en.wikipedia.org/wiki/Cartesian_coordinate_system
Rotation – http://en.wikipedia.org/wiki/Rotation_%28mathematics%29
Vector scalar product – http://en.wikipedia.org/wiki/Dot_product
Vector cross product – http://en.wikipedia.org/wiki/Cross_product
Matrix Multiplication – http://en.wikipedia.org/wiki/Matrix_multiplication
Block Matrix – http://en.wikipedia.org/wiki/Block_matrix
Transpose Matrix – http://en.wikipedia.org/wiki/Transpose
Triple Product – http://en.wikipedia.org/wiki/Triple_product

Notations

Vectors are marked in bold text - so for example “v” is a vector and “v” is a scalar (if you can’t distinguish the two there’s problem with the text formatting wherever you’re reading this).

Part 1. The DCM Matrix

Generally speaking orientation kinematics deals with calculating the relative orientation of a body relative to a global coordinate system. It is useful to attach a coordinate system to our body frame and call it Oxyz, and another one to our global frame and call it OXYZ. Both the global and the body frames have the same fixed origin O (see Fig. 1). Let’s also define i, j, k to be unity vectors co-directional with the body frame’s x, y, and z axes – in other words they are versors of Oxyz and let I, J, K be the versors of global frame OXYZ.

Figure 1

Thus, by definition, expressed in terms of global coordinates vectors I, J, K can be written as:

I^G = {1,0,0} ^T, J^G={0,1,0} ^T , K^G = {0,0,1} ^T

Note: we use {…} ^T notation to denote a column vector, in other words a column vector is a translated row vector. The orientation of vectors (row/column) will become relevant once we start multiplying them by a matrix later on in this text.

And similarly, in terms of body coordinates vectors i, j, k can be written as:

i^B = {1,0,0} ^T, j^B={0,1,0} ^T , k^B = {0,0,1} ^T

Now let’s see if we can write vectors i, j, k in terms of global coordinates. Let’s take vector i as an example and write its global coordinates:

i^G = {i_x^G , i_y^G , i_z^G} ^T

Again, by example let’s analyze the X coordinate i_x^G, it’s calculated as the length of projection of the i vector onto the global X axis.

i_x^G = |i| cos(X,i) = cos(I,i)

Where |i| is the norm (length) of the i unity vector and cos(I,i) is the cosine of the angle formed by the vectors I and i. Using the fact that |I| = 1 and |i| = 1 (they are unit vectors by definition). We can write:

i_x^G = cos(I,i) = |I||i| cos(I,i) = I.i

Where I.i. is the scalar (dot) product of vectors I and i. For the purpose of calculating scalar product I.i it doesn’t matter in which coordinate system these vectors are measured as long as they are both expressed in the same system, since a rotation does not modify the angle between vectors so: I.i = I^B.i^B = I^G.i^G = cos(I^B.i^B) = cos(I^G.i^G) , so for simplicity we’ll skip the superscript in scalar products I.i , J.j , K.k and in cosines cos(I,i), cos(J,j), cos(K,k).

Similarly we can show that:

i_y^G = J.i , i_z^G=K.i , so now we can write vector i in terms of global coordinate system as:

i^G= { I.i, J.i, K.i}^T

Furthermore, similarly it can be shown that j^G= { I.j, J.j, K.j} ^T , k^G= { I.k, J.k, K.k} ^T.

We now have a complete set of global coordinates for our body’s versors i, j, k and we can organize these values in a convenient matrix form:

(Eq. 1.1)

This matrix is called Direction Cosine Matrix for now obvious reasons – it consists of cosines of angles of all possible combinations of body and global versors.

The task of expressing the global frame versors I^G, J^G, K^G in body frame coordinates is symmetrical in nature and can be achieved by simply swapping the notations I, J, K with i, j, k, the results being:

I^B= { I.i, I.j, I.k}^T , J^B= { J.i, J.j, J.k}^T , K^B= { K.i, K.j, K.k}^T

and organized in a matrix form:

(Eq. 1.2)

It is now easy to notice that DCM^B = (DCM^G)^T or DCM^G = (DCM^B)^T , in other words the two matrices are translates of each other, we’ll use this important property later on.

Also notice that DCM^B. DCM^G = (DCM^G)^T .DCM^G = DCM^B. (DCM^B)^T = I₃ , where I₃ is the 3×3 identity matrix. In other words the DCM matrices are orthogonal.

This can be proven by simply expanding the matrix multiplication in block matrix form:

(Eq. 1.3)

To prove this we use such properties as for example: i^GT. i^G = | i^G|| i^G|cos(0) = 1 and i^GT. j^G = 0 because (i and j are orthogonal) and so forth.

The DCM matrix (also often called the rotation matrix) has a great importance in orientation kinematics since it defines the rotation of one frame relative to another. It can also be used to determine the global coordinates of an arbitrary vector if we know its coordinates in the body frame (and vice versa).

Let’s consider such a vector with body coordinates:

r^B= { r_x^B, r_y^B, r_z^B} ^T and let’s try to determine its coordinates in the global frame, by using a known rotation matrix DCM^G.

We start by doing following notation:

r^G = { r_x^G , r_y^G , r_z^G } ^T.

Now let’s tackle the first coordinate r_x^G:

r_x^G = | r^G| cos(I^G,r^G) , because r_x^G is the projection of r^G onto X axis that is co-directional with I^G.

Next let’s note that by definition a rotation is such a transformation that does not change the scale of a vector and does not change the angle between two vectors that are subject to the same rotation, so if we express some vectors in a different rotated coordinate system the norm and angle between vectors will not change:

| r^G| = | r^B| , | I^G| = | I^B| = 1 and cos(I^G,r^G) = cos(I^B,r^B), so we can use this property to write

r_x^G = | r^G| cos(I^G,r^G) = | I^B || r^B| cos(I^B,r^B) = I^B. r^B = I^B. { r_x^B, r_y^B, r_z^B} ^T , by using one the two definition of the scalar product.

Now recall that I^B= { I.i, I.j, I.k}^T and by using the other definition of scalar product:

r_x^G = I^B. r^B = { I.i, I.j, I.k}^T . { r_x^B, r_y^B, r_z^B} ^T = r_x^B I.i + r_y^B I.j + r_z^B I.k

In same fashion it can be shown that:

r_y^G = r_x^B J.i + r_y^B J.j + r_z^B J.k
r_z^G = r_x^B K.i + r_y^B K.j + r_z^B K.k

Finally let’s write this in a more compact matrix form:

(Eq. 1.4)

Thus the DCM matrix can be used to covert an arbitrary vector r^B expressed in one coordinate system B, to a rotated coordinate system G.

We can use similar logic to prove the reverse process:

(Eq. 1.5)

Or we can arrive at the same conclusion by multiplying both parts in (Eq. 1.4) by DCM^B which equals to DCM^GT, and using the property that DCM^GT.DCM^G = I₃ , see (Eq. 1.3):

DCM^B r^G = DCM^B DCM^G r^B = DCM^GT DCM^G r^B = I₃ r^B = r^B

Part 2. Angular Velocity

So far we have a way to characterize the orientation of one frame relative to another rotated frame, it is the DCM matrix and it allows us to easily convert the global and body coordinates back and forth using (Eq. 1.4) and (Eq. 1.5). In this section we’ll analyze the rotation as a function of time that will help us establish the rules of updating the DCM matrix based on a characteristic called angular velocity. Let’s consider an arbitrary rotating vector r and define it’s coordinates at time t to be r(t). Now let’s consider a small time interval dt and make the following notations: r = r (t) , r’= r (t+dt) and dr = r’ – r:

Figure 2

Let’s say that during a very small time interval dt → 0 the vector r has rotated about an axis co-directional with a unity vector u by an angle dθ and ended up in the position r’. Since u is our axis of rotation it is perpendicular to the plane in which the rotation took place (the plane formed by r and r’) so u is orthogonal to both r and r’. There are two unity vectors that are orthogonal to the plane formed by r and r’, they are shown on the picture as u and u’ since we’re still defining things we’ll choose the one that is co-directional with the cross product r x r’, following the rule of right-handed coordinate system. Thus because u is a unity vector |u| = 1 and is co-directional with r x r’ we can deduct it as follows:

u = (r x r’) / |r x r’| = (r x r’) / (|r|| r’|sin(dθ)) = (r x r’) / (|r|² sin(dθ)) (Eq. 2.1)

Since a rotation does not alter the length of a vector we used the property that| r’| = |r|.

The linear velocity of the vector r can be defined as the vector:

v = dr / dt = ( r’ – r) / dt (Eq. 2.2)

Please note that since our dt approaches 0 so does dθ → 0, hence the angle between vectors r and dr (let’s call it α) can be found from the isosceles triangle contoured by r , r’ and dr:

α = (π – dθ) / 2 and because dθ → 0 , then α → π/2

What this tells us is that r is perpendicular to dr when dt → 0 and hence r is perpendicular to v since v and dr are co-directional from (Eq. 2.2):

v ⊥ r (Eq. 2.21)

We are now ready to define the angular velocity vector. Ideally such a vector should define the rate of change of the angle θ and the axis of the rotation, so we define it as follows:

w = (dθ/dt ) u (Eq. 2.3)

Indeed the norm of the w is |w| = dθ/dt and the direction of w coincides with the axis of rotation u. Let’s expand (Eq. 2.3) and try to establish a relationship with the linear velocity v:

Using (Eq. 2.3) and (Eq. 2.1):

w = (dθ/dt ) u = (dθ/dt ) (r x r’) / (|r|² sin(dθ))

Now note that when dt → 0, so does dθ → 0 and hence for small dθ, sin(dθ) ≈ dθ , we end up with:

w = (r x r’) / (|r|² dt) (Eq. 2.4)

Now because r’ = r + dr , dr/dt = v , r x r = 0 and using the distributive property of cross product over addition:

w = (r x (r + dr)) / (|r|² dt) = (r x r + r x dr)) / (|r|² dt) = r x (dr/dt) / |r|²

And finally:

w = r x v / |r|²­ (Eq. 2.5)

This equation establishes a way to calculate angular velocity from a known linear velocity v.

We can easily prove the reverse equation that lets us deduct linear velocity from angular velocity:

v = w x r ­ (Eq. 2.6)

This can be proven simply by expanding w from (Eq. 2.5) and using vector triple product rule (a x b) x c = (a.c)b – (b.c)a. Also we’ll use the fact that v and r are perpendicular (Eq. 2.21) and thus v.r = 0

w x r = (r x v / |r|²­) x r = (r x v) x r / |r|²­ = ((r.r) v + (v.r)r) / |r|²­ = ( |r|²­ v + 0) |r|² = v

So we just proved that (Eq. 2.6) is true. Just to check (Eq. 2.6) intuitively – from Figure 2 indeed v has the direction of w x r using the right hand rule and indeed v ⊥ r and v ⊥ w because it is in the same plane with r and r’.

Part 3. Gyroscopes and angular velocity vector

A 3-axis MEMS gyroscope is a device that senses rotation about 3 axes attached to the device itself (body frame). If we adopt the device’s coordinate system (body’s frame), and analyze some vectors attached to the earth (global frame), for example vector K pointing to the zenith or vector I pointing North – then it would appear to an observer inside the device that these vector rotate about the device center. Let w_x , w_y , w_z be the outputs of a gyroscope expressed in rad/s – the measured rotation about axes x, y , z respectively. Converting from the raw output of the gyroscope to physical values is discussed for example here: http://www.starlino.com/imu_guide.html . If we query the gyroscope at regular, small time intervals dt, then what gyroscope output tells us is that during this time interval the earth rotated about gyroscope’s x axis by an angle of dθ_x = w_xdt, about y axis by an angle of dθ_y = w_ydt and about z axis by an angle of dθ_z = w_zdt. These rotations can be characterized by the angular velocity vectors: w_x = w_x i = {w_x , 0 , 0 }^T , w_y = w_y j = { 0 , w_y , 0 }^T , w_z = w_z k = { 0 , 0, w_z }^T , where i,j,k are versors of the local coordinate frame (they are co-directional with body’s axes x,y,z respectively). Each of these three rotations will cause a linear displacement which can be expressed by using (Eq. 2.6):

dr₁ = dt v₁ = dt (w_x x r) ; dr₂ = dt v₂ = dt (w_y x r) ; dr₃ = dt v₃ = dt (w_z x r) .

The combined effect of these three displacements will be:

dr = dr₁ + dr₂ + dr₃ = dt (w_x x r + w_y x r + w_z x r) = dt (w_x + w_y + w_z) x r (cross product is distributive over addition)

Thus the equivalent linear velocity resulting from these 3 transformations can be expressed as:

v = dr/dt = (w_x + w_y + w_z) x r = w x r , where we introduce w = w_x + w_y + w_z = {w_x , w_y , w_z }

Which looks exactly like (Eq. 2.6) and suggests that the combination of three small rotations about axes x,y,z characterized by angular rotation vectors w_x , w_y , w_z is equivalent to one small rotation characterized by angular rotation vector w = w_x + w_y + w_z = {w_x , w_y , w_z }. Please note that we’re stressing out that these are small rotations, since in general when you combine large rotations the order in which rotations are performed become important and you cannot simply sum them up. Our main assumption that let us go from a linear displacement to a rotation by using (Eq. 2.6) was that dt is really small, and thus the rotations dθ and linear displacement dr are small as well. In practice this means that the larger the dt interval between gyro queries the larger will be our accumulated error, we’ll deal with this error later on. Now, since w_x , w_y , w_z are the output of the gyroscope, then we arrive at the conclusion that in fact a 3 axis gyroscope measures the instantaneous angular velocity of the world rotating about the device’s center.

Part 4. DCM complimentary filter algorithm using 6DOF or 9DOF IMU sensors

In the context of this text a 6DOF device is an IMU device consisting of a 3 axis gyroscope and a 3 axis accelerometer. A 9DOF device is an IMU device of a 3 axis gyroscope, a 3 axis accelerometer and a 3 axis magnetometer. Let’s attach a global right-handed coordinate system to the Earth’s frame such that the I versor points North, K versor points to the Zenith and thus, with these two versors fixed, the J versor will be constrained to point West.

Figure 3

Also let’s consider the body coordinate system to be attached to our IMU device (acc_gyro used as an example),

Figure 4

We already established the fact that gyroscopes can measure the angular velocity vector. Let’s see how accelerometer and magnetometer measurements will fall into our model.

Accelerometers are devices that can sense gravitation. Gravitation vector is pointing towards the center of the earth and is opposite to the vector pointing to Zenith K^B. If the 3 axis accelerometer output is A = {A_x , Ay , A_z } and we assume that there are no external accelerations or we have corrected them then we can estimate that K^B = -A. (See this IMU Guide for more clarifications http://www.starlino.com/imu_guide.html).

Magnetometers are devices that are really similar to accelerometers, except that instead of gravitation they can sense the Earth’s magnetic North. Just like accelerometers they are not perfect and often need corrections and initial calibration. If the corrected 3-axis magnetometer output is M = {M_x , My , M_z }, then according to our model I^B is pointing North , thus I^B = M.

Knowing I^B and K^B allows us calculate J^B = K^B x I^B.

Thus an accelerometer and a magnetometer alone can give us the DCM matrix , expressed either as DCM^B or DCM^G

DCM^G = DCM^BT = [I^B, J^B, K^B]^T

The DCM matrix can be used to convert any vector from body’s(devices) coordinate system to the global coordinate system. Thus for example if we know that the nose of the plane has some fixed coordinates expressed in body’s coordinate system as r^B = {1,0,0}, the we can find where the device is heading in other words the coordinates of the nose in global coordinate systems using (Eq. 1.4):

r^G = DCM^G r^B

So far you’re asking yourself if an accelerometer and a magnetometer gives us the DCM matrix at any point in time, why do we need the gyroscope ? The gyroscope is actually a more precise device than the accelerometer and magnetomer are , it is used to “fine-tune” the DCM matrix returned by the accelerometer and magnetometer.

Gyroscopes have no sense of absolute orientation of the device , i.e. they don’t know where north is and where zenith is (things that we can find out using the accelerometer and magnetometer), instead if we know the orientation of the device at time t, expressed as a DCM matrix DCM(t) , we can find a more precise orientation DCM(t+dt) using the gyroscope , then the one estimated directly from the accelerometer and magnetometer direct readings which are subject to a lot of noise in form of external (non-gravitational) inertial forces (i.e. acceleration) or magnetically forces that are not caused by the earth’s magnetic field.

These facts call for an algorithm that would combine the readings from all three devices (accelerometer, magnetometer and gyroscope) in order to create our best guess or estimate regarding the device orientation in space (or space’s orientation in device’s coordinate systems), the two orientations are related since they are simply expressed using two DCM matrices that are transpose of one another (DCM^G = DCM^BT ).

We’ll now go ahead and introduce such an algorithm.

We’ll work with the DCM matrix that consists of the versors of the global (earth’s) coordinate system aligned on each row:

If we read the rows of DCM^G we get the vectors I^B, J^B, K^B. We’ll work mostly with vectors K^B (that can be directly estimated by accelerometer) and vector I^B (that can be directly estimated by the magnetometer). The vector J^B is simply calculated as J^B = K^B x I^B , since it’s orthogonal to the other two vectors (remember versors are unity vectors with same direction as coordinate axes).

Let’s say we know the zenith vector expressed in body frame coordinates at time t₀ and we note it as K^B_0. Also let’s say we measured our gyro output and we have determined that our angular velocity is w = {w_x , w_y , w_z }. Using our gyro we want to know the position of our zenith vector after a small period of time dt has passed we’ll note it as K^B_1G . And we find it using (Eq. 2.6):

K^B_1G ≈ K^B₀ + dt v = K^B₀ + dt (w_g x K^B₀) = K^B₀ + ( dθ_g x K^B₀)

Where we noted dθ_g = dt w_g. Because w_g is angular velocity as measured by the gyroscope. We’ll call dθ_g angular displacement. In other words it tells us by what small angle (given for all 3 axis in form of a vector) has the orientation of a vector K^B changed during this small period of time dt.

Obviously, another way to estimate K^B is by making another reading from accelerometer so we can get a reading that we note as K^B_1A .

In practice the values K^B_1G will be different from from K^B_1A. One was estimated using our gyroscope and the other was estimated using our accelerometer.

Now it turns out we can go the reverse way and estimate the angular velocity w_a or angular displacement dθ_{a ­}= dt w_a , from the new accelerometer reading K^B_1A­ , we’ll use (Eq. 2.5):

w­_a = K^B₀ x v_a / | K^B₀|²­

Now v_a = (K^B_1A­ - K^B₀) / dt , and is basically the linear velocity of the vector K^B₀. And | K^B₀|²­­ = 1 , since K^B₀ is a unity vector. So we can calculate:

dθ_{a ­}= dt w_a = K^B₀ x (K^B_1A­ - K^B₀)

The idea of calculating a new estimate K^B_{1 ­} that combines both K^B_1A and K^B_1G is to first estimate dθ as a weighted average of dθ_a and dθ_g :

dθ = (s_a dθ_a + s_g dθ_g) / (s_a + s_g­), we’ll discuss about the weights later on , but shortly they are determined and tuned experimentally in order to achieve a desired response rate and noise rejection.

And then K^B_{1 ­} is calculated similar to how we calculated K^B_1G:

K^B₁ ≈ K^B₀ + ( dθ x K^B₀)

Why we went all the way to calculate dθ and did not apply the weighted average formula directly to K^B_1A and K^B_1G ? Because dθ can be used to calculate the other elements of our DCM matrix in the same way:

I^B₁ ≈ I^B₀ + ( dθ x I^B₀)

J^B₁ ≈ J^B₀ + ( dθ x J^B₀)

The idea is that all three versors I^B, J^B, K^B are attached to each other and will follow the same angular displacement dθ during our small interval dt. So in a nutshell this is the algorithm that allows us to calculate the DCM₁ matrix at time t₁ from our previous estimated DCM₀ matrix at time t­­₀. It is applied recursively at regular small time intervals dt and gives us an updated DCM matrix at any point in time. The matrix will not drift too much because it is fixed to the absolute position dictated by the accelerometer and will not be too noisy from external accelerations because we also use the gyroscope data to update it.

So far we didn’t mention a word about our magnetometer. One reasons being that it is not available on all IMU units (6DOF) and we can go away without using it, but our resulting orientation will then have a drifting heading (i.e. it will not show if we’re heading north, south, west or east), or we can introduce a virtual magnetometer that is always pointing North, to introduce stability in our model. This situation is demonstrated in the accompanying source code that used a 6DOF IMU.

Now we’ll show how to integrate magnetometer readings into our algorithm. As it turns out it is really simple since magnetometer is really similar to accelerometer (they even use similar calibration algorithms), the only difference being that instead of estimating the Zenith vector K^B vector it estimates the vector pointing North I^B. Following the same logic as we did for our accelerometer we can determine the angular displacement according to the updated magnetometer reading as being:

dθ_{m ­}= dt w_m = I^B₀ x (I^B_1M­ - I^B₀)

Now let’s incorporate it into our weighted average:

dθ = (s_a dθ_a + s_g dθ_g + s_m dθ_m) / (s_a + s_g +_­ s_m)

From here we go the same path to calculate the updated DCM_1­

I^B₁ ≈ I^B₀ + ( dθ x I^B₀) , K^B₁ ≈ K^B₀ + ( dθ x K^B₀) and J^B₁ ≈ J^B₀ + ( dθ x J^B₀),

In practice we’ll calculate J^B₁ = K^B₁ x I^B_1, after correcting K^B₁ and I^B₁ to be perpendicular unity vectors again , note that all our logic is approximated and dependent on dt being small, the larger the dt the larger the error we’ll accumulate.

So if vectors I^B₀, J^B₀, K^B₀ form a valid DCM matrix , in other words they are orthogonal to each other and are unity vectors, then we can’t say the same about I^B₁, J^B₁, K^B₁ , the formulas used for calculating them does not guarantee the orthogonality or length of the vector to be preserved , however we will not get a big error if dt is small, all we need to do is to correct them after each iteration.

First let’s see how we can ensure that two vectors are orthogonal again. Let’s consider two unity vectors a and b that are “almost orthogonal” in other words the angle between these two vectors is close to 90°, but not exactly 90°. We’re looking to find a vector b’ that is orthogonal to a and that is in the same plane formed by the vectors a and b. Such a vector is easy to find as shown in Figure 5. First we find vector c = a x b that by the rules of cross product is orthogonal to both a and b and thus is perpendicular to the plane formed by a and b. Next the vector b’ = c x a is calculated as the cross product of c and a. From the definition of cross product b’ is orthogonal to a and because it is also orthogonal to c – it end up in the plane orthogonal to c , which is the plane formed by a and b. Thus b’ is the corrected vector we’re seeking that is orthogonal to a and belongs to the plane formed by a and b.

Figure 5

We can extend the equation using the triple product rule and the fact that a.a = |a| = 1:

b’ = c x a = (a x b) x a = -a (a.b) + b(a.a) = b – a (a.b) = b + d , where d = – a (a.b) (Scenario 1, a is fixed b is corrected)

You can reflect a little bit on the results … So we obtain corrected vector b’ from vector b by adding a “correction” vector d = – a (a.b). Notice that d is parallel to a. Its direction is dependent upon the angle between a and b, for example in Figure 5 a.b = cos (a,b) > 0 , because angle between a and b is less than 90°thus d has opposite direction from a and a magnitutde of cos(a,b) = sin(b,b’).

In the scenario above we considered that vector a is fixed and we found a corrected vector b’ that is orthogonal to a. We can consider the symmetric problem – we fix b and find the corrected vector a’:

a’ = a – b (b.a) = a – b (a.b) = a + e, where e = - b (a.b) (Scenario 2, b is fixed a is corrected)

Finally in the third scenario we want both vectors to move towards their corrected state, we consider them both “equally wrong”, so intuitively we apply half correction to both vectors from scenario 1 and 2:

a’ = a – b (a.b) / 2 (Scenario 3, both a and b are corrected)
b’ = b – a (a.b) / 2

Figure 6

This is an relatively easy formula to calculate on a microprocessor since we can pre-compute Err = (a.b)/2 and then use it to correct both vectors:

a’ = a – Err * b
b’ = b – Err * a

Please note that we’re not proving that a’ and b’ are orthogonal in Scenario 3, but we presented the intuitive reasoning why the angle between a’ and b’ will get closer to 90°if we apply the above corrective transformations.

Now going back to our updated DCM matrix that consists of three vectors I^B₁, J^B₁, we apply the following corrective actions before reintroducing the DCM matrix into the next loop:

Err = ( I^B₁ . J^B₁ ) / 2

I^B₁^’ = I^B₁ – Err * J^B₁
J^B₁^’ = J^B₁ – Err * I^B₁
I^B₁^’’ = Normalize[I^B₁^’]
J^B₁^’’ = Normalize[J^B₁^’]
K^B₁^’’ = I^B₁^’’ x J^B₁^’’

Where Normalize[a] = a / |a| , is the formula calculating the unit vector co-directional with a.

So finally our corrected DCM₁ matrix can be recomposed from vectors I^B₁^’’, J^B₁^’’, K^B₁^’’ that have been ortho-normalized (each vector constitutes a row of the updated and corrected DCM matrix).

We repeat the loop to find DCM_{2 ,} DCM_{3 ,} or in general DCM _n , at any time interval n.

References

1. Theory of Applied Robotics: Kinematics, Dynamics, and Control (Reza N. Jazar)

2. Linear Algebra and Its Applications (David C. Lay)

3. Fundamentals of Matrix Computations (David S. Watkins)

4. Direction Cosine Matrix IMU: Theory (W Premerlani)

Additional Notes

For the implementation of the algorithm for now see my quadcopter project in particular releases 6/7 have a nice Processing program for visual display of the DCM matrix and a model plane. The entire code is on SVN repository:

http://code.google.com/p/picquadcontroller/source/browse/?r=7#svn%2Ftrunk

The code is in imu.h file:

http://code.google.com/p/picquadcontroller/source/browse/trunk/imu.h?r=7

A PDF Version of this article is available here

DCM Tutorial – An Introduction to Orientation Kinematics by Starlino (PDF, Rev 0.1 Draft)

Please mention and link to the source when using information in this article:

http://www.starlino.com/dcm_tutorial.html

Starlino Electronics  // Spring , 2011

So I decided to build one for  the the acc_gyro boards. But how do you hold the board in place ? Using screws is secure but takes long time to put a board in and out. I needed a faster way to test a larger amount of boards.

Well after several experimentations with velcro tape, rubber bands , and even custom fitted clamps made out of polymorth , I arrived at this simple solution, just use some headers with extra long leads , the pictures tell it all:

The board is basically held by the plastic parts of 2 long headers. You simply spread them apart, insert the board and then , when they come back together they hold the board in place by the spring action of the pogo pins that pushes the board up.

To remove the board simply spread the headers again and the board pops up …

Hope the method could be useful to someone , so decided to share.

//starlino//

Well Radioshack first thank you for replying and not ignoring us altogether. But we would like to see more actions being done. As a reply I will leave you with a related comment from a 10th grade student:

Hello, my name is Nic. I'm in grade 10 and I have an interest in electronics. But I have a lot of restrictions. I live in Canada in a town where there is no electronics shop other than "The Source" (Radioshack was bought out by The Source) which sells overpriced components that aren't the greatest quality, I'm far away from A1 Electronics which is a brilliant store in missisauga. And There is no Electronics course in my high school.  …

[Source: http://www.instructables.com/id/New-Life-for-Old-Printed-Circuit-Boards/ ]

 

$26.95  STEVAL-MKI093V1 ( breakout for LYPR540AH  – 3 axis analog gyro )

http://www.mouser.com/ProductDetail/STMicroelectronics/STEVAL-MKI093V1/?qs=Mmr5WwCtLzNTGieQUi715w%3d%3d

Looks like , Mouser has all datasheet , pictures and descriptions wrong at the time of this post.

correct datasheet   http://www.st.com/stonline/products/literature/bd/17906/steval-mki093v1.pdf

$26.95 STEVAL-MKI064V1 (breakout for LSM303DLH  3-axis magnetometer + 3-axis accelerometer)

http://www.mouser.com/ProductDetail/STMicroelectronics/STEVAL-MKI064V1/?qs=Mmr5WwCtLzNMjRxMWs1ArA%3d%3d

correct datasheet http://www.st.com/stonline/products/literature/bd/17844/steval-mki064v1.pdf

Order while they are in stock :-)

Create a file called  arduino.reg with the following contents:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.pde]
@="Arduino.Document"

[HKEY_CLASSES_ROOT\Arduino.Document\shell\open\command]
@="\"C:\\arduino\\arduino.exe\" \"%1\""

Please note this assumes your arduino installation was unzipped to C:\arduino\ . If different , update accordingly the reg file but make sure to use double quotes \\ for path delimiter as highlighted above.

Next simply double click on the arduino.reg file you have created and the keys will be imported to your registry. Now when you right click on the .pde file you should see arduino as one of the options (and you can make it default program to open pde files). 

For $99  MuSA  could be a nice hackable platform for all sorts of motion-enabled applications.  It has a  built-in accelerometer , LCD  and a simple casing. Here is the description from ST:

"The platform comes with the LIS331DLH preinstalled on the board, but can support any digitaloutput accelerometer from ST in 3×3 or 3×5 mm packages connected to the microcontroller through an SPI interface, as well as the LIS344ALH analog-output accelerometer.

The MuSA platform features four buttons for navigating the menus. A mini-USB connector is available to exchange data with a PC, depending on the specific application, and also recharges the internal Li-ion battery. The battery is capable of providing power for approximately 7 hours of operation."

For device demonstration see video here:

http://www.st.com/stonline/domains/support/edemoroom/index.htm?id=14

If you found yourself in this funny situation you're not alone, the truth is that at this time  there are no serious retail stores for the electronics hobbyist, however there's a booming market !  Due to the current economic environment I doubt that someone would venture to open a nation-wide retail chain like the one Radioshack has, this being the reason I decided to write an open letter to the company. You might not like the Radioshack company but the truth is that we need them and they need us !

I am NOT going to send them this letter, instead I will put it out in the wild-wild web  and let the natural selection do its work. If it makes (or when it makes)  to someone in the Radioshack management  – it means there are enough people who think like I think to make it happen.

That being said , here is the letter, if you'd like to join the petition, leave a comment, post it on your blog, do whatever you feel like, just keep it civilized please.

"Dear RADIOSHACK,

We the electronics hobbyists of America would like to inform you that we are back ! Our soldering irons got cold during the 90's and 2000's  which made you pull all that interesting stuff to the back shelves. But we are the new generation and we are here to continue what our fathers and mothers have started, we are here to invent , change modify and rebuild this country back to it's glory days. We need your help though, we want our voices to be heard, we feel like you're not in touch with reality, while you were sleeping companies like Adafruit, Sparkfun, Make Magazine and many many others , have created a huge online community of new engineers and inventors who are the only hope that this country will once again regain it's edge in the technological field !

You shouldn't be threatened by these online retailers, neither should they be threatened by you, you should instead try to work together with them. In fact as a start you should try to resell their kits, they don't mind anyone copying their work, in fact they publish the schematics, code and advices how to use their products. They are not threatened by anyone, because they will never run out of ideas, they will always be one step ahead, and as long as this happens in our country we all have to gain !

We admire that you started carrying  Parallax products, however we find it somehow funny that searching for "Arduino" on Radioshack site returns "The BASIC Stamp Kit" , why not just start carrying Arduino just like Jameco recently did ?

If you're concerned that you don't have the market yet to pull those products from back shelves and create a larger inventory, don't forget that a market is not only the market that you have, but the market that you're going to create. Next time a father or mother  enters your store to buy batteries she might see all those interesting electronics kits and decide that's a good thing for their children to do in order to keep them busy and away from trouble. Why not get more involved in the community and organize or sponsor some electronics clubs, because we know you were sleeping – they are called nowdays  "hackerspaces". But don't worry they have nothing to do with hackers and bad guys, in fact they are very friendly and open to anyone.

We understand that things might be tough in the financial chapter right now, it might seem strange but we want to give you our money , just give us the stuff we need!  We are here to help and give you feedback. Together  we can change many things for the better. Never underestimate the power that our online community has!

With love,

The Electronics Hobbyists of America

"

Once again, if you'd like to join the petition please leave a comment or publish it on your site, let's hope they will hear us :)

//starlino//  

September 16, 2010

Newark has just launched their new hobbyist / maker oriented web site www.element14.com as well as their own video blog  persona Ben Heck. When I first saw Ben I thought "I didn't know Conan O'Brian is into electronics. Wait that's not Conan !". Just like David L. Jones from EEVBlog , Ben likes to take things apart even before turning them on. I enjoyed very much his X-Box tear down and custom foot controlled XBox controller  and I am looking forward to seeing more videos like this.

Jameco has teamed up with Make Magazine 's   Collin Cunningham and forged a series of video tutorials aimed towards electronics beginners. And yes they finally carry Arduino in stock  !

In the same spirit , Texas Instruments launched few months ago a subsidized development platform MSP430 LaunchPad trying to win the hearts of all those Microchip PIC and Atmel AVR fanboys out there. But word along the benches is that it ain't gonna happen unless they make it Arduino shield pin compatible :).

Old news already – but ST tried a similar move with their STM8S-Discovery kit , not sure how many people they converted but it's interesting to see some competition going on for this hobbyist /  maker , no-longer-niche market.

Adafruit and Sparkfun  are two wonderful pioneer companies that showed to the world that   [title of this post]  = TRUE  ! They started  from zero and reached millions of dollars in sales in just few years. A good example that if you like what you're doing and you are passionate about it – you're going to go a long way.

Overall my feeling is that we are witnessing a new boom right now.  Robotics and Electronics is for 2010's what  Internet was for 2000's and personal computers for 1990's. For all those still in doubt , or who haven't  send their college applications yet – this is THE FIELD to work in the next decade ! A lot of wonderful things are just waiting to happen ! Stay tuned and enjoy the ride.

Here are close-ups of the before and after desoldering:

As you can see desoldering something is really easy, and you get a really-really clean result with this tool.

There are few things to take care of though:

- do not touch the PCB traces for more than one second, this tool is hot and if you heat up the pads for too long it will suck them up
- buy several tip sizes for different jobs ,  i got  1mm (comes in the kit) and additionally I got  1.8mm and 2.3mm tips
- clean your tool regularly. The most replaced items are the ceramic filters so stock up on those, when they harden from the flux it's time to replace them.

Source: Hakko 808 Manual  (Download PDF)

Hakko 808 Kit comes with a carry-on case and few spare parts. What is missing is a holder, that you can buy separately (Hakko 633), however the tool will lay on it's side on the table without touching the surface so that will suffice if you don't have a holder. Another feature that is missing is a  an on/off switch, unplugging this from power outlet is not convenient especially if you have to crawl under the table with a hot tool on the table :)

Overall Hakko 808 is great tool , worth every penny, and I would buy it again if it breaks, speaking of which it is nicely build and has spare parts available so self-repair is possible and even encouraged and explained in the manual.

//starlino//

Hakko A1229: Hakko Replacement Pre-Filters for 808-5, 10/pkg.

Demo

Testing one axis:

Schematic

How it Works

The RC transmitter uses a potentiometer for each axis, it acts as a voltage divider sending a voltage of 0..5V (the middle position corresponds to 2.5V) to the analog input that is converted into a pule of  1..2ms that is sent over RF.

This module converts (amplifies and shifts) the accelerometer analog output , usually  1.65 +/- 0.4V to the same range of the potentiometer and sends it to the transmitter instead.

An op-amp in an inverting amplifier configuration is used. Vref is set manually by tuning the output to be 2.5V (or the PWM pulse to be 1.5 ms). However it is possible to calculate the theoretical value as follows:

Note that according to the rules of  a feedback op-amp the voltage on it's inverting/non-inverting terminals tends to equalize so   V(+) = V(-) and in our case  = Vref.

Since no significant current enters the op-amp , the currents going through R1 and R2 are equal:

( V(-) – Vin ) / R1 = ( Vout – V(-) ) / R2  

(Vref – Vin) / R1 = (Vout – Vref) / R2

solving for Vout gives us

Vout = Vref -  R2/R1 (Vin – Vref)    =   Vref( 1 + R2/R1)  – R2/R1 * Vin

now let's do some notations

G = – R2/R1

Vout = Vref( 1 – G)  -  G * Vin

According to our schematic  G =  R2 / R1 =  – 5.12 , this will convert the accelerometer swing of 0.4 V to a swing of   0.4 V * 5.12  ~  2V .

We want  to make   Vin = 1.65  correspond to a  Vout = 2.5 so we  have the equation

2.5 =  Vref (1 + 5.12)  – 5.12 * 1.65

from here we find

Vref =  (2.5 + 5.12 * 1.65 ) /  (1 + 5.12) = 1.78888 V

Well, this is the theoretical value , in practice we adjust the trimmer R3 until the output is 2.5 while the accelerometer is in laying in horizontal position (has an output of 1.65V).

How to Build

To build use a small proto-board following schematic. Part numbers are mentioned on schematic. Hook-up with the transmitter is described in images below and on the schematic. For accelerometer use Acc_Gyro or similar module, or build your own accelerometer break-out board.

The module is mounted in a free space under antenna using double-sided foam tape – best way to mount an accelerometer to avoid vibration. Note that we get +5V power for the module from the potentiometer contacts. You can test  with a led that the power contacts can deliver at least 20mV, the module uses far less <5mA.

Here is a close-up of the module, as you can see I did  my own accelerometer break-out board, but you can buy a pre-assembled one , there are many choices. You will need an analog accelerometer for this project.

Enjoy your new RC Tilt Transmitter. For any comments/questions use the comment form below.

//starlino//

The source code will be Open-Source and will be hosted on Google Code, you can get code for quad copter here:

http://code.google.com/p/picquadcontroller/source/browse/#svn/trunk

As usual I like to start with a video demo, it's basically me controlling the tilt of the quad using a RC controller:

This is a PID feedback algorithm and a "Simplified Kalman Filter" as  described in my other articles.

First of all there's a a RCGroups thread where I first introduced the project

http://www.rcgroups.com/forums/showthread.php?t=1235360

You'll find some specs there and I will put some material here  as well.

Here is Revision 0.1 of schematic (what I started with):

PicQuadControllerRev01.pdf

The major parts list is as follows:

MCU:  DSPIC33FJ128MC802  (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en532302)

Sensors: 5DOF Acc_Gyro ( http://gadgetgangster.com/213 )  + 1Dof Pololu LIST300AL-BREAKOUT (http://www.pololu.com/catalog/product/765).

Motor Drivers:  Power N-Channel Mosfets (Many choices -Low Rds(on) and rated for the current , I used  IRLR8743 ). Schottky diodes to protect against back-EMF ( I used SS2H10-E3/52T )

Frame , motors propellers: I picked a ready platform that was on sale Dragandfly IV Frame these are actually brushed motors same ones as used in Esky helicopters.

I did some tests on the lift force potential of this frame+motors+props, and was surprise to find out it performed better than some entry-level brushless motors. The lift force of this platform is up to 2.25 lbs.  The results of lift-force experiments are compiled in this spreadheet: MotorLiftPower.pdf.

How I measured the lift force ?  I didn't have any fancy equipment so I simply fixed the quad in a vise and weighted  it it at different throttle levels – the difference in weight gave me the lift power.

For testing just one motor, I used a string attached to the weight:

I built a test rig out of wood for testing the tilt balancing algorithm as you see in the video.

Here are some close-ups of the motor drivers. You'll  see the Mosfets and the Schottky diodes, also note the extra solder added to support the high currents that will flow through those traces ( up to 5A per motor !).

Finally here is a view on the top of the board ( notice the PIC , the switching regulator  ,  Acc_Gyro 5DOF IMU and single axes Gyro breakout , from top-left to bottom right).

This is it for now hope to bring you more interesting stuff on this and other projects if time allows  !

//starlino//

Demo:

About the project:

For the hardware I used the Acc_Gyro sensor and a thumb-size PIC platform UsbThumb built around the inexpensive PIC18F14K50 chip that provides all the necessary USB connectivity and ADC inputs.

This setup is actually hardware compatible with my original Motion Gamepad design so all the software utilities and firmware will work on the Acc_Gyro + UsbThumb combination that is available as a kit under the name of UsbThumbImu . The Acc_Gyro fits on top of UsbThumb and this is not a coincidence since UsbThumb was designed as microcontroller helper for the Acc_Gyro with the idea of being able to provide the USB/Serial/SPI/I2C interface, as well as making use of the built-in 10bit ADC module of the PIC18F14K50.

In the pictures above headers are used to connect the device, so the end result is a little taller  than you could get if you'd simply solder the two boards together. Both devices have been designed for people that would like to extend  or experiment with the existing solution so there is a second row of connectors on the UsbThumb that can be used to connect buttons or other devices to the project. 

All that's it for now – hope you liked the project. It was really easy to built having the two important components UsbThumb and Acc_Gyro. You'll find more info on individual components on my website as well as  on the GadgetGangster site with whom I partnered to provide kits for anyone interested. If you don't find the necessary information, or you have any any suggestions, ideas or questions – as always feel free to drop me a line with in the comment area below.

//starlino//

It is basically a customization of Mouse emulation demo that Microchip bundles with their USB Framework.

The code responsible for enabling/disabling mouse emulation is triggered by a timer interrupt like so:

        OpenTimer0( TIMER_INT_ON &
                 T0_16BIT              &
                 T0_SOURCE_INT         &
                T0_PS_1_256);

                     ………….

        //These are your actual interrupt handling routines.

        #pragma interrupt YourHighPriorityISRCode
        void YourHighPriorityISRCode()
        {
                //Check which interrupt flag caused the interrupt.
                //Service the interrupt
                //Clear the interrupt flag
                //Etc.
        #if defined(USB_INTERRUPT)
                USBDeviceTasks();
        #endif
       
                if(INTCONbits.TMR0IF){
                        counter_s++;
                        //to interrupt every 1s we need to count FOSC / 4/ 256  = 46875 ticks (0xB71B)
                        //to count these ticks till overflow we need to set TMR0 to  0xFFFF – 0xB71B = 0x48E4
                       
                        TMR0H = 0×48; //will write to TMR0H buffer
                        TMR0L = 0xE4; //will write actual TMR0L / TMR0H 

                        INTCONbits.TMR0IF = 0;
                }

        }       //This return will be a "retfie fast", since this is in a #pragma interrupt section

       ……………..

       INTCONbits.TMR0IE = 0;  //disable Timer0 interrupt
        if(emulate_mode && counter_s > 3){      // seconds on
                counter_s = 0;
                emulate_mode = 0;
        }else if (!emulate_mode && counter_s > 60){     //seconds off
                counter_s = 0;
                emulate_mode = 1;
        }
        INTCONbits.TMR0IE = 1;

For full source code see:

http://code.google.com/p/usbthumb/source/browse/#svn/trunk/UsbThumbMousePrank

UsbThumb is an open-hardware platform, anyone can build their own:

http://code.google.com/p/usbthumb/source/browse/#svn/trunk/Hardware

or pick up a prebuilt SMT version of UsbThumb here: http://www.gadgetgangster.com/303