Flashing HobbyKing 20A ESC with SimonK Firmware

Standard ESCs are designed for cars and aircraft for which it is undesirable for the speed of the motors to change rapidly.  As such, the firmware running on the ESC accounts for this by ramping motor speeds up or down smoothly regardless of how rapid the change in inputs from the transmitter.  It achieves this by averaging the input signal with the n previous input signals before acting upon it; such filtering necessarily introduces latency in the response of the vehicle.  This latency can, under certain conditions, cause the control system to become unstable.  For the case of a multicopter, we'd like the change in rotor speeds (and thus thrust) to be as fast as possible which will improve the responsiveness of the vehicle. 

Additionally, the standard firmware incorporates other functions which are useful for fixed wing aircraft and cars but could very well be detrimental to multicopters (like a low voltage cutoff - designed to protect your LiPo battery from damage - clearly we don't want the multicopter's motors to shut off mid-flight.)

In a process known as RapidESC, the standard ESC is converted, at no cost, into a high performance, highly responsive ESC suitable for multirotor applications.  Specifically,  we will use open source firmware designed for this process by the legendary Simon Kirby who is well-known throughout the RC multirotor community simply as SimonK.  In the case of the SimonK firmware, the ESC is reprogrammed to run at 400Hz rather than its original speed of 8Hz.  It does, however, continue to average the current input signal with the last n values (which will eliminate spikes in the input), but because the ESC is sampling the input signal 400 times a second instead of 8 times a second, any change in the throttle input will result in an almost immediate change in the RPMs and thus the thrust of the motors.  The video below demonstrates the difference in responsiveness of the control system between an ESC running the standard firmware versus one running SimonK.

So, in short, the idea here is that we'd like to replace the existing firmware on the ESC with the SimonK firmware using a process called "flashing".  It should be noted that this firmware is, in many cases, both brand-specific and model-specific so be sure to select the correct one.  Here is a database containing containing flashing information for various ESC's including which firmware version to use for a particular ESC.  Before beginning it is necessary to identify the RapidESC firmware version that is suitable for the particular ESC being flashed.

Here's what I used...

Hardware

1. HobbyKing Blue Series 20A ESC
   
2. USBasp Programming Device for ATMEL Processors
   
3. ATMEL Atmega Socket Firmware Flashing Tool
   
4. Exacto Knife 
   

Note that (2) and (3) are made specifically for ATMEL processors.  In order to flash ESCs that use a different processor (like Silabs) will require a different (but similar) programming tool and socket connector.

Software

1. KKmulticopter Flash Tool

 This software was, in fact, developed to flash the KK2 flight controller with the latest firmware.  It, however, also allows one to quickly and simply flash one's ESC with the latest version of SimonK firmware which is a .hex file and which can be downloaded automatically from an online repository.  Additionally, this software tool will run on Windows, Mac or Linux (although Windows might first require the installation of a driver for the USB programming device).

Preparing the ESC for flashing

Before the ESC can be flashed, we need to to be able to access the ATMEL processor on the ESC so that an electrical connection can be made.  For this purpose, the shrink wrap covering must be removed.  Rather than removing the entire shrink wrap from the ESC and then having to re-wrap the ESC afterwards it is easier to simply cut an access window/flap.  Use the Exacto knife to cut the shrink wrap around the ATMEL processor, as shown in the picture, on three sides to create a flap that can be folded back.  This now provides direct access to the ATMEL's electrical terminals for the socket tool.

NOTE:  There are two ways to get the correct orientation of the ATMEL processor (which is square in shape).  The first way is to look at the writing on the ATMEL.  If the writing is correctly oriented, then so is the chip.  The second way is to look for the dot on the ATMEL (ie a  small round impression on the ATMEL's plastic casing).  This indicates the top left corner and the chip should be oriented accordingly. 

The socket tool generally has a red dot on one of the corners and the socket tool should be connected to the ATMEL so that the red dot is in the TOP LEFT CORNER - ie the same corner of the ATMEL that contains the circular dot - so we match the dot on the socket tool with the dot on the ATMEL.  If the socket tool does not contain a dot (or if it has since been erased) then look at the pin configuration on the socket tool and you will notice that 4 of the 6 electrical connections are concentrated near one of the corners.  This concentration of pins connects to the LOWER RIGHT HAND corner of the AMTEL chip.

Flashing the ESC with SimonK firmware in 5 simple steps (on my Mac)

1. Download and install the KKmulticopter flash software (just use the latest stable version).
2. Plug the USBasp programmer into the USB port and connect the socket tool to the programmer.
3. Launch the KKmulticopter software set the following:
1. For the programmer, select "Any usbasp clone with correct VID/PID".
2. For the controller, select "atmega 8 based brushless ESC + enable Bootloader (8kb flash)".  NOTE:  Make sure to select the "enable bootloader" option.
3. For the firmware (which will be downloaded from an online repository) select "BS N-FET V2014-03-06 by Simon Kirby" or whatever the most recent update is.  If you are unsure of which version of the firmware to use then take a look at this list.
4. Connect the socket tool to the ATMEL IN THE CORRECT ORIENTATION and hold it in place with one hand.  The pins in the tool are spring-loaded so it is easy to keep the ATMEL connected by applying a bit of downward pressure on the socket tool.
5. With the other hand, click "Flash Firmware".  Whole process takes about 10 seconds.  You are done when you see "Flashing of firmware was successful".

DO NOT DISCONNECT THE FLASHING TOOL TOO SOON OR YOU RUN THE RISK OF PERMANENTLY DAMAGING YOUR ESC.  If you happen to disconnect or are otherwise confronted with red writing (an error) then just repeat steps 4 and 5.

Now close the flap of shrink wrap so that it covers the ATMEL again and add a small piece of tape to keep it in place and you're done.  

Voila.

Building My First Tricopter

Background

After having experimented with quads of varying sizes, I decided it was time to get my teeth stuck into some tricopter building.  Seeing that I would like to use the platform for aerial photography and for experimentation, I was looking for a frame that allowed me both the opportunity of carrying a meaningful payload while enduring as long as possible (with the goal being to keep it under 1,000g AUW while being able to hover for 15+ mins).

After considering a few different options, I decided on the new Turnigy Talon tricopter frame. 

The arms and hubs are made completely of carbon fiber with the mounting blocks for the arms as the motors made from machined aluminum.  Additionally, the arms are made from standard carbon fiber tubes and so can be easily replaced in the case of breakage (arms and propellers tend to be the most commonly broken frame parts on multicopters) .  Once assembled, the frame should weigh in at 350g (accoridng to its instructions) and serves as a good comparison to my DJI 450 quad frame in terms of its overall size, its payload capacity and the space available for mounting equipment.  One salient different is that this tricopter frame has folding arms which allow the frame to be flown three different configurations (including a T-shape) and configured in a fourth for compact storage.  In it's storage configuration it is much smaller than the DJI 450, so much so that it can be easily carried in a small backpack.  Another major difference between a tricopter and quadcopter is that the tricopter requires thrust vectoring of the rear motor/propeller combination in order to control yaw.  For this purpose, a servo is required and a digital servo using metal gears is the preferred way to go.  An ideal servo will have very fast response times, can take a fair amount of abuse and has good centering ability while the amount of torque it can handle is slightly less important. 

Frame Assembly

Assembly was a little tedious as the small parts are not well-suited to my fat fingers.  Additionally, the assembly instructions (which amounted to little more than a breakaway CAD drawing) were basically non-existent.  Would definitely not recommend this build for the beginner.

Steps:

1. Assemble the arm mounts.
   
   
    
   
   
   
   
2. Prepare the hub plates with the appropriate spacers and attachments.
    
   
   
   
   
3. Mount the arms to the hub ensuring that the arms are able to fold properly.
    
   
   
   
   
4. Prepare and attach the motor mounts to the ends of arm.
    
   
   
   
   
5. Voila.  The foldable tricopter frame is compete.  The bare frame tips the scales at 352g.
   
   
   
   
   

Motors and Propeller Sizing

The selection of a motor and propeller for a tricopter is a fairly easy task - much more so than for a quad copter because there is almost no limitation in the size of the propeller one can choose.  While a 450 quadcopter frame can accommodate up to 12-inch propellers (although this even is slightly large due to the proximity of the tips), a similarly sized (and weighted) tricopter frame can accommodate up to 24-inch props (HUGE for a frame of this weight).  In this case we will go with 10 x 4.5 props for now.

 

Office Bot

I decided to build an autonomous bot to rove around my office.  The idea is to use this as a platform to develop and test new ideas for autonomous systems.  These systems will eventually be installed in our Aerobot.  This includes the ability to communicate with the internet using a wireless network.
 

After researching various platforms, I decided upon the Magician chassis at just $14.95 from Sparkfun and it includes two DC motors and gearboxes.  I will be using an Arduino Uno as the controller and this chassis is an appropriate size and provides and good amount of space with its two-shelf design.  This will accommodate the Arduino, a motor shield, battery and a small breadboard for prototyping as well as Sonar, WiFi and PIR sensors.

Assembling the chassis was a little bit tedious (especially for those of us with fat fingers) as there are numerous screws and holes to align.  That said, I am happy with the finished product.  It is sturdy and has ample room to mount sensors and controllers.  Moreover, its design allows one to readily attach additional shelves.  The two wheels plus caster design with a built-in 48:1 gearbox will enable it to roam smoothly along the carpeted floors of my office at a good pace and will also allow for maneuvering in tight spaces.   The Magician chassis also comes with a battery holder (4 x AA batteries) which provides 6V (which will power the Arduino Uno controller).  This was mounted on the lower shelf where it is tucked away out of sight (this will likely make the batteries a little tedious to change in the future as it will require disassembling the shelves).

Additional posts are provided with the chassis kit which are used to mount the controller board - though mounting the Arduino Uno to the shelf required a little jockeying around with the post, but such is the beauty of the shelf design; it provides tremendous flexibility.

So What's The Goal?

 The goal of this project is to build a robot the can autonomously roam my office.  While this goal is a rather vague and open-ended one (due to the fact that one can always add additional "intelligence" to the vehicle) suffice it to say that Phase 1 of this project should seek to achieve the following:

1. COMMS:  Establish wireless communication ("comms") between the bot and a "ground station" computer.  Initially, an PC in my office will serve as the ground station.  The PC will thus be able to send instructions to the bot. 
2. GUIDANCE:  Create a user interface for sending guidance instructions to the bot there by instructing it where to go.  While a general framework will be set up for this, for now only the the commands "forward" and "stop" will be implemented in Phase 1 (it is important with any project always to set up your "STOP/OFF" button first!)
3. AUTONOMOUS CONTROL:  Using a combination of sensors and intelligence algorithms, the bot must be able to navigate the office while avoiding obstacles.  

So the idea is that if one commands "forward" on the PC, the bot should drive "forward" but should stop and turn in order to avoid obstacles (mostly cubicle walls for now).

Controlling Arduino with iPhone using OSC

The iPhone's touch screen allows it to be used as a handy remote control user interface for all sorts of things.  For this project, I used my iPhone to control different electrical components.  The first goal was to use a button on the iPhone to turn an LED on and off and the second goal was to use a fader (potentiometer) control on the iPhone to control the speed of an electric motor (fan).

I used a technology called Open Sound Control (OSC) which is used in the music business to control various audio components (using MIDI).  Without getting into the benefits of OSC in too much detail, suffice it to say that this allows us to very quickly create different custom user interfaces for the purpose of controlling all sorts of things.  Think of the big sound boards with its sliders, buttons, toggles, faders, etc. that one finds in a recording studio - the ones that the sound engineers use.  This is what OSC gives you on your smart phone or tablet (which makes it portable).  It is used often by DJs at clubs that want to use their own, customized, familiar controls to control the music they are playing.  Connectivity is handled through WiFi.

TouchOSC

Of the various OSC apps available for iOS, I decided to go with TouchOSC based on the various reviews that I read.  In order to get OSC to work, a host machine must be set up to receive the OSC commands.  This is achieved by connecting both the iPhone and the host machine to the same WiFi network (yes, ad-hoc mode will work if you don't have a wireless router set up).  The host machine runs an event handler that catches the OSC commands and handles it accordingly by translating it into an instruction for the Arduino.  For the purpose of this project, the Arduino is connected directly to the host computer via USB cable and the serial port is used by the host computer to command the Arduino.  For a completely wireless setup, the Arduino can be linked to the host computer by WiFi, bluetooth or radio link depending on the application.  

There is a a downloadable layout editor provided for TouchOSC which allows one to quickly and easily produce a custom UI on your desktop computer and to sync with TouchOSC in order to upload the layout to the iPhone.

Host Computer

The Processing language was used for the purpose of coding the event handler for the host computer.  Processing is commonly used for interacting with Arduino as the two play very well together.  In fact, the Arduino IDE was derived from the Processing IDE which is why they look so similar.  While the Arduino language has its origins in C/C++, the Processing language comes from JAVA.  This means that the same sketch (the term used for a Processing and Arduino program) can be used on MacOS, Windows, Unix/Linux and can readily be compiled for use on Android OS.  Additionally, Processing is supported by a huge open source community and, consequently, there are libraries and sketches already available for many different things - including OSC handling.

Controlling an LED

 

Circuitry

For the purpose on this demonstration,  a simple circuit was set up containing an LED plus a resistor connected to the cathode (-ve terminal) of the LED.  The other end of the resistor was connected to ground on the Arduino while the LED's anode (+ve terminal) was connected to digital pin 9 on the Arduino.  By writing a HIGH or LOW value to pin 9, the LED can be turned on and off respectively.

Arduino Sketch

The Arduino sketch is very simple and pretty much just contains an event handler which monitors the serial port for any data (in this case only 1 byte of data is being communicated each time).  In this case, the data being sent is simply a "1" or a "0" from which the Arduino determines whether to send a HIGH or LOW voltage to pin 9.  A copy of the sketch can be download from here.

 

Processing Sketch

The Processing sketch is slightly more involved than the Arduino sketch (although only slightly).  Using Processing, the host computer must also run an event handler in order to receive commands from TouchOSC on the iPhone.  The handler catches the incoming message from TouchOSC, parses the message in order to determine which control sent the message and the corresponding value.  

TouchOSC

In this case, we just needed a simple on/off toggle switch.  A custom layout was created containing a toggle switch (which I named 'toggle1') and was set to send the values of '0' or '1' depending on the state of the toggle.  IMPORTANT:  Under Settings-->Connections-->OSC, the host name must be set to the IP address of the host computer.  The host computer should be configured with a static IP address to ensure that it won't somehow change unexpectedly.

So, in this case a typical message sent from TouchOSC will look something like "1/toggle1" followed by a value (in this case a 0 or 1).  By parsing this message, the processing code determines which control was changed (in this case it is only toggle1).  For a more general set up, the Processing sketch should be abstracted so that it can handle different types of controls.  In general (although not used in this case), the Processing sketch will send a different range of values to those that the Arduino is expecting so there is usually some mapping that is handled by Processing.  For example, you could have set a knob on TouchOSC to send the value of 0 to 180 (which indicates how many degrees the knob has been turned).  This range of 0 to 180 degrees might need to be mapped to a value of, say, 0 to 100 before sending it to the Arduino. 

Controlling an Electric Motor/Fan

 

Circuitry

I decided to build a test rig in order to test various motor/propeller combinations in order to determine the thrust output and the efficiency of different combinations while spinning at different RPMs.  The test rig is made from wood onto which an electric motor was mounted (NOTE:  it is a good idea to attach the propeller only AFTER one is sure that everything is working as expected so that nobody can get hurt).  I attached an ESC (30A) to the motor to which I attached a big 4S (14.8V) battery to power the motor and then attached the control wire's ground and signal wires to the Arduino's ground and digital pin 9 respectively.  Do NOT connect the power wire to the Arduino.

WARNING: These ESCs contain a battery elimination circuit (BEC) for the purpose of providing power from the flight battery to the receiver and thereby eliminating the need for a separate receiver battery.  Consequently, the red power line of the ESC's control wire is hot (it carries 5V at up to 3 amps).  It could be used to power the Arduino, but the Arduino is already getting its power from the host computer's USB port.  

IF YOU CONNECT YOUR ESC'S POWER LINE TO THE ARDUINO'S 5V PIN, YOU STAND A GOOD CHANCE OF BLOWING BOTH YOUR ARDUINO AND THE USB PORT ON YOUR COMPUTER.

 

Arduino Sketch

For the purpose of controlling the ESC, the Arduino's servo library was used.  A couple of things to bear in mind is that servos are controlled by sending a value of 0 to 255 along the control wire.  In order to achieve this, the signal wire on the servo must be connected to a pin on the Arduino that is capable of pulse-width modulation (PWM).  In the case of the Arduino nano that was used here, port 9 will work just fine.  Just to complicate matters a little, we are obviously not controlling a servo, but rather an ESC.  The difference is that, in the case of an ESC, sending a value of 0 to the ESC does NOT usually correspond to the zero-throttle setting of the ESC (it is actually a negative throttle setting).  

Why is this important.  Well, for one thing, when you first power up the ESC's they start up in safe mode in so that the motors do not suddenly run unexpectedly.  Upon powering up the ESC, it proceeds with a chime and then continues to beep to indicate that it is in safe mode.  In order to arm the ESC, the throttle must be reduced to zero at which time the beeping stops.  In order to find this value, the Arduino was powered up and then different values were sent via the serial port monitor to the ESC and it was discovered the a value of 50 armed the ESC - so a signal value of 50 corresponds to zero throttle (this is different for different ESCs) and 255 is full throttle.  Note that this relationship between signal input and motor speed is not a linear one.

 

Processing Sketch

The Processing sketch was modified slightly.  On the one hand, instead of the control being a toggle switch, it is now a potentiometer (called a fader).  This fader can be adjusted from 0 to 180 degrees (or whatever mapping one prefers).  In this case, the value received by the sketch must first be mapped to a range of values that the ESC expects to receive.  it should be noted that TouchOSC will send only integer values to the host computer (no fractional values are used).  If a higher resolution is desired for the fader knob, then the range of values from the fader could be set to be 0 to 1800.

The value of the fader (0 to 180) is then mapped to the range of output signals which is 50 to 255 (as mentioned above).

 

TouchOSC

Once again a custom UI was designed using layout editor.  In this case, it consisted of simply a fader knob which was set to output values in the range of 0 to 180.  Custom layout was uploaded to TouchOSC on the iPhone.

An F550 Hexcopter for Aerial Photography

Since I really liked the agility of my quadcopter, I wanted to keep it that way and, so, for a stable aerial photography platform, I opted for a hexcopter.  I got a great deal on a DJI Flame Wheel F550 combo package which included DJI's NAZA-M v2 flight controller with GPS (which is just killa'), a Zenmuse H3-2D gimbal for a GoPro camera (which I already have) and DJI's landing gear so that the gimbal and camera can be mounted underneath the copter.  All of this should make for a very stable aerial platform.

NAZA-M V2 Flight Controller

NAZA-M V2 Flight Controller

The assembly followed much the same procedure as that for the quadcopter project although the setup of the NAZA took a little while as I wanted to familiarize myself with the assistant software and all the features of the NAZA controller (it will supposedly fly OTB but I wanted to dig into its features).  Also,  since I have an older Spektrum DX7 transmitter, I needed to perform some custom programming in order to allow me to activate the various functions on the NAZA controller (like the Return-To-Home fail-safe option).

The first thing I tested was the GPS-lock mode (commonly referred to as Loiter Mode).  In this mode, the flight controller should not only hold the attitude of the vehicle, but should also keep it at a given location in space - this includes altitude.  In this video, the ability of the F550 to return to its prescribed location and also its ability to takeoff and then land on the same spot is tested.  Before mounting and possibly losing expensive camera equipment, it was necessary to test the ability for the F550 to be easily and steadily controlled and recovered.  As can be seen in the video, the NAZA FC kept the F550 on the spot.  With a good lock on several satellites, the NAZA performs extremely well in this role.  The controller does have a sluggish feel to it.  It flies very well and with much stability and it feels like it.

It is important to realize that these vehicles are unstable by design and would crash very quickly without a controller, (although not so much that it can't be flown manually by a pilot).  Consequently, any computer-augmented control is really a fly-by-wire (actually wireless) design.  Different flight characteristics can be build into the flight controller.  In the case of the NAZA-M, this controller is designed to be smooth and stable and flying the quad with it feels that way.  Switching the controller to manual really gives the F550 a much more aggressive nature.

In a rush to get some aerial photography (AP) going, I decided to mount my GoPro directly to the F550 using one of the standard mounts that came with the camera plus some double-sided tape.  Video was a little choppy, but great to see.

Zenmuse H3-2D Gimbal

Zenmuse H3-2D Gimbal by DJI

Having satisfied myself that the flight controller was working properly, I then proceeded to mount the Zenmuse H3-2D gimbal on which to mount the GoPro.  This Zenmuse is especially designed for the GoPro camera.  It holds it, stabilizes it and allows one to remotely control the camera's shooting as well as controlling the pitch on the camera.  Since the Zenmuse it 2D, it stabilizes in pitch and roll only.  Additionally, as mentioned, the camera can be remotely tilted using the transmitter.  Yaw control of the camera is performed by yawing the vehicle.  When the battery is connected to the vehicle and the gimbal powered, the GoPro will recharge itself.  Additionally, the gimbal provides a video out line which can be used to send the video signal to a video transmitter for real-time viewing at the ground station.

Unfortunately, the Zenmuse does not attach readily to the frame of the F550 (which I found very strange since both are made by DJI - it does, however, attach readily to the frame of the F450).  For now, I simply attached the mounting plate of the gimbal to the underneath of the F550's hub using cable ties.  This worked pretty well except that (because of the wide angle lens of the GoPro) the langing gear appears in the camera's view.  Soon I will 3D print a custom mounting plate for the gimbal that will take care of this.  For now, I will just have to live with the sight of the landing gear.  Initial testing of the Zenmuse gimbal shows that it works very well in stabilizing the camera.

The real test, of course, comes from flying the copter.  Took the F550 up over UCLA for a scenic flight.  Zenmuse results in a beautiful, stable picture.

 

 

Back at the park for another go round and starting to put the F550 through its paces.  Flying it more and more aggressively as I develop a feel for its performance.

 

Return-To-Home (RTH) Failsafe Setting

Before adding too much expensive equipment to the vehicle, I wanted to ensure that the the controller's failsafe feature was enabled, active and working correctly.  The idea here is that in case of an emergency, I can flip a switch on the radio and the RTH function will be activated.  When activated, the vehicle will climb to 20 meters (this can be adjusted) if it is below that altitude, return to the location from where it took off and will land itself gently (assuming sufficient power remains in the battery).  If, when RTF is activated, the vehicle is above 20m in altitude, then it will retain that altitude, fly itself home and land.  In the event that the vehicle flies out of range of the radio and the signal drops, the NAZA will automatically enter RTH mode after 3 seconds of signal loss.  The video below shows a test of the RTH feature.

First Person View (FPV)

The idea behind FPV is that by attaching a video transmitter to the hexcopter, we can turn the GoPro video with a live stream that can be viewed in real-time at the ground station using either a video monitor of a pair of video goggles.  Using this video image, the pilot can control the vehicle well beyond the visible range by, in effect, putting the pilot in the "cockpit" of the vehicle and allowing him to steer from that point-of-view.

MORE SOON...

Velleman 3W Mono Amplifier

Amplifier Components

With the sort of tinkering I get up to, it is often useful to have a small amplifier on hand.  Couldn't resist when I saw this little kit on sale for $10.  It requires just a little soldering (34 connections in all) and it is recommended for this project that you insert a pointed tip into your soldering iron.  We will be soldering components onto a PCB so it is important to do a neat job with the soldering iron being careful not to short-circuit two pins by using too much solder.  The amp consists of a PCB, an IC, five capacitors, a diode and some terminal pins.  Beginning with the IC, the components are added one-by-one to the PCB and soldered into place.  The IC is soldered directly to the PCB and does not require the use of an IC socket.  Care should be taken not to use too much solder as the terminals are very close together and we don't want any short-circuits.  The amp consumer a maximum of 3W of power with corresponds to 500mA at 6V and will accept an input voltage of 6VDC to 15VDC.  I found an old 9V DC power supply supply that delivers 600mA which should be perfect for the job.  I cut the plug off this and soldered it to the power terminals of the amplifier making sure not to cross the positive and negative wires (a cheap multimeter can help with this).

Soldering the components

For the purpose of testing the amplifier, I used the same paper plate speaker that I built in a previous project (actually I had to rebuild the speaker because the old one was looking a little worse for wear).  This allowed for a direct comparison of the speaker performance first without and then with the added 3W amplifier.  Since this is a mono amplifier and because we have only one speaker, when connecting the 3.5mm stereo jack to the input terminals of the amplifier, the left and right channels were first twisted together.  The use of crocodile clips makes it quick and easy to connect the speaker and the audio source to the amplifier.  The insulation on the wires can be easily removed by using a lighter to burn the tips.  I must say, I'm pretty impressed with the results.  The amplifier gave the speaker performance a dramatic boost. In fact so much so that turning the volume up too much caused the speaker the reverberate to the point of distortion.  To be fair, it should also be mentioned that, when hooked up to a proper (higher quality) speaker, the amplifier delivered a clear, crisp sound (substantially better than that of the paper plate speaker - as you might expect) and good volume.  This is a very handy amp that can be used for a whole array of applications and at a (marked down) $10 price point at my nearby Radio Shack, I bought a whole bunch of them - can't go wrong!  Additionally, this project provides a good, quick exercise to brush up of your soldering skills.  This whole project should take no more than 30 minutes from start to finish.

 

 

Gesture Based Controller

HC-SR04 Ultrasonic Ranging Detector

We would like to build a input device for our computer that allows the user to use hand gestures in order to command a computer program.  We begin by experimenting with a ultrasonic distance sensor in order to better understand its operating characteristics.  The ultrasonic sensor will form the basis for a measuring device that will be used to locate the user's hand in 3D space.  Most Arduino projects that require the use of an ultrasonic sensor will generally point you in the direction of Parallax's Ping Ultrasonic Sensor.  These sensors tend to be pricey (about $25 to $30) and so I searched for a cheap replacement.  In the end, I found a HC-SR04 Ranging Detector by SainSmart these are available for $2 to $5 at Amazon.com.  So way, way, cheaper, but the real question is how well do they work?  One point to note is that while the Ping sensor has three connections (Vcc, SIG, GND), the HC-SR04

requires four connections (Vcc, Trig, Echo, GND).  This requires just a slight modification of the example sketch for the Ping sensor from the Arduino IDE, viz. that separate pins are now to be used for the triggering and the reading of the sensor rather than using one pin that was switched between being used for OUTPUT versus INPUT.  Additionally, I abstracted the reading of a distance measurement by creating a function called getData(trigPin, echoPin) which facilitates easy reuse of the code for the reading of multiple sensors.  Distance measurements are returned in centimeters only.

Wiring Setup for HC-SR04

So, in order to get started, we build a simple sensor by connecting an Arduino Nano to a three ultrasonic sensors and run a simple sketch to log the sensor data by outputting it to the serial port.  We use three sensors so that we can test for the consistency and variations of each sensor thereby allowing us to determine the accuracy of the HC-SR04 ranging sensor.

More Soon...