[M. Eric Carr] built this a long time ago as his Senior Project for EET480. It’s an electronic version of the ball-in-maze game. We’ve embedded this video after the break for your convenience.

The game has just one input; an accelerometer. If you’re having trouble visualizing the game, it works the same as this Android-based version, but replaces the physical maze and marble with a virtual maze on the graphic LCD screen. This has huge implications. Instead of just recreating the maze on the screen, [Eric] designed a multi-screen world, complete with warp blocks, which adds difficulty to  finding a solution. It also means that multiple different mazes can be played if you get tired of playing the same level.

This game also features music. A separate PIC microcontroller uses PWM to push out the 8-bit sound heard in the video. From the YouTube comments we learned that [Eric] didn’t write the music himself, but we still appreciate the playback quality he achieves with his hardware.

[via Reddit]

So we saw this tip come in and thought–oh, another POV device. We watched the video (embedded after the break), took a sip of coffee, then almost sprayed the beverage all over the computer when we realized that this uses a diy sensor to synchronize the POV image.

[Ch00f] came up with the idea for the sensor after seeing a similar implementation on a commercial POV toy. Instead of using a proper accelerometer to sense the motion, the toy uses a plastic bead in a channel. When you move the body of the toy the bead rolls to one end or the other, covering or exposing a reflective sensor.

A similar sensor is used here. A drinking straw servers as the channel, with a paper-covered nylon screw as the bead. [Ch00f] cut a window in the bottom of the straw for his reflective sensor, then sealed each end with a wad of paper.

This method works, but not as well as he had hoped. It seems the refresh rate and timing of the particular sensor he’s using is rather poor. If it were replaced with one that is simply and IR LED and phototransistor (like the sensors from [Jack's] last video) he thinks it would work a lot better.

via Buildlounge.

[Lizzie] from LustLab sent in her Ball of Dub that turns a few accelerometer and a digital audio workstation and turns everything into an aural experience of wubs and dubs. The Ball of Dub can turn just about anything into dubstep, and does so with a fairly interesting user interface.

There isn’t a build log for the Ball of Dub, but  the folks at LustLab did send in a basic overview of her project. Inside the ball, there’s a Razor IMU from Sparkfun that is attached to the ever-popular XBee wireless transceiver. A tiny program on an Arduino calibrates the gyroscope and accelerometer and sends that data to the DAW at 50Hz.

The host computer is running Renoise, a very popular tracker that can accept MIDI and OSC input. A Processing app parses the ball spin, free fall and impact, averages them over a period of time, and pipes that into the OSC input of Renoise. In [Lizzie]‘s video, the ball spin is sent to a low-pass filter on the baseline track, and the average impact is applied to the vocal track.

This isn’t the first time we’ve seen some fairly strange ways to modulate wub; we saw real instruments covering Skrillex earlier this month. The Ball of Dub wins in the simplicity department, though.

Make sure your health insurance premiums are all paid up; if you decide to replicate this project you may need it. [Corey], [Kris], and [Jess] built their own go cart which is controlled with a Wii remote. The website has a poor navigation scheme, but if you hover over the horizontal menu bar you can get quite a bit of information about the build.

The cart has two motors which use a chain to drive each of the rear wheels. A pair of H-bridge controllers let the Arduino interface with them. It’s also has a Bluetooth module that makes it a snap to pull accelerometer data from the Wii remote. The front end looks like it uses rack and pinion steering, but you won’t find a pinion or a steering column. Instead, a linear actuator is mounted parallel to the rack, moving it back and forth at the command of the Arduino.

We can’t help but think back to silent movies where the steering wheel comes loose in the middle of a car chase. See if you get the same image while watching the demo after the break. This doesn’t seem quite as dangerous as adding remote control to a full-sized automobile, but we’ve played MarioKart Wii before and know how lousy the accelerator performance can be. Hopefully the firmware kills the motors if the batteries in the controller die.

This odd-looking ball can automatically take a panoramic image whenever you throw it up into the air. Seriously, that’s then entire set of operating instructions for the device. Inside, a 3D printed frame hosts an array of 36 cellphone cameras, each capable of taking a two megapixel image. Also included is an accelerometer. When it senses the change in momentum associated with the apex of its vertical trajectory it snaps an image with all of the cameras at the same time. The result is a spherical image with no obstructions-like a tripod or other support mechanism. The images are automatically stitched together and displayed on a computer which allows the user to pan and zoom.

The whole story is told in the video after the break. The example images shown are quite good, although there are a few artifacts where the segments meet. Most notably, color variances between the images captured by different CCD modules. We’d image that this can be fixed automatically in software if a talented programmer were willing to put in the time. The thing about spherical photos is that methods using post processing to unwrap an image always have some distortion to them. With that in mind, we think the ball camera is as good a solution as we’ve seen.

[Thanks Gregory and Hans]

Well, if you hadn’t noticed the news there has been a little bit of a shakeup on the east coast. I just arrived home after being evacuated due to a 30 second rumble the likes of which has not been felt on the east coast in something like 114 years. In lieu of the not so devastating but earth shaking event we thought we’d put together a few earthquake related links for you.

Earthquake-proof Wine Rack

First off instructables user [jofish] has a quick remedy if earthquakes are constantly destroying all the wine on your wine rack. He researched some existing commercial products and simply copied them by stapling cheap O rings to the front of the rack. We assume the back of the wine rack is secured to the wall as well.

Vertical Seismometer

Next up is a vertical seismometer from [Mike] over at mikesense.com. This was in response to a slightly more threatening 7.2 earthquake he experienced in Baja California last year. A vertical seismometer measures the movement of a weight either electronically or mechanically, and then damps the motion of the oscillation by a magnet or some other means. This particular design is known as the AS-1 developed by [Jeff Batten]. Matt’s page has links to everything you’d need to know including build videos.

Predict Seismic Activity with Hard Drives

If you are looking for some non-conventional ways of tracking seismic activity we have a pair of articles that detail earthquake tracking using your disk drive’s accelerometer. [Michael Stadler] realized the potential for all these sensors and released a program that creates a peer-to-peer network compiling data from the sensors. We are not too comfortable with the prospect of somebody tracking every time we drop or kick (or drop-kick) our laptops but 2500 users in Asia downloaded the software in ’06. The second article details an effort lead by IBM to monitor the fixed hard drives in server racks which generally remain far more stationary.

Simple DIY Earthquake Simulator

Finally for those of you who want to cause (miniature) earthquakes, we dug up this MTU project using plywood, an electric drill, rubber bands and some bearings to fabricate a DIY shake table (PDF warning). We are sure there are tons of improvements that can be made but this is a pretty fun project if you have a bunch of CNC parts lying around (we wish we did).

[Maayan Migdal] wrote in to share a really cool drum kit he constructed that has one special twist – no drums at all. Using a simple MIDI device and an Arduino, his “Air Drums” look pretty sweet.

The hack makes use of a pair of garden rakes, which serve as his drum sticks. The rakes were cut down and modified to allow the addition of accelerometers and some USB cables. The left stick contains a single accelerometer for registering hi-hat hits, while the right stick is armed with a pair of the modules, which are used to trigger snare and crash symbol strikes. He modified a pair of sandals to fit better while drumming before adding a sensor to each shoe. The left sandal contains an accelerometer to register bass drum hits, while the right shoe uses a light sensor to simulate the use of a hi-hat pedal.

We think that the results are awesome, but feel free to check out the video below to see what we mean. If Guitar Hero wasn’t dead in the water on hiatus, we think this sort of setup would make a great replacement for the flimsy drum set that comes with the game.

[Petter] built himself a DIY Segway out of a couple of cheap electric scooters. We’ve seen a couple of very nice Segway builds in the past like the all analog Segway, or the creepy walking version, [Petter]‘s Segway build seems like it would be a useful human transport device.

The motors, chains, gears, and wheels are scavenged from a pair of electric scooters. Steering left and right is accomplished by tilting the handlebars left and right. The handlebars themselves are attached to the joint at a base that allows them to be taken on and off. We’re thinking this would be great for throwing a [Petter]‘s Segway in the trunk of a car – a design feature the original Segway doesn’t have.

The electronics of the project are based around an ATMega168 that reads data from an accelerometer and gyroscope. The motors are controlled by two H-bridges and are powered by two 12 V lead batteries wired in series. We’re not sure how long the batteries will last in a real-world situation, but [Petter]‘s build seems to go fast enough.

Check out the demo video below:

[Ragnar] and his friends were getting tired of the usual Friday night drinking games. They went through dice games, card game, and TV show based games before [Ragnar] retired to his workbench to whip up an electronic solution that would randomly pick a player and assign a certain number of drinks. That’s a novelty at first but not really a game. After letting the project sit for some time he revisited it and came up with a more advanced solution. The box seen above is his second attempt; a game called pass the bomb.

The case is a black aluminum project box. The user interface includes a 20×4 character LCD and three buttons. Check the video after the break for the menu system as well as english translations. Once turned on you can set the sensitivity for the accelerometer and choose the game. For now, pass the bomb is the only option – a game that counts down to a digital explosion. Carefully pass the device to the next player without upsetting the accelerometer or it’ll go BOOM and you’ll have to drink.

We’d prefer to enjoy a nice frothy beverage rather than searching for reasons to throw back some shots, but whatever floats your boat.

If you’ve ever wondered about the use of or theory behind or the use of accelerometers, this tutorial by Love Electronics is a very good resource. In this article, Love takes one through how to hook up an ADXL345 accelerometer and use it with a Netduino processor. Before the subject of hooking everything up is broached, a very good discussion is given on the general theory and operation of accelerometers.

Information is given about installing all the required software and libraries. Additionally, a mini tutorial about writing a “hello” application using the .NET framework is given. Finally, the application gives the [Windows Presentation Foundation] tools necessary to visualize the raw data that the Netduino produces.

One could really start using this processor and accelerometer from scratch with this tutorial and some basic electronics knowledge.  This could add a great new feature to your next robot or allow measurement that couldn’t be done with simpler sensors.

72 hours of hacking came to a head with the completion of the Red Bull Creation. This years challenge was to build something out of junk that moves a human. It’s hard to pull all the aspects of the event together in one place, so here’s some links you’ll want to check out if you weren’t able to attend.

Tech Crunch has an overview of all the event winners. One of our favorites is pictured above. The spinning see-saw is not your average playground toy. Its built-in accelerometer waits for the forces to peak, then snaps a picture for later enjoyment. Techshop, a San Francisco hackerspace, took the team prize for their work on it. Don’t miss the video after the break

The overall winner was a team from Minneapolis called 1.21 Jigawatts. They produced a human-sized hamster wheel that pulled a small follower behind it. As you walk, the follower prints incoming text messages on the sidewalk, kind of like the chalkbot. We searched around for video of it, the best we could find is this one.

[Thanks NeonDion]

[PJ Allen] built a meter to display gravitation force in an easy to read way. Good thing it’s easy to read, because he’s added it to the dashboard of his car. That way he gets instant feedback when he puts the pedal to the metal. We’re hoping this encourages safe driving practices. But since it appears that not only is he watching the meter while he drives, he’s also holding a camera at the same time, we’d say this makes him a menace on the road.

But we do like the hardware concept. He used five Red/Green LEDs to show what the accelerometer is sensing. A green display reflects acceleration, while a red display shows deceleration. Inside the project box you’ll find a Parallax 2-axis accelerometer and an SX28 micrcontroller. This is an 8-bit Parallax chip family that was discontinued a few years back.

While the Segway enjoyed a few years of fame before falling off the radar, [Marcelo Fornaso] is hoping his creation has quite a bit more staying power. Inspired by the Segway’s ability to balance itself, he started thinking about how the concept could be improved. He felt that one of the Segway’s shortcomings arose out of the fact that the base platform was rigid and required the user to lean back and forth outside the device’s frame in order to turn it. He thought that this made the riding experience uncomfortable as well as risked causing the rider to fall over.

His creation, the Tilto, aims to both improve on the turning ability of the Segway while eliminating the need for handlebars. Based on a tilting mountain board design he had been tossing around for a while, the Tilto uses accelerometers and gyros to keep its balance, much like the Segway. His goal was to keep the vehicle balanced while traveling forwards and backwards, but also allowing the device to tilt from side to side without tipping over. This design keeps the rider mostly upright, allowing the user to direct the vehicle by leaning much like you would on a bicycle.

As you can see in the video below, the Tilto works pretty well, even in its prototype form.

Finally, a people mover that lets us get our gangsta lean on!

[Pcdevltd] pulled an all-nighter to get his first Android Developer Kit project up and running. Basing the project off of the example that Google used when unveiling the new accessory development hardware, he set to work controlling a marble labyrinth game using his smart phone. What began at 7pm was wrapped up by 5am to produce the results seen in the video after the break.

These ball mazes use two knobs to pivot the playing surface, changing gravity’s pull on the ball to get it to go where you want. [Pcdevltd] pulled off the bottom on his labyrinth and installed two small servo motors. These connect to the Android Open Accessory Development Kit via a small cable. Connect that to the phone and you can then use the internal accelerometer to play the game. If you have an Android phone and an Arduino this should be pretty easy to replicate since we know you can already use the ADK with Arduino. Get to work on your own projects and don’t forget to send us a link to your project log.

[Thanks David]

A little while back I attended the largest east coast gathering of folks from the ever popular social news site, Reddit.com. Those of you familiar with Reddit already know that it is all about link aggregation. Users post links to interesting websites and material, and can then vote up or vote down content based on interest or relevance. Through the magical site algorithms original and interesting content is, as implied, aggregated up to the front page.  The whimsical nature of this big DC event lead many people to furnish signs of all types based on the culture of the site, internet memes, etc… The signs that really caught my attention were based primarily on the stylistic site layout, blowing up mail icons and other Reddit specific graphics.

The concept of using site graphics gave me the idea of being able to personally vote up or down other peoples’ signs. It was far too easy to just make a cardboard arrow, and I don’t have a color printer. I happened to have a shelved coffee table project involving orange and blue LEDs. Same colors as the arrows! Sweet. To make this project work I would have to work entirely from my project pile, there simply was no time to order anything from the internet. I managed to crank out a functional up/down voting sign in 3 days leading up to the gathering (and the morning of), here is what I did:

What I Had Around The House:

• Orange and Blue LEDs – 124 each. Extras from a coffee table project that is currently shelved.
• Breadboard – I have tons of this stuff lying around, surface mount friendly square flavor!
• MOSFETs – Another shelved project, an electric motor controller so these could handle many amps.
• Resistors – I only had SMD resistors in the values I needed, this turned out to be a huge hassle.
• Arduino Nano – I keep this one kicking around project free for just such an occasion.
• Trippe Axis I2C Accelerometer – I built a little breakout board and toaster oven soldered the thing a long long time ago. We only really need one of the three axises for this project.
• SPDT Switch.
• Voltage Regulator – The Arduino could technically make enough 5v to power everything, I decided to not risk it though.
• A knife worthy of foam core board, I used a pen knife.
• Tweezers, solder, soldering iron, wire, a steady hand, patience.

Stuff I had to get:

• Poster Board – Craft store!
• Hot Glue – Craft store!
• 9V battery clips – This was a snap decision, I got these the day of the event!

Layout The LEDs:

Now its time to recreate the pixel graphics. The site has a very simple low res graphics, below is a close up of the activated voting buttons.

Since I have far more LEDs than sense, I decided to place an LED at the intersections of the pixels.  All these great ideas on how to diffuse the light were tossed around,  wax paper and what not, they would have looked amazing but time intervened. I had to pick a strategy and go with it. I traced the pixel art onto peg board and used the holes as a guide, the total is 124 LEDs per arrow.  In order to fit in one inch squares the arrows overlap one another. The design was drawn out onto peg board (again the coffee table project) and then transferred to some foam core poster board.

This left a nice guide for all the LEDs. There are companies out there that make very specific foam board hole punches, but my local craft store had nothing like it. So I was forced to use the pen knife to spoon drill the holes, all 248.

Once all the holes were drilled I had to press the LED into its slot, this was pretty labor intensive. 5mm LEDs can really damage your fingers.

I tried to get the arrow gradient by spacing out the last couple LEDs in the pattern, it went okay. Some resistor tweaking could produce a more convincing fade out. Dual orange/blue LEDs would have been even cooler. To protect all the wiring and LEDs I glued an arrow shaped section of foam core to the back of the sign (left over from diffusion experiments), this let a bit too much light through the back of the edge LEDs. I’d recommended cutting a slightly larger backing and attaching it with a weak adhesive or Velcro to allow future access to the electronics.

The Circuit:

Now that all of the LEDs are mounted I plugged a few variables about my setup into an LED calculator. I had to determine some values experimentally since blue and orange are slightly different, and I long since have lost any data pertaining to them. My source voltage is 18v, I used a multimeter to find the voltage drop and a power supply with a current meter to measure the forward current of the LEDs.

The calculator told me I could string the oranges up in chains of 9, with a 1Ω resistor for each chain. The orange array would draw 448mA from the batteries. The blues each consume 4 volts and around 70mA (!!). The blues were wired in groups of four, with a 33Ω resistor on each chain. The blue LEDs draw 2.1A from the source. This is about when I decided on the heavy duty MOSFETs from an electric motor project.  The leads of the LEDs were then bent down to wire them together. Since I only had surface mount resistors I had to run ALL of the LED positive wires back to the PCB using some wire wrap wire I had lying around, this is one of those cases where a through hole resistor and some thick bus wire could have made life MUCH easier. The LED grounds were created with some low gauge bus wire, and separated for the up/down portions of the sign.

Switches are fun, people love a good SPDT. They are robust, can handle lots of current… they are really good at toggling LEDs. You know what people really love though? Accelerometers. People love accelerometers, and I happen to have a whole hand full of these buggers in my pile of goodies. Somewhere in the solder smoke and endless wire bonding I had the insane idea to use my spare Arduino to control the arrows, and trigger them off some sort of gesture.

Below is the final circuit. The 3 axis accelerometer is extreme overkill, Cheap analog accelerometers are easily found soldered and coded for and I would go with one of those were I to do this project again.  I also failed to include a potentiometer and code to fade the LEDs via PWM. Don’t judge me, I ran out of time! You may also notice that the voltage regulator is more or less tacked on haphazardly, I had a really nice switching regulator but the stupid thing had the audacity to explode! The nerve! At least it didn’t happen during the event.

Code:

The accelerometer I had on hand is the LIS3LV02DQ, which was offered by sparkfun back in the stone age. I found my own block of code to modify but the site is currently down, you can find a slightly more complete example of the original here and the sparkfun page also has code, this made life really easy. All I had to do was figure out what axis was vertical and set up a threshold to flip on either MOSFET. Gravity affects the axis facing down, so its threshold had to be offset by 1024. I also think the accelerometer was upside down since I wound up at a smaller negative number than positive, either way messing around with the serial output on really helps to dial in the values. 

Testing also revealed that I needed some kind of ‘lock out’ timer. When you flick the sign vertically acceleration peaks on one axis but then reverses on itself as you pull the sign back down. I used 1 second although this value could be shorter. Here is the code, don’t forget to check out [Troy]‘s code for more heavily commented accelerometer stuff:

#include <Wire.h>

// TWI (I2C) sketch to communicate with the LIS3LV02DQ accelerometer

// Using the Wire library (created by Nicholas Zambetti)
// http://wiring.org.co/reference/libraries/Wire/index.html
// This Code is modified to toggle two digital outs based on
// A sudden acceleration upwards or downwards on the Y axis
// -Jesse Congdon

//Modified code from http://research.techkwondo.com/blog/julian/279
//Thanks Julian.

#define OUTX_L 0x28
#define OUTX_H 0x29
#define OUTY_L 0x2A
#define OUTY_H 0x2B
#define OUTZ_L 0x2C
#define OUTZ_H 0x2D

#define XAXIS 0
#define YAXIS 1
#define ZAXIS 2

int downvote = 5; //pins 3 and 5 can handle PWM too
int upvote = 3;
int ledtoggle = 0;

int upgesture = 1800;
int downgesture = -1200;
int lockout = 1000;
boolean lockouttoggle = false;

void setup() {
Wire.begin(); // join i2c bus (address optional for master)
Serial.begin( 9600 );

Wire.beginTransmission( 0x1D );
Wire.send( 0x20 ); // CTRL_REG1 ( 20h )

Wire.send( 0x87 ); // Device on, 40hz, normal mode, all axis’s enabled
Wire.endTransmission();

pinMode(downvote, OUTPUT);
pinMode(upvote, OUTPUT);
}

void loop() {

int val[3];
// transmit to device with address 0×1D
// according to the LIS3L* datasheet, the i2c address of is fixed
// at the factory at 0011101b (0×1D)

Wire.beginTransmission( 0x1D );

// set the MSB so we can do multiple reads, with the register address auto-incremented
Wire.send( OUTX_L | 0x80);
Wire.endTransmission();

// Now do a transfer reading six bytes from the LIS3L*
// This data will be the contents of the X Y and Z registers
Wire.requestFrom( 0x1D, 6 );

while ( Wire.available() < 6 ) {
delay( 5 );
}

// read the data
for ( int i = 0; i < 3; i++ ) {
// read low byte
byte low = Wire.receive();
// read the high byte
val[i] = ( Wire.receive() << 8 ) + low;
}

//keep this in for testing
//Serial.print( " y_val = " );
//Serial.println( val[YAXIS], DEC );

//Now that we have a Y value, does it signify a jerk up or down.
if(val[YAXIS] > upgesture){
ledtoggle = 1;
lockouttoggle = true;
}

if(val[YAXIS] < downgesture){
ledtoggle = 2;
lockouttoggle = true;
}

//blue? orange? what are you trying to say to me toggle.
switch(ledtoggle){
case 0:
digitalWrite(upvote, LOW);
digitalWrite(downvote,LOW);
break;
case 1:
digitalWrite(upvote,HIGH);
digitalWrite(downvote,LOW);
break;
case 2:
digitalWrite(upvote,LOW);
digitalWrite(downvote,HIGH);
break;
}

//This allows me to pause the program to avoid debounce
//also you dont have to throw the sign and gently catch it to
//make it change.
if(lockouttoggle == true){
delay( lockout );
lockouttoggle = false;
}
}

Results:

Sucess! The batteries ran down on me several times (I learned four packs of 9v batteries are expensive). My battery issues stem from the long chains of LEDs. You can see in the above image that the oranges are already starting to die while the higher current blues are destroying the camera. Also note that the remaining 7 LEDs got their own chain and are, as a result, much much brighter. Therefore, smaller chains of diodes means that the LEDs can stay bright under lower voltages.  Silly of me to not realize this sooner. The orange LEDs would become tough to see after about an hour of continuous use.

This was a really fun project, everybody got a kick out of it and I think I have invented a new form of crowd control.

Thanks for reading!