Saturday, October 11, 2014

Games and Controllers With Scratch, Makey Makey, and 3D Printing

We got a Makerbot Replicator 2 last December and one of the projects I came up with turned out really well, and I think is worth sharing. My 7th graders designed key press controlled games in Scratch, then designed hand-held controllers with embedded switches, and we connected Makey Makeys to the leads on the switches for a great game experience. The highlights were putting on a game arcade event for our middle school and exhibiting the projects at this year's World Maker Faire here in New York City.

Design the Scratch Games

I wanted my students to be aware that you can make games based around important, socially relevant themes, and that they would have to do so with theirs. So before they started their own, they played some examples. Here is a list I found, but I would love suggestions on others:
The context of this project is a full-year robotics class so making games was a diversion into physical computing and game design. Not being experienced in game design they needed significant scaffolding for their game design algorithms. So I walked them through the basic programming for two game formats with the idea that they would pick one to develop further for their project.

Falling Object Game

Here is a link on Scratch to a template, http://scratch.mit.edu/projects/25316753/. To teach it I had them remix it before it had any scripts and together we went through the scripting. I didn't cover winning and losing score scripts until later, but the script for that looks like this, placed in the stage.
And of course you have to add backdrops for winning and losing. It's easy to add more cans, just by duplicating the existing one, then you have more of a challenge. Students extended this format in ways I will describe further down.









Side Scrolling "Flappy Bird" Game

Here is a link to this template, http://scratch.mit.edu/projects/23061550/. Again, they remixed mine without the scripts and we went through the scripting together. Adding the winning and losing conditions later on was a little more complicated because the background sprites were covering the win and lose screens. 
So in addition to adding the script above to the stage, another condition has to be added to the background sprites scripts that makes them hide if the score gets above or below the limits for the game. You could also get rid of the scrolling background sprites altogether and the game mechanic becomes one of flying objects coming at a character that isn't moving but just jumping up and down to avoid them.

Game Enhancements

Students decided on a game theme and picked one or the other mechanic, then made several modifications to extend their template. They changed all of the graphics using images from the Scratch library and images from the web. Some added sound effects. Some added animations to the character that played when they moved or when they got hit. Some added levels by changing the stage background if the score went above a certain amount. Some added lives that were subtracted when you get hit so you have only 3 chances to get hit, and some made it game over as soon as you were hit once. Tough!  

Designing Controllers

The Makey Makey extends basic gaming keys to the the physical world. We used these two options for switches I had from Super Cricket and GoGo Board kits as the contacts. If you don't have switches, you will have to get the switches and solder on leads. A search for "momentary lever switch" brings up many varieties. Here is one for $.99 each on Jameco Electronics (my fav). Other than this, there are probably lots of ways to make switches for this project, but the more standard the better, since the switch is incorporated into the controller design.
   The switches have two leads. One connects to a Makey Makey alligator clip attached to a key assignment, like right arrow, and the other lead connects to the ground, or EARTH, assignment. Some games had one switch, some had two, depending on how you control the character.
The students used Tinkercad to design their controllers. There are several "lessons" they can learn basic skills, like making holes, grouping objects, and resizing.
The holes for the switches had to be precise, which was beyond the skills my students could develop. So I made that and gave them the link. They then clicked "Copy and Tinker" and built their controller designs around my piece.
Link to design
Link to design
In making their designs, they had to avoid two main pitfalls. One was scale. Some students ended up with very small controllers because everything looks bigger than it is on Tinkercad. The second was process. They had to make sure they had the size they wanted for the whole controller before they grouped their parts to the switch holder/s. If they grouped it and then resized it, the switches wouldn't fit.

Final Results

Here are many of the resulting projects. Here's a link to our project page for Maker Faire. If you try this project out, I would love to see your results (and so would my students)! Note: there are glimpses of GoGo Boards in some of the pictures below because we used those initially to connect the switches to Scratch. But that process was difficult and buggy, so I switched to Makey Makey for the final version.
 

 

 

 





Friday, July 18, 2014

Can Middle School Kids Create iOS Apps?

The Problem

No question about it, Apple does not make it easy to write apps for iOS. I take the fact that the Apple Developer program license is only free to university programs to be just one sign that Apple does not expect many students in K-12 to be making apps, no matter how much teachers may want them to (and they do!). I'm not talking about rare whiz kid 12 year-olds who follow enough tutorials and have enough guidance and a fairly good idea to make an app and get it in the store. I work with teachers who want to integrate app-making for iOS into their science curriculum, with 50 students developing content-rich apps. Is this possible?
I don't know...yet. But I'm working on it.
The apps themselves for this project are pretty simple--a "dichotomous key" structure people would be able to use to identify something scientifically in the field. Does the bug have six legs? Does the six-legged bug have wings? Does the six-legged bug with wings have a hard shell? etc. It's a lot of pages in a hierarchical structure. Maybe a messaging function people could use to take a picture of something they can't identify and send it to the author.

Requirements

Two primary things we require for this app-making workflow to work are a graphical UI for building the app and the capability to use Ad Hoc distribution for the app in our school's Organizational/Business Developer License. So far I've seen these two things, but in separate tools.

The Solutions

The graphical UI is amazingly worked out in Mozilla's Appmaker. A variety of objects are available on the left, placed on the screen in the middle, tweaked on the right, and the logic for each object worked out in colorful lettered "channels" that would be easy for middle schoolers to use to link up objects and pages.
Mozilla's Appmaker
With no coding it's perfect for a project that is not meant to focus on programming skills but to use computer science tools to accomplish a learning goal. Unfortunately it is designed to install on Firefox OS devices only.
The other tool that looks promising is Appmakr. Appmakr is all about making 'native' iOS apps that can be deployed to devices through the App Store or using Ad Hoc distribution and it offers a variety of basic functionality in a clear UI and great tutorials, again with no coding. However, the one feature we need in this project would be created in this environment by simply uploading a zip file of pre-designed HTML pages. You cannot edit custom HTML in the interface itself. So that won't work either.

The Solution?

Ironically, while reading about the whiz kid at the beginning of this post I learned of a tool that may possibly offer the graphical UI and the iOS deployment capability in one package. AppGyver Composer has a graphical UI like Appmaker, though not quite as simple or intuitive. You can configure basic button actions, perform layout in the structure tab, and there is a nice logic editor section that allows you to create paths of conditional actions. And Composer facilitates an App Inventor-like device connectivity that allows you to see edits on your screen update in real time on your device. And for the other requirement, iOS deployment, AppGyver takes you through the build and deployment process.
I will have to work with Composer some before I can really tell whether middle schoolers could use it to make apps, but on the surface it looks very promising.

Wednesday, July 16, 2014

Arduino waitForButtonPress function

Lots of programming robotics languages (RobotC, leJOS NXJ, Cricket Logo, NXT-G) have functions that allow you to suspend processes while waiting for some kind of input. My robotics students most learned about leJOS NXJ's Button.waitForAnyPress() method. When we moved on to programming Arduinos one of them wanted to use the same concept to run a sensor calibration routine in setup(). So we had to make one, and it turned out to be very easy. She was initially trying to do something complicated with boolean variables but I remembered using this simple construct in RobotC:

while(SensorValue(touchSensor) == 0)  // while the Touch Sensor is inactive (hasn't been pressed):
  {
    // DO NOTHING (wait for press)
  }

and thought something similar should be possible in Arduino. Here is what we worked out:

while(digitalRead(buttonPin) == HIGH) {
    //program will sit here until button is pressed (LOW)
  }

We turned that into a function and added a little debounce wait time and had ourselves a very nice waitForPress() function to call in our programs. The button is HIGH, or not pressed, by default, which we achieve by setting the pinMode to INPUT_PULLUP in setup, using the Arduino's internal pullup resistor. Here is what the function looks like, with an added delay to provide a debounce:

void waitForPress() {
  while(digitalRead(buttonPin) == HIGH) {
    //program will sit here until button is pressed (LOW)
  } 
  delay(1000); //delay for button debounce
}

Now students could call waitForPress() in setup to run a calibration routine in setup, like

  Serial.println("Turn lights ON and press the button.");
  waitForPress();
  recordMaxLight();
  Serial.println("Turn lights OFF and press the button.");
  waitForPress();
  recordMinLight();
  calibrateLightSensor();

with the function calls defined as:

void recordMaxLight() {
  maxLightVal = analogRead(ldrPin); //ldrPin is light dependent resistor
}
void recordMinLight() {
  minLightVal = analogRead(ldrPin);
}
int calibrateLightSensor() {
  ldrThreshhold = (maxLightVal + minLightVal) / 2;
  Serial.print("calibrated threshhold: ");
  Serial.println(ldrThreshhold);
  return ldrThreshhold;
}

Wednesday, May 21, 2014

Keeping Multiple Electroluminescent Wires Bright With An Arduino

I recently helped a student with a nice, provocative installation with kitschy religious imagery that used EL wires to simulate a neon sign. She had a border, made by a yellow wire, framing three words in orange, each made by its own wire. She wanted the border to stay lit while the words blinked on and off. If you've ever worked with EL wires you will know that if they have the same power source, such as an Arduino (with El Escudo Dos controller) the more wires that are lit at once the dimmer they all get, since the voltage is shared. She really should have done the words with one wire but she wanted the option to blink the words in series instead of at once.
As soon as we got them blinking, we saw the problem. The border significantly dimmed when the words came on, then got nice and bright when they went off. Not a nice effect. That was using this program:

const int border = 2;
const int wire1 = 3;
const int wire2 = 4;
const int wire3 = 5;
const int numberOfWires = 4;
const int delayTime = 750;

int wires[] = {
  wire1,wire2,wire3,border};

void setup() {                
  for(int i = 0; i < numberOfWires; i++) {
    pinMode(wires[i], OUTPUT);     
  }
  digitalWrite(border, HIGH);
}

void loop() {
  for(int i = 0; i < numberOfWires-1; i++) {
    digitalWrite(wires[i], HIGH);  
  }  
  delay(delayTime);
  for(int i = 0; i < numberOfWires-1; i++) {
    digitalWrite(wires[i], LOW);  
  }  
  delay(delayTime);
}
I had an idea it might be possible to get around the significant dimming by strobing the border and word wires imperceptibly fast to maintain the high power to the border, and it worked! Here is that code:


const int border = 2;
const int wire1 = 3;
const int wire2 = 4;
const int wire3 = 5;
const int numberOfWires = 4;
const int delayTime = 750;

int wires[] = {
  wire1,wire2,wire3,border};

void setup() {                
  for(int i = 0; i < numberOfWires; i++) {
    pinMode(wires[i], OUTPUT);     
  }
  digitalWrite(border, HIGH);
}

void loop() {

  for(int i = 0; i < 50; i++) {
    for(int i = 0; i < numberOfWires-1; i++) {
      digitalWrite(wires[i], HIGH);  
    }  
    digitalWrite(border, LOW);
    delay(15);
    for(int i = 0; i < numberOfWires-1; i++) {
      digitalWrite(wires[i], LOW);  
    }  
    digitalWrite(border, HIGH);
    delay(15);
  }    
  for(int i = 0; i < numberOfWires-1; i++) {
    digitalWrite(wires[i], LOW);  
  }  
  digitalWrite(border, HIGH);
  delay(delayTime);  
}
You can see how nicely it worked in these two pictures comparing the on and off states. The video below actually picks up the strobing but you lose the brightness:



Monday, March 24, 2014

Controlling NXT Robot From the Keyboard with leJOS NXJ

Bad GUI for robot control
(UPDATE: So this was all well and good as a proof of concept but we found when we brought the motors into the mix the motors were too slow to respond to direct commands. We learned a lot in the process, though.)

I worked up a proof of concept in leJOS NXJ I'll be teaching my high school robotics students soon for a method of controlling a tethered NXT robot directly through key presses. At first I had worked out a GUI with buttons following some Head First Java lessons but I realized that wasn't an optimal way to control a robot, by moving a mouse around clicking it. Arrow keys make much more sense. Capturing arrow key presses was hard to figure out. The Scanner class won't do because you type in a line and your String is captured when enter is pressed. For instant capture of every key press a KeyListener is needed, or that's the simplest way I could figure out.
So the solution I worked out is a text field with a KeyListener, and each arrow key press event calls a send-over-USB class method, sending a number over a data stream to the robot, which responds to the number sent with motor commands. In this proof of concept all I'm getting the robot to do is display response text on the LCD but it's a short step from there to driving it around.
Better GUI for robot control
First, the KeyListener GUI: For this I'm indebted to an Oracle example on KeyListeners. I stripped everything out that I didn't need in order to learn the bare elements that were needed. Here is the KeyEventDemo.java class, in plain text.
Second, the Sender class: There is an example in the leJOS NXJ download that sets up a data stream between PC and NXT over USB. This opens a data stream, sends an int 100 times to a Receiver class, receives it back from the NXT, and closes the data stream. I needed the data stream to stay open as long as the user wants to send new commands. The way the USB send examples were originally written, every time a key was pressed a whole new connection was established, and read and write data streams opened, which made each key press take 7-10 seconds to reach the NXT. So I moved the connection into the USBSend constructor so it would be established as soon as the USBSend class was referenced, then it was just the data streams that were opened and closed each loop. Synchronizing the logical coordination of opening and closing the streams and the connection was tricky to figure out. The other thing to figure out was how to close the IO streams and USB connection gracefully at the user request, which worked out nicely in the USBReceive class.
Here's the adapted USBSend.java class.
And the USBReceive.java class.
A few things that are helpful to know with leJOS.
  • the KeyEventDemo and USBSend classes have to be set up as a PC project, while the USBReceive class is a leJOS project.
  • On Mac with anything Snow Leopard + PC classes have to be run in 32 bit mode. In Eclipse you open run configurations and add -d32 to the VM arguments.

Thursday, March 20, 2014

Radio Shack DIY 3 X 3 LED Cube Project

This project is really fun! Lots of people have posted their experience putting it together so I won't do that, but after recovering from a bit of soldering problems what I find challenging, or just tedious, is figuring out exactly what hex codes to use to create arrays for you own programs. I did figure out lighting up individual LEDs 1-9 on each level to make these two patterns, shown one after the other here:

So to make it easier for others here are the codes for individual LEDs:

// 1-9
// * 0x001 = 1
// * 0x002 = 2
// * 0x004 = 3
// * 0x008 = 4
// * 0x010 = 5
// * 0x020 = 6
// * 0x040 = 7
// * 0x080 = 8
// * 0x100 = 9

And here's the array that makes the LEDs circle around:
//        Spiral 2, set page to 32
                                 {0x001,0x000,0x000,0x1ff},
                                 {0x002,0x000,0x000,0x1ff},
                                 {0x004,0x000,0x000,0x1ff},
                                 {0x020,0x000,0x000,0x1ff},
                                 {0x100,0x000,0x000,0x1ff},
                                 {0x080,0x000,0x000,0x1ff},
                                 {0x040,0x000,0x000,0x1ff},
                                 {0x008,0x000,0x000,0x1ff},

                                 {0x000,0x001,0x000,0x1ff},
                                 {0x000,0x002,0x000,0x1ff},
                                 {0x000,0x004,0x000,0x1ff},
                                 {0x000,0x020,0x000,0x1ff},
                                 {0x000,0x100,0x000,0x1ff},
                                 {0x000,0x080,0x000,0x1ff},
                                 {0x000,0x040,0x000,0x1ff},
                                 {0x000,0x008,0x000,0x1ff},

                                 {0x000,0x000,0x001,0x1ff},
                                 {0x000,0x000,0x002,0x1ff},
                                 {0x000,0x000,0x004,0x1ff},
                                 {0x000,0x000,0x020,0x1ff},
                                 {0x000,0x000,0x100,0x1ff},
                                 {0x000,0x000,0x080,0x1ff},
                                 {0x000,0x000,0x040,0x1ff},
                                 {0x000,0x000,0x008,0x1ff},

                                 {0x000,0x001,0x000,0x1ff},
                                 {0x000,0x002,0x000,0x1ff},
                                 {0x000,0x004,0x000,0x1ff},
                                 {0x000,0x020,0x000,0x1ff},
                                 {0x000,0x100,0x000,0x1ff},
                                 {0x000,0x080,0x000,0x1ff},
                                 {0x000,0x040,0x000,0x1ff},
                                 {0x000,0x008,0x000,0x1ff},

Now how about the hex codes for combinations of LEDs? Brad here explained the method for calculating them but I didn't get it until I read over it a few times. Once we have the base 10 (DEC) value for each of 1-9 (see Brad's table), just add those for the numbers you want to display, then convert the total to HEX, like here. For example, if I want 4 and 6 to light, 8 + 32 = 40, converted to HEX = 28. So this will do it for that element: 0x028.
Update: here is a modified sketch for running different tables more easily. Different patterns are individual tables, so call the pattern() function with a table passed as argument, along with how many lines it uses.

Monday, March 17, 2014

Hands On Tech: Making Ceramic Tiles

Inspired by the brilliant work of Gary Donohue and Josh Burker, I have been working on a project with some of our art teachers that has exciting possibilities. It started with Gary describing his workflow that allows elementary students' line drawings to become 3D printed pieces. Then Josh took that in another direction with 4th graders using Turtle Art to make patterns that can be printed as presses for making clay tiles.
One of our art teachers said this is the idea that fills in the missing link for him with 3d printing--the link between hand-made artwork and digital manufacturing. Other teachers responded similarly, feeling little affinity for a machine that prints digitally designed objects until they could see how hand craft can be a vital part of its use.
I'm working with a high school art teacher and her ceramics class. I made a Processing sketch they can use to generate patterns from several different shapes. Check it out, it's here: http://openblackboard.com/processing/shapetile/.

Conceptually the code of the program is very similar to the one Josh presents above for Turtle Art. Each shape object is made up of a shape method, called by a row method that draws the shape across the window (and a second offset row if you set offsetEvenRows to true), called by a makeRows method that repeats the rows top to bottom. The amount of horizontal and vertical overlap is determined by the slider numbers you give the shape, as well as the size of the shape.
After configuring the shapes they way you want click the save button and download the image. You will want to tweak it before you get your final pattern.
The next step is to crop the image down to what you want just for the tile, so open it in Preview, or some image editor on a PC, and crop down to the desired area. Since you probably want the tile to repeat horizontally and possibly vertically as well this may be tricky, especially if you are aiming to have a square tile.


Save the cropped image and open it in Illustrator. Now you will trace it to prepare it for conversion to a vector graphic. Click Object > Live Trace > Tracing Options. Check Preview and spend some time trying the different Presets. When you have one you like, click the Trace button. At first I tried Detailed Illustration on this one, but when I completed the next step, importing to Tinkercad, I saw that the preset did something very different than I expected, so I retraced it with the Lettering preset and that worked much better.

Click Save as, and choose SVG.
Now in Tinkercad use the section in the upper right to import the SVG file into a new design. It will come in bigger than you want it, so scale it down, holding shift while you drag a corner to keep the aspect ratio.
The height will have decreased as well so raise it back up to about 6mm. Then add a 2mm layer to tie it together. 
And now some results! I can't wait to see them glazed.










Friday, March 07, 2014

A Machine Asking To Be Remade

I've been having a great time teaching students about 3D design and printing, and helping them print things they need. From robot scoops to ears, it's always an exciting surprise to find out when the printer can be a useful tool for learning. One of the more interesting ways it serves as a useful tool is in printing parts for itself. I've found two of these opportunities so far. Early on I could see that the filament tube on the Replicator 2 came out of its clips on the back easily when the extruder had to move towards the back of the build plate. I found a filament tube upgrade on Thingiverse that has worked perfectly.

Then recently a student's dad brought in a few spools of filament to provide more colors for printing. One of the spools has a much smaller hole than the standard Makerbot spools. So I found a spindle, again on Thingiverse, modified it a bit in Tinkercad, and now the spool fits perfectly.

Monday, February 24, 2014

Raspberry Pi Makerbot Cam

We've been using our new Makerbot 3D printer quite a bit since we got in in December in our school. I've been the one learning how to use it and training some students to use it. So it's taken quite a lot of my time watching the results from printing different projects under different conditions. Not every print comes out successfully and sometimes you need to cancel a print because you can see that something is going wrong. And sometimes a spool of filament is running low and you're not sure there will be enough to complete a print. Rather than having to check on it every so often, I wanted to set up a streaming Makerbot cam with my Raspberry Pi and the new Pi Cam I got for it so I can oversee prints wherever I am.
The Pi Cam produces very nice quality still and video images and there are some very good tutorials on making it do lots of different things.
I like to do things a little at a time, so in this post I'm outlining the steps toward the eventual goal of streaming video and some of the hurdles on the way to getting there.

Getting the camera working

Getting the camera plugged in and snapping pics and video was easy and fun. The Raspberry Pi folks have put this information together here: Raspberry Pi Camera setup. In the process I wanted to start using the Raspi in "headless" mode to make it easier to get the photos off. My email client doesn't really work on it and plugging in a USB drive to copy files takes time. 

Remote access to images

From a Mac I use Terminal to log right in to the Raspi. Get the Raspi's IP by typing ifconfig on the Pi (connected to a monitor with peripherals), then use that to log in with SSH:

ssh pi@ipAddress
Now I'm at the pi prompt and can type the camera commands to take pictures and video. But the files are saved on the Pi. To get them off, log out of the ssh session. I used SCP to copy them to my Mac:

scp pi@ipAddress:image.jpg Desktop/image.jpg

puts the image right on my desktop.

Streaming video to a website

Miguel Grinberg has a great method of setting up a constant stream of images to the web from a Raspi Cam here. The idea is not to stream video, but to take stills in rapid succession, each new one replacing the previous, and stream those with MJPG-Streamer. So far it's pretty choppy for me, but I haven't played with the framerate yet. I can probably tweak it to get a smoother stream. Here is a sample:
There is a point in Grinberg's tutorial where he provides an update on installing MJPG-Streamer. Definitely follow it. The information is crucial to getting it to work successfully. I found a couple Linux command line tools useful. To stop the raspistill process before it's finished, first log out of the SSH session (the trailing & allows you to log out without killing the process), log back in and type:
$ ps aux | grep raspistill
That shows the raspistill process ID. Then you can kill it with:
$ sudo kill 2314 
(or whatever it's process ID is)

Running the streamer from button input

So I don't want to have to log in to the Pi and run this line of code every time I want the Pi to stream Makerbot footage:
$ raspistill --nopreview -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &

What I need is a button I can press on the Pi that starts taking pictures for an hour or two. So I've ordered this setup from Adafruit--a GPIO ribbon and breakout board--to which I'll wire a button. The MJPG Streamer is always running, so all it needs is the pictures to dump into the streaming folder. This took some time to figure out. Here is the wiring below, which includes wiring for a momentary switch and an LED that will stay on as long as the camera is taking stills. The LED on the camera would work were it not for the camera enclosure I printed, which covers up the LED. I know, I could have drilled one or put it in the design, but a little more wiring is fun. Some tips on this setup follow:
Note: LED is on because switch has just been pressed.
To figure this out, I mostly used these two resources; buttons and switches and blinking LEDs. Initially the switch did nothing because I made the mistake of having the GPIO ribbon reversed. Heed this advice and make sure the single different colored wire on the ribbon--in my case, white--is oriented so it is towards the outside facing end of the Pi, not towards the middle. And on the topic of GPIO pin numbering, I am using BCM mode, which is a confusing topic for beginners like me and well explained here (down the page at A Word About GPIO Pin Numberings). The concept of pullup and pulldown resistors is still a little fuzzy to me, despite having dealt with it before with Arduinos, but I am pretty sure I have a pullup resistor here because there is no resistor between the button and ground. I need to attend a pullup/pulldown workshop, clearly.
So for the programming I used Python, which is typical on the Raspberry Pi. I made one Python program that 
  • configures the GPIO pins, 
  • turns on the LED when the button is pressed, 
  • runs a shell script that creates the /tmp/stream directory (for some reason it keeps disappearing) to store the images, 
  • starts the raspistill command, 
  • starts MJPG Streamer (if it's not already going), 
  • then turns off the LED when those finish. 
Note the trailing & after the MJPG Streamer command. That allows raspistill to start even though the MJPG Streamer process hasn't been stopped. The omission of & at the end of the raspistill command forces the LED to stay on until it has finished, though. The original program in the buttons and switches tutorial had prev_input = 0, but I had to change it to prev_input = 1, or the program would run without being pressed the first time, I think because my switch is being pulled high when open (not pressed), so ((not prev_input) and input) was initially true when prev_input was initialized to 0.
Here is startcam.py:
And here is the shell script startMBCam.txt:
I tried to get startcam.py to run at startup like is shown in the buttons and switches tutorial but MJPG Streamer would not run. I could tell the camera was snapping images but nothing was accessible at the streaming IP.

Creating a box for the camera

For this part I found a nice Raspberry Pi Camera case design on Thingiverse and used Tinkercad to modify it a little. I moved the ball connection to the bottom of the camera case front and flattened the ball socket.

The next and final step will be mounting the whole apparatus near our Makerbot with power and ethernet attached, but that will have to wait until after break.


Wednesday, January 01, 2014

Tri-color LED Project: Mineral Light Show

My son has a piece of hambergite--I'm pretty sure that's what it is--and I've been wanting to give it special lighting for a while. Finally got a tri-color LED and wired up some switches so the colors can be turned on in combination. With this setup you can make 7 colors, red, green, blue, of course, and their complements, yellow, cyan, and magenta, and with all three, white. Hambergite is translucent with cleavage running straight along the length of it, so light travels through it well. So here are some pictures of the results.