Categories

Meta

Tag: Arduino

With a “Plushy Robots” all-girls summer camp coming up, Team FabLab was tasked with creating a way for each camper to go home with a robot they programmed themselves with just a couple of constraints: it had to be cheap, so we could make 10 of them, and it had be made of soft materials, since we promised Plushy Robots.

Sketching out different ideas of what could be done with Arduino’s basic servo motor program, I vividly remember Judy (@judieelee) exclaiming in a wide-eyed eureka moment: “Pom Pom Bots”

Since then, we’ve run this activity with hundreds of kids and seen every one of them get comfortable with plugging in the wires of the servo and changing the speed and movement of that servo by adjusting Arduino code. What follows is a lesson plan detailing the steps to run this activity yourself.

Setup & Introduction

If you’re not familiar with poms, they’re the colorful soft balls you can buy in big bags at your local craft store. Together with some googly eyes and hot glue, you can make some pretty adorable creatures. Once you add felt and fuzzy sticks (pipe cleaners) to the mix, the sky’s the limit.

The materials per student for this activity include:

Arduino Uno with USB cable

Microservo (9 gram)

3 jumper cables

The materials you should have piles of for students to share include:

PomPoms of many sizes and colors, Fuzzy Sticks, Felt

Googly eyes

Scissors for fabric, wire snips for fuzzy sticks.

LOW TEMP hot glue guns

In addition to these materials, you will also need a nearby computer lab (we used laptops) to program the Arduinos. This activity involves constructing the robot and programming the robot. How you set up your space will depend on how many participants you have and how many helpers you have.

We had three 8 foot tables for hot gluing and pipe-cleaner-sculpting and two 8 foot tables set up with 10 laptops for a group of 20 kids. We had 6 instructors (sometimes a couple more volunteers) for 20 kids, which was great. I can’t recommend going into an Arduino-programming activity without an instructor per 2 or 3 computers — it’s really important to guide students through the lesson on an individual basis. The success of this activity has been in large part because the instructors are familiar enough with Arduino code so that they can spot typos and common errors right away. Learning perseverance in debugging can wait for another day — we’re trying to get these kids comfortable with programming, to be able to see themselves as programmers, and staring at a screen for more than a few minutes without knowing what’s wrong can be very discouraging.

Start the class by gathering students around a table with some example bots you built yourself. Have the bot running so kids see the result of the activity and get their gears turning. We often use this time to egg the kids into a conversation on robots in general. You get to ask kids, “What is a robot, anyway? Is it a machine that does something for us? At what point does a machine become a robot? Does it have to make decisions for itself? What’s the difference between following instructions and making decisions?”

I encourage you to ask kids what they think of robots and what they think the future holds any chance you get, you’ll be surprised with what they come up with. My favorite exchange that’s happened during this activity:

Creating small electronics out of uncommon materials is a hobby of mine. I think it’s fun to show that electronics isn’t limited to circuit boards, and computers don’t have to be stuffed inside boxes. Especially when FabLab is exhibiting for school age kids who might change their minds about whether they’re interested in CS and ECE, I’m happy to show off a wide variety of computers, usually various arduino-powered objects.

Aside from having interesting widgets to show off, I mostly enjoy the challenge of building something with materials I haven’t seen used before. Instead of sewing LEDs on top of fabric, I wanted to integrate the LEDs into the fabric, so I used a hand loom to make a patch of fabric, using stainless steel thread as my weft. Knots have never made sense to me, so setting up the loom was especially challenging.

I really can’t think of anything to do with this, so for now it’s just a tech-demo. I’d love to hear your ideas.

I really appreciate what Adafruit and Sparkfun do to make small electronics available in sew-able packages (such as the Flora and Gemma microprocessors from Adafruit, and the Lilypad from Sparkfun), but I never really liked that the components were still bonded to a chunk of fiberglass circuitboard — it limits the flexibility of the fabric where it’s sewn and it looks bulky. With that and the extra expense of those products in mind, I wanted to come up with a strategy that allows surface mount components be embedded into a flexible material. SMD is the cheapest package for many parts — we order these 1206 size LEDs at 2 or 3 cents apiece on eBay.

Stranded copper soldered directly to these LEDs are sewn into leather which was lasered to punch holes and provide guides for the wire. This is just a test swatch, I have it in mind that lasering the holes and traces like this would provide a way to wire fairly complex 2-layer circuits (since traces could cross to opposite sides of the leather to avoid intersecting). The parts can sit flush with the surface of the leather, and the leather can flex without dislodging the parts — they aren’t bonded to the substrate, just pulled against it by the copper stitches. This also makes it surprisingly repairable. At one point I melted an LED after stitching everything together, and it only took a minute to un-solder and drop in a fresh LED.

For the leather circuits, I’m looking forward to trying to do 7-segment displays with the same LEDs, but embedded the microcontroller and battery holder directly into the material. I’m imagining interesting tabletop radios and clocks that exhibit their circuitry on their surface.

NodeJS, Client Side Javascript, and Google Speech API

This section of the tutorial introduces “client side javascript” — running code alongside HTML in a web browser. We won’t be building a beautiful site. Instead, I’m going to introduce as little as possible to get results so you can move onto controlling lamps and motors and other internet-connected-things. Hopefully you can combine this with your own knowledge or other tutorials to build the application you want.

At this point you should have two files, a server.js and an index.html sitting in the same directory.

For this part, we’ll just be working with index.html, so you could simply point your web browser to C:/your/file/path/index.html and it will work fine, but why not get in the habit of starting your node server? You’ll see changes to index.html reflected when you refresh the page either way.

The history of HTML is a jumbled one with many actors. Lots of people were taking stabs at building websites and lots of people were writing web browsers that did their best to render a useable website from everyone else’s code. The modern day result of this is that the web browser is a very forgiving platform that lets you leave all kinds of stuff out, and lets mistakes go without complaining too much. That’s actually one reason why I’ve heard some people discourage javascript as a first programming language: you can make a lot of mistakes and there’s not a compiler to tell you what you did wrong, the web browser will try to run anything it can and ignore whatever doesn’t work.

Use the “Inspect element” to find out how Chrome interpreted our 4 lines of HTML:

Our file only contained <h1> tags and the <script> tags. <html>,<head>, <body>, and this mysterious “#shadow-root” were all added by the web browser before rendering. On top of that, in the bottom-center there’s styling added on to the <h1> element: all of this display: block; font-size: 2em; -webkit-margin-before etc. is added by Chrome to make our barebones HTML code look presentable. So like I said, you can leave a lot out and modern web browsers will figure out how to render your page anyway.

OK, I promised an interactive web page, so let’s change that header <h1> into a button <button>. If you don’t know: in lots of text editors Ctrl+H will bring up a “find and replace” menu. We’ll also add an “id” attribute inside the opening button tag: this is a name you give individual elements so you can write javascript that acts (or listens to) those elements.

Here, ‘onclick’ listens to that ‘myButton’ element, ready to react to a click at any moment. This is different than, for instance, programming an Arduino, where we’d have to check whether a button is pressed continuously in an infinite loop. Instead, we can write a function that executes only in response to the web browser noticing that the user clicked their mouse while hovering over the button element. This is “Event driven programming.” (You actually can do event driven programming with Arduino, if you know about hardware interrupts.)

While chaining those identifiers and functions all together on one line works OK, programming like that quickly gets hard to read. It’s much better practice to break it into pieces.

Create a function called speak, which calls on the alert function to say hi.

Attach the ‘onclick’ event listener to the button variable and assign the function named ‘speak’ as its action.

I included two ways you could create the speak function here that would work equivelantlly in this case. There are specific cases where you should choose one or the other that involve global vs local scope (great info on the subject here), but for now it’s just important to know that there’s more than one way to do it. Hopefully keeping that in mind will make reading other people’s javascript examples less confusing.

Buttons default to ‘block-inline’ style, and appear on the same line

Let’s move on to a button that changes the background — this will set us up for turning a lamp on and off. The buttons have separate IDs, and each button is assigned to a new javascript variable.

By the way, you don’t have to have a button element to be able to click on it. I like the look of h1 better, so I’ll just click on those. I’ll change the color style of the h1 elements with each click as well. (side effect: button elements default to a block-inline style whereas header elements default to block style)

Recommended Reading:

Note: “Handling Events” recommends using ‘addEventListener’ instead of ‘onclick’, which is a better way to do it. Onclick events are limited to one-per-element, whereas you can ‘addEventListeners’ as much as you want. But for a simple example I like the syntax of .onclick better.

This tutorial will allow you to play short samples (less than four seconds) from an Arduino with no extra hardware. It is based off the work of MIT group “high-low tech” and uses all free software. It will futher explain how to trigger the sound using sensors. It is generously translated into Chinese by Chris Zhang at Shanghai hackerspace Xin Che Jian:

You can either open an existing file with Audacity, or record a new one, which is what Chris did to create our ghost sound. Freesound.org is a great website to download other people’s recordings. Try it out! Use the record, stop, and play icons at the top left of the program.

When deciding what sound to use, we have to consider the very small memory of Arduino — 32kB for our program + our audio. Audacity has a “resample” ability so our sound takes up less memory. In the bottom left corner, change the project rate from 44000 to 8000. Then in the Tracks menu, select Resample, and hit OK.

When powering a speaker directly from the Arduino, it won’t be very loud. In Audacity, if your sound waves aren’t very tall (low volume, low amplitude), it’s useful to use the Normalize effect. This boosts your levels as high as possible without clipping (overpowering the speaker resulting in distorted sound). Select Effect →Normalize and set the amplitude to zero before hitting OK.

In the Export menu, you’ll have the option to change the file format. This is typically the difference between mp3, wav, and flac, etc. but we’re using a more uncommon file type, so in that menu choose “Other uncompressed files” and click options. Choose WAV (microsoft) as your header , and Unsigned 8 bit PCM as the Encoding.

This results in a very small .wav file that we can finally convert to store on the Arduino. The conversion program is written in Processing so for now it requires Java. Run “EncodeAudio”, which simply asks you to select that wav file you just exported. The results are stored on your clipboard, waiting to be pasted. We’re ready to open Arduino and save the file to memory.

Open the Arduino IDE and add the PCM library downloaded above. Open File →Examples →PCM →playback. It should look like this:

That long list of integers is the example sound, we can replace it with the list of integers that resulted from Encode Audio. Triple-click on any of the numbers to highlight the entire line (thousands of numbers long) and use ctrl-v or cmd-v to paste our own sound.

Upload this code and the sound will play on a speaker connected to pin 11 and GND. You can either use a tiny speaker like in the doorbell tutorial, or if you have speakers with a headphone jack, wire it up like so:

GND gets attached to the tip, pin 11 can be attached to either (or both!) of the remaining silver bands. Be sure to start with the volume on your speakers turned way down, this will play full blast! Also probably don’t do this to your nice stereo cause I’m not sure if it’s safe, I just know it works.

With the current code, the sound will play once when the Arduino turns on: you can hit the ‘reset’ button on the circuitboard to play it again.

The simplest trigger possible is touching two wires together to connect GND to a sensor pin. In our loop we constantly check if our sensor pin is ‘LOW’ and if it is, we start the sound. So cut the ‘startplayback’ function from inside the setup and paste it inside a conditional statement in the loop, using digitalRead() to check if it’s connected to ground. To make sure it doesn’t go off when no one is at the door, we use the internal pull up resistor using pinMode(). This is our final code for using a simple switch to trigger a single sound.

Notice that I changed the name of the array from ‘sample’ to ‘ghost’ — be sure to change the name in the startPlayback function as well — it’s used twice.

You’re not limited to this, of course! You can have as many different sounds as will fit on memory (so 4 seconds total) but trigger them at different times. Copy-paste that ‘constant unsigned char sample[] PROGMEM’ code and give different names to different lists of numbers. You can also use an external pullup resistor of 1 megaohm (the built-in one is only 10k) to make it touch sensitive instead of having to touch two wires together. Connect the megaohm resistor between the sensor pin (A0) and 5V. Delete the pinMode function from the setup.

The following code uses booleans to play a different sound each time the sensor is touched. This one includes our ghost sounds, so you can upload this and try it yourself. Megaohm resistor between A0 and 5V, speaker on pin 11 and GND.

ATmega328 + JQ6500 MP3 tutorial

Fellow Xin Che Jian member LuFeng came in with a good project and a stack of microchips: Microduino modules that can be programmed to play music off a memory card and a wireless doorbell that made a boring old doorbell sound. He’s new to arduino and the tutorials for these modules are fairly vague, so I thought this would be a good opportunity to write up a tutorial on using an Atmega328 and a JQ6500 to trigger sounds with a really simple program.

Here’s the tools we had, a really neat set of stackable modules called Microduino programmable with the standard Arduino IDE (though you might not know that by reading their website — for this ATmega328 at 5V and 16Mhz clock, you can tell the IDE that it’s an UNO, no extra hardware files are requried.)

While I used these modules to get this project to work, if you get these parts in a different format (maybe an Arduino UNO and a JQ6500 on a breakout board) the following instructions should be relevant to you, too.

So we’ll deal with two stacks separately first: the audio module with the usb port stacked on top of the memory card module and the ATmega328 stacked on the UART.

When you plug in the audio + memory card stack, two drives will show up on your PC: one is the internal storage on the MP3 decoder, you probably don’t want to touch that one. But the drive that shows up called “SD” is where we can drop our MP3s. Microduino’s wiki has some information on the necessary naming scheme: Our file will be called “001.mp3” and be placed in a folder simply named “01”

Audacity makes it easy to grab a short clip of our chosen sound: a nice piano arpeggio from a longer song. If you’ve never used Audacity, no problem, you can visit their website for a Mac or Windows executable, or if you’re on debian (ubuntu / kubuntu / mint etc) you can just open a shell and type “sudo apt-get install audacity” and it will magically be installed on your OS. File → Open your song, click and drag across its sound wave to select a portion of it, and hit play to listen to your selection. Once you’ve selected the few seconds you want to play, you can hit File → Export Selected Audio and choose your file type as MP3, save it with the filename ‘001.mp3’

With your mp3 moved to the ‘01’ directory of the SD card, we can unplug that module and start programming our ATmega328. The microduino wiki was really vague on how to write code to control the MP3 module, but thankfully it gives the model number of the IC it uses: JQ6500. So I searched for a “JQ6500 arduino library” and found something really well documented here. So download that library and add it to the arduino IDE in the usual way (Sketch →Import Library →Add Library… or unzipping into your sketchbook, whatever works for you.) Check out the example sketches, “Full Demo” and “HelloWorld”, but here’s my code to simply play the first file on bootup. (01/001.mp3)

The only part that may be different based on your hardware is line 5, the object declaration that defines what Arduino pins will communicate via software serial to the JQ6500 chip. Looking close on the underside of this particular breakout board, the default TX and RX serial pins (the ones not in parentheses) are labeled next to D2 and D3, which in Arduino IDE language corresponds simply to 2 and 3.

So I declared my object as mp3(2,3) but if you’re using a different breakout board for the JQ6500 you will have to determine which 2 pins are wired to JQ6500’s RX and TX and use those pin numbers in your “JQ6500_Serial mp3(tx, rx)” declaration. By the way, ‘mp3’ is a user definable name, it can be called whatever you want.

Once you’ve got that figured out, you can load the code to the little stack of UART + ATmega. Unplug it once it uploads, and join the two stacks together, and add the amplifier module on that, so you have a whole tower of modules. Oh, important thing to know at this point: if you try to power the stack via the audio module’s USB, it won’t work, it will try to boot into file transfer mode, so power it with the UART module or otherwise.

If everything has gone right so far, you can plug a little speaker (the aluminum 3W style pictured at the top is perfect and easy to get a hold of) into the amplifier and give it power you’ll hear your sample. Did it work for you? I hope so.

To get the sound to play only when our original doorbell rings, we have to add a conditional to our program: instead of just mp3.play() in the setup, we use an if statement in our loop so that the ATMega328 is constantly checking for an input, it’ll look something like this:

void loop(){ if(AnalogRead(A0) > 400){ mp3.play(); }}

Our input will be the two wires that use to be the doorbell’s speaker. For this, I cut off the original speaker and soldered new wires into its place. One of these wires should just be grounded, and the other wire can be stuck into A0 for measuring.

To make a sound, the speaker is pushed and pulled by changes in voltage. ATmegas have a 10-bit analog-to-digital converter that is super useful for measuring changes in voltage. Instead of measuring if something is turned on or off (like a button, which is strictly on or off, digital, 1 or 0) the A0-A7 pins let you measure subtler changes like a speaker buzzing around in between high and low voltage (between 1 and 0 😉

The readAnalog function performs this measurement for us, and if you want to experiment with this you should try the File → Examples → Basics → AnalogReadSerial program, which lets you open the serial monitor and see what voltage the ATmega328 is measuring. When you have what-use-to-be-a-speaker wired to GND and A0, and watching your serial monitor when you ring the doorbell, you’ll see a number jump around and settle back to 0 once the doorbell stops ringing. So in the code snippet, our mp3 will be triggered whenever the voltage jumps above 0V. (the 400 is a number we pick. In arduino-land, zero volts reads as 0, and 5 volts reads as 1023. That’s just because the hardware on the chip has 10bit precision, which is to say, it can distinguish between 2¹⁰ different voltages. 2 to the tenth power equals 1024, and if you have 1024 numbers and want to start at 0, you get the range 0–1023. So any voltage it measures is returned as some number between 0 and 1023.)

However, this simple way of waiting for change in voltage is susceptible to a electronic hobbyist’s worse nightmare: noise. Even if things are wired correctly (but especially if they’re wired loosely) little spikes in charge from humans handling things or other more mysterious sources can cause a spike in measurement, thereby triggering our doorbell when no one is at the door.

A slightly more reliable way to wait for changes in voltage, then, is to use a handy feature of ATmegas called an ‘internal pullup resistor.’ This phrase didn’t make sense to me for a long time so I’ll elaborate a little: if there’s a signal that may naturally fluctuate and you want to prevent it from fluctuating, you can wire a resistor in between that signal and a power source (thereby “pulling the signal high”, making it a “pull up resistor”) or wire a resistor in between the signal and a ground source (thereby “pulling the signal down to ground” making it a “pull down resistor”). If I didn’t explain it well enough, search for more articles about it, it’s a super useful thing to understand.

ATmegas have one of these resistors built in inside the chip and it can be programmed to be connected to a power source or not (this is the magic of programmable computers…they are machines that re-wire themselves). It can keep the analogRead measurement pinned to 1023 until some other active component, like our speaker signal, interferes and pulls the voltage low (remember how the speaker gets voltage pushed and pulled? That’s why this can work by measuring from 0V or from 5V, we just want to wait for a change in voltage, doesn’t matter what direction.) So to set that internal pullup resistor and wait for a change away from 5V, our code will look like this:

Oh, and the pinMode(6, OUTPUT) and digitalWrite(6, LOW) is kind of silly, I’m giving myself an extra place on my tiny MicroDuino modules to ground the speaker. Arduino UNOs have 3 different places to GND things, but if you ever need more, you can set a pin low and it will work just the same as a GND pin. Just don’t ground something that uses lots of power, because this forces current to go through the chip.

But that’s the final program, and the final necessary wiring: old speaker pins plugged into GND and A0, JQ6500 connected to pins 2 and 3, and I’m using the 5V pin to power the doorbell. It use to be powered by 220V mains, but that part exploded for reasons I don’t need to go into detail about here. Did you ever see Wayne’s World? Fireworks. Suffice to say, this almost become a blog about how to build a replacement full wave rectifier out of diodes until it occurred to me that the parts that I want to use can be powered off 5V.

Now when the doorbell makes a sound, it triggers the arduino to command the JQ6500 to play its mp3 and we hear a nice piano arpeggio instead of a boring old simulation of a doorbell.

Those are LEDs on DIY circuitboards weaved into a patch of cotton. The hand loom it was made on was laser cut, gifted to me by Walter Gonzales of Fab Lab Lima (Thanks, Walter!). Stainless Steel is used as a warp thread and can provide power to light up the LEDs, controlling each row individually.

The cooler part is that with Arduino, you can write a program that switches these threads from output to input very quickly. This means that each thread can act as a touch sensor (Like the Celestial Celeste) but if touch is detected, electricity can immediately be output down the same thread.

I’ve got a video of plain steel thread acting as a touch sensor (this is the Makey Makey method of using a large pull-up resistor and detecting when the sensor pin becomes grounded via your skin).

Unfortunately, I didn’t use LEDs with built in resistors (like the Adafruit sewable LEDs) so I can’t power them with 5V directly. Long story short, the detection circuit becomes more complicated if I have to use resistors before the output. Another option I’ve yet to try is detecting and powering the LEDs with an Arduino running at 3.3V (like the Adafruit Floras).

10/11/15 Update: Got it blinking with a Flora. Will probably have to mill my own board to integrate the resistors needed to sense touch and power LEDs. Or I could probably solder megaohm resistors to these same LEDs boards and weave them in…

With a team of new friends, I got to build a musical instrument that combines LEGOs and Arduino. An ultrasonic distance sensor hangs under a gantry and plays different notes according to the LEGOs underneath it. Our hurried first build was fragile, but pulled off a successful live demo in front of the audience.

(We called it FORTissimo since you could build LEGO forts that make loud noises.)

Thanks to Nora’s suggestion to join the facebook group Hackathon Hackers, I found out about an event I couldn’t pass up: a music/technology hackathon put on by a the People’s Music School (@PeoplesMusicSch ). Only trouble was I was living 300 miles away at a cabin in the woods of Southern IL. Luckily I wasn’t too far from an Amtrak station, and I scheduled a roundtrip on the City of New Orleans inside of the 24 hours I had off work (it seemed that way at the time).

After a few hours of spotty sleep on the train, and a drowsy cab ride to Merchandise Mart, I can’t tell you how refreshing it was to walk off the elevator into a sunlit atrium filled with the sounds of a string quartet. Throughout the day a few students of the music school would set up in one room or another to give a soundtrack to the brainstorming and building. It was awesome.

This was the first hackathon I’d participated in. The way teams were divvied up was a bit awkward: after opening remarks, the audience was asked if anyone had an idea for a team yet — perhaps they were expecting more small groups to show up ready to go, but I think most of the people came as individuals. So instead a few people introduced themselves and said what comes to their mind when they think about tech / music / education. I introduced myself and said I liked to use Arduino to teach music and coding.

In the coffeecake fueled team-forming mingling that came afterward, I was approached by a couple different people who had ideas for software to help people learn music, and I ended up sitting down with a couple of women who had kids studying music — it was a lot of fun to think about what makes practicing difficult for anyone (I had dropped out of music school a few years before partly because I couldn’t quite stomach the 4 hours a day in the practice booth that my professors recommended).

We identified that the repetition of material coupled with the lack of feedback makes sitting in a practice room a pretty dull experience. So we brainstormed ways of automating feedback — perhaps a program could take a recorded example of a teacher playing a passage, and compare a student trying to copy it. I still think a computer could quickly point out wrong notes and wrong timing so that you don’t practice the same passage incorrectly over and over, but we agreed that replacing a music teacher with an app was pretty pie-in-the-sky.

People’s movement from one team to another was pretty fluid, which was great — it meant ideas got around. Having people work around each other openly, brainstorming on white boards makes it pretty easy to join a conversation, and not long after, join a team. After bouncing ideas off a few different people during the morning, I came across a table scattered with LEGOs. Alex and Ania had brought their hack-kit with them and already had some beeps going on while constructing lego towers. Of course I sat down to ask them what they had going on. Alex had seen an Instuctables for an Arduino Distance Sensor with Buzzer and LED before coming to the hackathon and brought his Arduino, distance sensor, and piezo buzzer. After catching me up, he complained that his main concern is that the buzzer wasn’t a loud enough output. I showed him that it was really easy to control the sound from a laptop via Arduino, but he insisted that he doesn’t want the product to be tethered to a computer to work. Luckily (well, I was going to a music-tech hackathon) I had speakers and transistors in my laptop bag and built two simple one-transistor amplifiers to output some simple square wave tones. We rubber-banded the mini breadboard to the top of their gantry. Happy with the improvement, they let me join their team and commence a couple hours of programming and debugging to get each note of a major scale to be triggered by a particular height of LEGOs.

Note the kid in the background who looks jealous that we got to play with LEGO.

The live demo went great, playing a melody up and down a major scale (cleverly avoiding the bug we never worked out when going from the highest tower back down to nothing). Among the rest of the presentations, ours was the only one that was more than theoretical (though there were some web mockups that were pretty impressive for 6 hours of design time). I’d still like to explore software that compares a student practicing to some standard and tells the student what they can do to improve. I’d also like to actually build FORTissimo as a kit. It really would be pretty cheap and versatile. But for now it was just a fun weekend.