Solderin’ Skaters

About a year ago, i joined a group of hackers to take part in the Nokia Push Challenge, which was basically a hacking contest brought up to advertise the N900 smartphone that was released at the end of 2009. The teams were asked to come up with creative ideas to use the phone.
The Solderin’ Skaters wanted to equip a skateboard with motion sensors in order to use it as a real life gamecontroller for a skating game running on the smartphone. the skateboard sends 6-DOF IMU-data to the phone via Bluetooth. a software on the phone uses datamining in order to detect the tricks the skater performed and award those with points in the game.

i was one of the two hardware people that build the skateboard. the electronics were designed by the other guy and my main task was to mount them to the skateboard, sp o in this post, i will only focus on this aspect of the project.
what sounds simple at first is in fact fairly difficult. besides the strong vibrations while riding the skateboard, huge g-forces are applied to the electronics when you land a trick. another problem is that almost every part of the skateboard is exposed to kicks, scratches and impacts, which has to be kept in mind when searching for a spot to mount the electronics. additional constraints are Bluetooth connectivity and the sensitive LiPoly battery that powers the system.

we decided to put everything between the deck and the trucks of the skateboard. therefor i designed a special mounting consisting of four important parts. first a frame that holds the electronics in place and protects them from impacts. second a set of transparent covers that allow to observe the status LEDs on the PCB. another important component is a custom foam rubber cushion that surrounds the PCB in order to damp vibrations and impacts. finally a thin piece of PVC separates the LiPoly battery from the PCB and keeps it safe inside the truck.

all parts were designed in a CAD software and CNC milled afterwards. after some try and error in the design, the results were pretty satisfying. the skateboard has been in sporadic use for about a year now and it still works fine.

besides the Push Challenge, we presented our work at the ACE 2010, the 7th International Conference on Advances in Computer Entertainment Technology in Taiwan.

demo of the application:

links:
solderinskaters.net, infos about the project
Solderin Skaters @ Flickr
Nokia Push Challenge

Using a 3D Mouse in CadSoft Eagle

A few weeks ago, i was deep into Solid Edge 3D CAD modeling for some mechanical stuff. our CAD computers are equipped with 3DConnexion 3D mice. this 6-DOF input device makes navigating in CAD software a pleasure. you can rotate and translate the objects on the screen while using a normal mouse in your other hand to manipulate them. anyways, once you get used to this, you cannot CAD without it. seriously.
now at about the same time i had the pleasure to design some PCBs in CadSoft Eagle. my left hand kept moving the 3D mouse in order to pan and zoom the view, but of course nothing happened. unfortunately, Eagle does not support 3D mice.

yesterday i found some time to do a dirty little hack in order to use my space mouse with Eagle. it took me two hours and somehow works. i spare you the details. just take a glimpse on the video.
this post is not about the actual hack. that’s just a proof of concept.

primarily i’d like to ask you, fellow space mouse and Eagle users, if you ever wished to navigate in eagle using your 3D mouse.
secondly i’ve got a message going out to the people at CadSoft: i like your software very much and it really improved my electronic design skills a lot. thanks indeed for that. but you’d be my all time heroes if you add support for 3D input devices to Eagle in the next release. come on, it’s not that hard. please?

update:
for those of you who really want to know how i did this, here’s the story. first of all, 3DConnexion offers a lot of information, examples and support for people who want to use their input devices in own applications and of course for companies who want to integrate 3D mice into their software. among a developers forum and their SDK download page, developers can download example codes at the 3DConnexion FTP-server (user:examples/pw:examples).

i used a .net example to write a small software that reads the 3D mouse. to interface CadSoft Eagle, i used the WINDOW (@); command bound to a hotkey. this Eagle command centers the view to the mouse cursor. when i move the 3D mouse, my readout software moves the cursor away from the view center (you can see that in the video) and triggers the hotkey. the more i push the mouse, the greater the distance between cursor and view center. this results in a higher panning speed.
zooming unfortunately cannot be done continuous, because it is triggered by hotkeys that zoom in or out a certain amount as the z-axis of the mouse exceeds a threshold.
this is all very dirty, i feel bad about it, to not try this at home, kids. although it somehow works, i have not really tested if it is usable when actually working in Eagle. a problem is that because i use the cursor for navigation, it cannot be used for manipulation at the same time. if you for example want to move a component, grab it with the move command and then use the 3D mouse for navigating, the component is moved too. another point is of course the bad interface between my readout software and Eagle. it is surprisingly fluid, but not comparable to a build in 3D mouse support.
talking about build in support, are you aware that panning and zooming only uses 3DOF of a 6DOF input device? that’s 3 rotational DOF that can be used for example to rotate parts or other awesome features.

[Projekt:Bunt]

While relaxing on a beach in spain back in 2006, an idea came into my mind. i wanted to build an LED display. fullcolor and large. no large resolution, just large in terms of dimension. in december 2006, i made actual plans for the project. from there on, i experimented, prototyped, programmed and soldered from time to time. having no deadline made it a real long time project. but then in 2009, i had my 10×10 pixel RGB LED matrix, a square meter of color and light.

i guess most of you are particularly interested in some facts about the hardware and software. first the hardware. i used 100 Superflux RGB LEDs with an angle of radiation of about 100°. the LEDs are dimmed via 8-bit PWM, generated by ATmega8 microcontrollers. each controller is responsible for 4 LEDs, which makes it a total of 25 controllers, running at 14,7456 MHz. there are 4 controllers on each PCB, the outputs are amplified by darlington arrays.

every LED has it’s own small board, including resistors for each color channel. the pixels are separated by a grid made of 4mm plywood. the light in each pixel is diffused by a small piece of air filter material and the frosted plexiglas pane. diffusion was a major problem, and i guess it’s not really possible to achieve perfect diffusion. my solution is a tradeoff between good diffusion and complexity.

the data comes from a PC via RS232(USB adapter) at 460800 baud. all controllers read the RS232 line simultaneously and are addressed by a reserved byte in the data stream. so i broadcast the data to all controllers and each one picks the data it is supposed to read. i’ve reached frame rates beyond 100 FPS.

the final software was written in JAVA because of the OS independency. it is still in development and will probably always be. at the moment it is capable of playing back animations which are stored in bitmaps, displaying the game of life and some variations of it, simple particles and several colorful effects and filters. and of course multiplayer tetris with overlaying playfields. can drive up to three sane persons really nuts.
the matrix was always supposed to be some entertaining decoration element, so it has to be able to generate an endless variety of content without steady user inputs. so i let the software surf the internet and jump from link to link. on every website, it collects content. at the moment, its just an image of the whole website, but i plan to analyze for example the text on the website. the image of the website is analyzed to get it’s n main colors, which are then the basic colors of graphical effects. i hope to end up with some kind of AI which analyzes the web in-depth and shows a simulated creative behavior in dealing with forms, colors and movement. but that’s an utopia right now and it’s gonna be a long way.
another plan was to add some kind of interactivity, but the design is not optimized for adding sensors. maybe a webcam could be used as a proper input-device.
future plans for the hardware include the integration of a netbook to have a completely standalone device which connects to the internet via wifi or ethernet. i considered some embedded solutions, but as old netbooks get cheaper and cheaper, this would be a reasonable solution

if you want to have detailed information about the development and the building process of this project, please visit the project’s own blog
http://rgb-led-matrix.blog.de (german)

brickAVR

Spending some time optimizing my prototyping-tools, i finally got the atmega8-basic-circuit i searched for. i don’t need things like onboard MAX232 or FTDI, because i have modules for that. what i wanted was some AVR-module that is robust, compact and features a crystal, a pullup and ISP. here it is:

i soldered a row of female pin headers directly to the AVR-pins. they have a distance of 0.4″, so you could fit a custom protoboard-shield on top of the module. a 16 MHz-SMD-crystal was glued under the chip and connected to the pins, and so was the pullup. i glued an 6-pin ISP-header to the front of the chip and connected it to the appropriate pins. last but not least  i added an SMD-LED to indicate power-on.  that was it for the electronics. next i filled the space between the female pin headers and above the atmega with hotglue (sticking the led into it). finally i needed a case. i had some lego bricks lying around on the desk and more randomly picked one that seemed to match. amazingly it fit perfect after i clipped the sides of the ISP-header. so i glued the circuit into the hollowed brick and added a label i made in corel draw. that’s about it.

the module is powered by the programmer (USB) and i can access every single pin. i like to use it in prototyping applications where a whole breadboad would be overkill, fragile or simply too large. like when you  just want to create a specific output signal. the module also easily hooks up to a breadboard. here’s another two pics of the lower side and the raw circuit:

delta robot

So i had these three servos and thought about how to use them in a project.  i saw flexpicker robots on the internets which were really impressive. had to have one. found six ball joints in my drawer and started to do some cad. i needed twelve ball joints or at least something comparable, so i had to make six from scratch. a few days of cnc-milling and drilling later i had my delta-robot. now it’s time to find a purpose for this thing. i thought about attaching some kind of head to it with an integrated display. i plan to control robot and display via rs232 and a microcontroller. so there’s more to come.

pics:

 

i2c slave

While messing around with twi (that’s what atmel calls i2c) some time ago, i built this little device that does nothing more than listening to the bus and display all the bytes it receives on a two-digit 7-segment-display in hex-format. the motivation for this project was not only “i need this thing” but also “i’m tired of coding and want to solder something. and i have to get rid of these displays anyway”. the schematic and layout was done in eagle. an atmega8-controller (overkill) handles bus and display. the whole device is powered by the bus.

here’s two pics:

yes, i forgot one line

haptiks cube

Some time ago i got into rubik’s cubes by accident. after a while i thought it would be nice to solve the cube using a different perception than the visual. i decided that i wanted something haptic.  so i went and designed some patterns that were

• easily distinguishable
• systematic
• plain
• easy to make
• rotation invariant

 

the result were three different basic shapes: cross, box, hollow box

“why no circle?”. well i decided to stick to the concept of straight lines. but i added some roundings just for a more comfortable feeling. anyway, it’s three basic patterns in a normal and diagonal version each since the colors on a rubik’s cube are also paired. we have [red/orange], warm colors on opposite sides of the cube, [white/yellow], bright colors and [blue/green], cold colors.  i wanted to keep that concept in order to have a better orientation when solving the cube. so each [normal/diagonal]-pair is located on opposite sides of the cube.

finally the plates were cnc-milled out of  pcv and it was a really painful amount of work to clean them with steel wool.  it took a while till i got my fingerprints back. i peeled off the original labels of the rubik’s cube and mounted the plates using double-sided tape.

54 plates later the cube was finished. the first days the cube felt a little uncomfortable, but it became better because the edges wore off. solving the cube takes me about five times longer than solving a normal cube, but it’s an interesting challenge every time.

here’s a picture of the finished cube: