Posts with «accelerometer» label

Gesture Recognition / Pattern Recognition.

I have published earlier two projects:

First one was created for Arduino UNO (AtMega328), and second project is for Leonardo (AtMega32u4).  They are devoted to Voice Recognition. Now it’s about time for a Gesture Recognition. I’m referring to this two ancient projects, because, as you probably already noticed, they share same subject: RECOGNITION. Or pattern recognition, if we step aside for a moment from the nature of the data to be processed. And again, I choose same method for basic algorithm – CROSS-CORRELATION. This project is less complex, linear movement is just 1D curve (actually, three 1D curves), plus no needs for FFT this time.

New software submodule, which is directly related to  DSP – FIR Band Pass Filter. Actually, just FIR, as changing coefficient in the kernel you may turn it’s into HPF, LPF, BPF or BSF. Order of the filter is also flexible, so I didn’t tested it above 9-th, there  could be some issues with 8-bit integers math.


Build with  a sensor:

MMA736xL 3-Axis Accelerometer with Voltage Regulator

To track a movement in 3D, there are 3 analog outputs to be sampled: X, Y and Z consequently. I plugged-in the sensor board directly to Arduino UNO analog inputs, configuring AN0 and AN1 as the power rails for the board, accounting very low current consumption – 0.5 mA or so.

Software Submodules:

  1. Sampling.
  2. Decimation.
  3. Filtering.
  4. Recording or Comparing.
  5. Making a Decision, Yes or No.

Part 1 & 2, Sampling – Decimation.

 static uint8_t ch_Numb = 0;
 static uint8_t nb_Cycl = 0;
 static int16_t sm_Dcm[CHANNELS] = { 0}; // Summ & Decimation X

 int16_t temp = ADCH; 
 temp -= adc_Oft;

 digitalWrite( 9, HIGH);
 if( ch_Numb == 0 ) temp -= 30; // G-Force compensation

 sm_Dcm[ch_Numb++] += temp; // Rotate MUX, monitoring all inputs for VOX level.

 if ( ch_Numb >= CHANNELS ) 
 ch_Numb = 0;
 nb_Cycl++; // Freq. ADC reading / CHANNELS
 ADMUX &= 0xF8;
 ADMUX |= (ch_Numb + 3); // PINS A3, A4 & A5; A2 = 3.3V, A0 = 5V; A1 = Gnd. 

 if ((abs(temp) > trigger) && (!capture) && (!process))
 capture = 1;
 n_sampl = 0;
 nb_Cycl = 0;
 for ( uint8_t y = 0; y < CHANNELS; y++) sm_Dcm[y] = 0;
 digitalWrite( 13, HIGH);

 if ((capture) && (nb_Cycl >= DECIMATN))
 for ( uint8_t y = 0; y < CHANNELS; y++) {
 acl_input[y][n_sampl] = sm_Dcm[y] / DECIMATN; 
 sm_Dcm[y] = 0;
 nb_Cycl = 0;

 if ( n_sampl >= BUF_SIZE )
 process = 1; 
 capture = 0;
 n_sampl = 0; // process = 1 !!!
 nb_Cycl = 0;
 digitalWrite( 13, LOW );
 digitalWrite( 9, LOW );

There are 3 analog inputs, and only 1 ADC presents on Arduino. Of course, it’s require some efforts, channels are sampled one after another in sequence. Voltage or signals magnitude is monitored continuously,  but data isn’t stored or processed untill level becomes higher than pre-set threshold, or trigger level, I called it’s MOX, using analogy with VOX system, or voice activated. Here – MOvement activated -);

There is a constant “30″ is subtracted from Z samples, as board outputs some signal on this axis, even it is laying flat on the desk. G-Force is responsible for such abnormality. According to data sheet of the sensor, frequency response is quite high for this application, 400 Hz, and sampling rate has to be 800 Hz in order to avoid aliasing. (He is mostly known for having discovered, independently of others (e.g. Edmund Whittaker, Harry Nyquist, Claude Shannon), the sampling theorem in 1933.).

Multiplying by 3 = 2 400 Hz. Too high for Arduino 2K memory size in the first, and it’s not necessary for normal human beings to have such high sampling rate in the second. Here is comes PART 2.

Decimation factor equals 32, is reducing samples rate down to ~25 Hz. Nothing sophisticated, integral sum of 32 samples divided by 32 is transfered to acl_input array. Length of input array and decimation factor could be adjusted in different proportions, limiting parameters to be considered:

  • Memory size of the Arduino board, both RAM & EEPROM;
  • Length of the Pass-Move in seconds;
  • Speed of the movement.

Part 2 & 3. Filtering and Cross-Correlation.

 Filtering serves mainly as  pre-processing stage for Cross-Correlation (C-C) or Pattern Recognition algorithm.  C-C algorithm works significantly more sensitive after performing “transition stressing” and removing a DC bias from the input data pull. (Some constant level voltage always presents if accelerometer is not placed perfectly horizontally, due gravity force).  Simple High Pass Filter usually is enough to solve a problem.

Note: I used a name “transition stressing” instead of commonly known “edge enhancement” as IMHO, original term is misleading in the context of this project, simply because there is no images, where such term makes more sense, and plus there is only one dimension.

But there is one nuance, sensitivity becomes ENORMOUSLY high. If you read a paragraph above, than you already know, that data rate is 25 Hz, or 40 milliseconds per samples. Having 128 samples in the input array, length of the pass-Move = 128 x 40 = 5.120 milliseconds, or ~5 seconds. I just can’t repeat a movement two times, that is exactly synchronous down to 40 milliseconds over 5 seconds time frame !  In 3D space ! I’m 100 % sure, NOBODY can’t.

 Why than do a “transition stressing” at all, you may ask. For fun, a-hh, for research of course -);

There is a switch in software “h” – to turn off / on filtering. You may turn filtering off if you can’t repeat pass-move correctly. Just make sure you do a “recording” and “comparing” with the same filters settings !

 I decided to implement Band Pass Filtering instead of High Pass. And with longer kernel – 9, (Voice Recognition using kernel 3/per axis, 3×3 overall).  It stretches transition over ~6 frames, or 240 milliseconds on both sides.

Full List Of Commands:

  1. if (in_Byte == ‘x’) { // INPUT ADC DATA
  2. if (in_Byte == ‘h’) { // HPF – BPF
  3. if (in_Byte == ‘r’) { // RECORD TO EEPROM
  4. if (in_Byte == ‘p’) { // PLAY FROM EEPROM
  5. if (in_Byte == ‘c’) { // PRINT CORRELATION RESULTS REPORT

 Should I say, that LED “capture in progress” must be off before you send an “r”?

Ok, here is quick manual.

  1. Place a board on the desk. Send “h” to shout-down a filter.
  2. Printing input data with “x”, you may check if voltage on X, Y or Z inputs is over trigger level, in case if LED is always “ON”.
  3. Reposition a board, or change a constant “30″ to appropriate value, depends on the sensitivity of your accelerometer. Changing trigger value is also an option, to make a LED switch off.
  4. If LED is off, good, than tip slightly a sensor to trigger a capture. Your objective is get close to “0″ in all 3 arrays of data. Print with “x” whenever new capture happened (LED indicates this).
  5. Now move a board in space (3-4 sec.) and place back. Check whatever been captured with “x”. The higher  values are in the arrays, the better.
  6. After you practice for awhile, and able to fill up all 3 array in one “high pilotage” single move, wait until LED is off and go to step 7.
  7. Than send “r”. Move a board AND REMEMBER how you moved it. Wait until LED is off.
  8. Send “c”. Now make exactly the same movement and see your results!
  9. You succeeded? “BINGO !” , now turn filtering ON, and check your coordination capability again !

Link to download an Arduino UNO sketch:  Gesture Recognition.

Enjoy, and Happy Holiday !

Please, be advised, that alcohol may reduce your ability to repeat a strong pass-MOVE -): 

 Updates. 25 Dec. 2013

 I’ve been thinking, how to re-design my software into full blown patter recognizer. What I mean, my first “prototype” works on “stop-run-stop” principle, and that may helps a lot to understand a theory behind  C-C, the same time it excludes a great number of applications, where process couldn’t be stopped.

 For example, if I’d like to track / identify specific abnormality in the heart beating pattern, I can’t just say “heart, please stop for 5 sec., than run ones, and stop again until I finished my pattern matching subroutine…”

 Exactly, software has to be REAL-TIME. O’K, let’s check into timing resources, because real-time application requires matching subroutine to be executed each time new sample stored. In this particular case, triplet of new samples, X, Y, Z. Measured time required to run C-C on 128 x 3 = 384 samples (pin 8),  close to 1 milliseconds. Theoretically, there is enough time to get sampling rate up to 1 kHz.

 What about filtering? Filtering has to be real-time as well, but there is no problem with it, just declare a history array as [3][N] and keep it’s as a static.  I transfer a call to this subroutine inside a sampling one, and here how new function looks like :

 static uint8_t ch_Numb = 0;
 static uint8_t nb_Cycl = 0;
 static int16_t sm_Dcm[CHANNELS] = { 0}; // Summ & Decimation X
 static int8_t hist_f8t[CHANNELS][HPF_KRNL] = { 0};

 int16_t temp = ADCH; 
 temp -= adc_Oft;

 digitalWrite( 9, HIGH);
 sm_Dcm[ch_Numb++] += temp; // Rotate MUX, monitoring all inputs for VOX level.

 if ( ch_Numb >= CHANNELS ) 
 ch_Numb = 0;
 nb_Cycl++; // Freq. ADC reading / CHANNELS
 ADMUX &= 0xF8;
 ADMUX |= (ch_Numb + 3); // PINS A3, A4 & A5; A2 = 3.3V, A0 = 5V; A1 = Gnd. 

 if (nb_Cycl >= DECIMATN)
 for ( uint8_t y = 0; y < CHANNELS; y++) {
 int8_t tempr = sm_Dcm[y] / DECIMATN;

 acl_input[y][n_sampl] = HPFilter( tempr, fir_f8t, HPF_KRNL, hist_f8t[y]);
 sm_Dcm[y] = 0;

 process = 1; 
 nb_Cycl = 0;
 if ( n_sampl >= BUF_SIZE ) n_sampl = 0;
 digitalWrite( 9, LOW );

Oscilloscope shows on pin 9, that one pulse out of 32 is wider, about 100 usec.. Though, there is plenty of time, more than necessary.   I also changed behavior of the for-loops, turned them into circular buffer style:

address = 0;
 for ( uint8_t y = 0; y < CHANNELS; y++) {
 long summ_c = 0; 
 for ( uint16_t i = 0, indx_1 = n_sampl; i < BUF_SIZE; i++ , indx_1++) { 
 uint16_t indx_2 = (indx_1 & BUF_MASK); 
 while(EECR & (1<<EEPE));
 EEAR = address;
 EECR |= (1<<EERE);
 summ_c += (((int8_t) EEDR) * acl_input[y][indx_2]);
 if ( ++address >= 1024 ) address = 0; 

Be aware, that printing input array with “x” twice in a row, would show a second copy shifted up.

Last things, new quick manual:

  1. Place a board on the desk. Send “h” to shout-down a filter.
  2. Printing input data with “x”. you may check if voltage on X, Y or Z inputs is over trigger level, in case if LED is always “ON”.   All values for immovable board must be “0″. (due BPF).
  3. Now move a board in space (3-4 sec.) and place back. Check whatever been captured with “x”. The higher  values are in the arrays, the better.
  4. After you practice for awhile, and able to fill up all 3 array in one “high pilotage” single move, wait a few seconds.
  5. Move a board AND REMEMBER how you moved it. Wait until LED is off. 
  6. Than send “r”. Recording takes already captured samples , 5 sec before you send “r” !
  7. Send “c”. Now make exactly the same movement and see your results!
  8. Results also shown by LED, it lights up for 1 sec, whenever match pattern registered.

How to test a software, w/o accelerometer:

Connect pin AN3 and AN4 to ground. Using jumper wire, apply +3.3V to AN5. Wait for a few seconds, than disconnect a wire. Software would register a single transition +3.3V to +0.0V, and if you send “x” immideately, you should see BPF-ed version of this transition:

Input - 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
 0 0 0 0 0 0 9 25 36 57 18 -57 -46 -25 -16 0 
 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0

Now, connect a voltage to AN5, wait ~5 sec., disconect a wire and send “r”.  Print out with “p” whatever been captured, data should be approximately same as shown above. Now whenever you connect, and than disconnect a wire to AN5, LED should lights up, after small delay.
Link to download an Arduino UNO sketch:  Gesture Recognition-2.

DIY Airbag, explosions included

Your car’s airbag is one of the major engineering accomplishments of the auto industry. In an accident, a whole host of processes must take place in sequence to keep your face from slamming into the steering wheel, and  everything must happen in just a fraction of a second. [Steve] over at Make thought it would be a cool idea to discover what actually goes in to saving a life with an airbag and decided to build his own.

The electronics of the build consisted of an accelerometer and an Arduino. A lot of research, development, and experimentation has gone into the algorithms that trigger airbags, but [Steve] decided to keep things simple: when a sudden acceleration is detected, set off a small charge of black powder.

The airbag itself is ripstop nylon reinforced with canvas, contained in a small wooded box fitted with hinged doors. All these components are put on wheeled aluminum test rig, manned with a honeydew melon crash test dummy, and pulled into a short wall at a few miles per hour.

Despite [Steve] not putting hundreds of thousands of man hours into the development of his airbag – unlike the ones you’ll find in your steering column – his device actually worked pretty well. While not a complete success, he did manage to come up with something that both looks and acts like the familiar device that has saved countless lives.

Filed under: Arduino Hacks, transportation hacks

Rocketduino, for high-G, high altitude logging

Although the thrill of launching rockets is usually found in their safe decent back to Earth, eventually you’re going to want some data from your flight. Everything from barometric pressure, GPS logging, and acceleration data is a useful thing to have, especially if you’re trying to perfect your craft. [zortness] over on reddit created a data logging board created especially for amateur rocketry, a fabulous piece of work that stands up to the rigors of going very fast and very high.

The design of the board is a shield for the Arduino Mega and Due, and comes with enough sensors for over-analyzing any rocket flight. The GPS logs location and altitude at 66Hz, two accelerometers measure up to 55 G. Barometric, temperature, and compass sensors tell the ground station all the data they would need to know over a ZigBee 900MHz radio link.

Because this is an Arduino, setting up flight events such as deploying the main and drogue chutes are as easy as uploading a bit of code. [zortness] built this for a 4″ diameter rocket, but he says it might fit in a 3″ rocket. We just can’t wait to see some videos of it in action.

Filed under: Arduino Hacks

motorcontroller board [problem]


I am trying to build a segway, I know how I am going to make it, but I have been struggling to get the motorcontroller to work for days now.

I attached an accelerometer and a motorcontroller to an arduino uno. When I tilt the accelerometer 2 indicatorlights on the motorcontroller change, so this signal must be right. But when I measure the voltage at the motor output I get only 10-60 mV.

I tried using more and using less Volt (5-15 V) on the m.c. board itself. (I attached it to an old model train transformator)

Please Help


read more

Cornell Students Create Virtual Archery Game

Inspired by the bow-and-arrow use in Legend of Zelda games, Cornell students Mohamed Abdellatif and Michael Ross created a Virtual Archery game as their Cornell University ECE 4760 Final Project.

Fantastic programming makes this Arduino gaming device something special

The hardware that went into this Arduino gaming console is just fine. But the coding that produced this game called Twisted SNAKE is beyond compare. [Rodot] has programmed several games for the hardware, which uses an Arduino, 160×168 TFT screen, a 3 axis accelerometer, and two input buttons. If you’re interested, there is a forum thread in which he talks a bit more about the hardware design. But you’re not going to want to pass up either of the two videos embedded after the break.

The first clip shows off a bouncing-ball platforming game. The accelerometer moves the ball back and forth, and the top scrolling level brings more ledges into play. This in itself is a great game. But the Twisted SNAKE game shown off in the second video makes our own ARM-based Snake game look like a 3-year-old programmed it. [Rodot] filled up all of the program memory of the ATmega328 chip to  make this happen. There’s a menu system which allows for color themes and difficulty selection. The game play itself lets the snake travel anywhere it wishes with the tail following behind in graceful curves. Wow!

Filed under: arduino hacks, handhelds hacks

Accelerometer for circuits course?

One of the people that I asked to look over the course notes and give me suggestions suggested another lab that would likely appeal to bioengineers:

another cheap experiment, accelerometers from Sparkfun to measure gait patterns or detect falls.  If really ambitious, you can teach chaos theory here with analyzing chaos levels in gait patterns—they are different for men and women.

I’ve used accelerometers before, both the analog output ADXL335 and the I2C MQA8452Q. The ADXL335 breakout board was from Adafruit Industries, the MQA8452Q from Sparkfun.  Although I personally prefer the I2C interface, since it takes up only 2 Arduino pins, programming is outside the scope of this class.

This lab sounds like fun, and it would be good for the bioengineers to think of accelerometers as cheap sensors that are easily used, rather than as magic that comes in cell phones, I’m not sure how we would get a circuits lab out of this. Even the analog-output accelerometer just needs to have its XYZ pins connected to analog inputs on the Arduino.  Anything interesting you do with the accelerometer is in either the mechanical mounting or in the software analyzing the data, not in electronic circuits.

We have several constraints in selecting labs for this circuits course:

  • Lab must teach something useful to the students.
  • Lab must seem interesting (or at least useful) to bioengineering students.
  • Lab must not be dangerous (either to students or to equipment).
  • Lab must be doable in one 3-hour lab session (we can afford at most 2 labs that are 2-session labs).
  • Lab cannot require students to be able to program computers.
  • Lab cannot require knowledge of electronics beyond what is taught in the course.
  • Lab should support the teaching of traditional linear circuits.
  • Lab should involve student design and not just analysis of existing designs.

The accelerometer lab fails on two points: any design component would have to be software and there is no support for teaching linear circuits in the lab.  That’s too bad, because it is otherwise a cool lab idea.

Filed under: Accelerometer, Circuits course Tagged: accelerometer, Arduino, bioengineering, circuits, course design

Printing and programming a self-balancer

The Hackaday staff isn’t in agreement on 3d printers. Some of us are very enthusiastic, some are indifferent, and some wonder what if they’re as widely useful as the hype makes them sound. But we think [Jason Dorweiler's] self balancing robot is as strong a case as any that 3d printing should be for everyone!

Don’t get us wrong. We love the robot project just for being a cool self-balancer. Seeing the thing stand on its own (video after the break) using an Arduino with accelerometer and gyroscope sensors is pure win. But whenever we see these we always think of all the mechanical fabrication that goes into it. But look at the thing. It’s just printed parts and some wooden dowels! How easy is that?

Sure, sure, you’ve got to have access to the printer, it needs to be well calibrated, and then you’ve got to make the designs to be printed out. But these hurdles are getting easier to overcome every day. After all, there’s no shortage of people to befriend who want nothing more than to show off their Makerbot/RepRap/etc.

Filed under: robots hacks

Space experiments for everyone: the ArduSat project

ArduSat, which stands for “Arduino satellite”, is a recently kickstarted project that aims at developing an open platform usable to emulate space scientists:

Once launched, the ArduSat will be the first open platform allowing the general public to design and run their own space-based applications, games and experiments, steer the onboard cameras to take pictures on-demand, and even broadcast personalized messages back to Earth.

ArduSat will be equipped with several sensors (such as cameras, gyros, accelerometers, GPS and more) packed inside a small cube (the side will be approximately 10 cm long) that can be accessed through a set of Arduinos.

Once in orbit, the ArduSat will be accessible from the ground to flash the required firmware for the experiments and for getting back all the collected information. People interested in performing space experiments will have access to a ground replica of ArduSat explotable to test and debug their code before the actual deployment.

The project is very ambitious, and it is expected that such an open accessible space platform will have a considerable impact on how simple space experiments will be carried out in the forthcoming years, in the case of fundraising success.

You may find the Kickstarter page of the project here.

[Via: Hack A Day and Kickstarter]

Some advances in aerial vehicles: bat-inspired smart wings

Researchers from Centro de Automática y Robótica (Universidad Politécnica de Madrid) and from Brown University carried out a very deep research about the specific behavior of bat flight, whose ultimate goal is to replicate the capabilities of bat’s wings by means of an ad-hoc designed micro aerial vehicle (MAV).

From the home page of the project:

[...] this research is oriented towards the development of a biological inspired bat robot platform, that allows to reproduce the amazing maneuverability of these flying mammals. The highly maneuverability is achieved by reproducing the flapping and morphing capabilities of their wing-skeleton structure. This structure is composed by several joints and a membrane that generates the required lift forces to fly.

To mimmic the muscular system that moves the joints of the wing-bones, Shape Memory Alloys (SMA) NiTi wires are used as artificial-muscles. Several challenges in controlling this SMA-based actuation system are regarded in this research.

A lot of research work has already been carried out (see here for a list of publications) and a bat-like MAV prototype has been designed and implemented to both evaluate and validate the research outcomes. Among the other stuff, the core onboard electronic is made up of an arduino-based board, an IMU, a radio transceiver and a rechargeable LiPo battery.

More details on this project can be found here.

[Via: BaTboT project homepage]

Arduino Blog 06 Jun 13:52