This plug-and-play rig will make it easy to control high-voltage outputs from a low-voltage Arduino.

Read more on MAKE

The post Use an Arduino and Relays to Control AC Lights and Appliances appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.

 

My attention is drawn towards the noise behind me....
I cannot believe it.
There it is.

  The Arduino is taking a SELFIE !!

 

How did this happen?
 
Well actually, it is not that difficult for an Arduino.
 
I found out that my Canon Powershot SX50 HS camera has a port on the side for a remote switch. In the "Optional Accessories" section of the camera brochure, it identifies the remote switch model as RS-60E3. I then looked up the model number on this website to find out the size of the jack (3 core, 2.5mm), and the pinout (Ground, focus and shutter) required to emulate the remote switch. Once I had this information, I was able to solder some really long wires to the jack and connect up the circuit (as described below).
 

And before I knew it, the Arduino was taking Selfies !!!

 
Warning : Any circuit you build for your camera (including this one) is at your own risk. I will not take responsibility for any damage caused to any of your equipment.
 

Parts Required:

• Freetronics Eleven or (Arduino UNO compatible board)
• 4 Channel Relay Module
• 2x 330 ohm resistors
• 2 x diodes
• breadboard
• Jumper Wires (male to male)
• Jumper Wires (female to male)


• Canon Powershot SX50 HS - (here is the brochure)
• Three core, 2.5 mm Jack

 

Fritzing Sketch

 

 
 

Connection Table

 

 
 

Three core, 2.5 mm jack

 

 
 

Camera Connection to Relays

 

 
 

Jack pinout

 

 
 

Completed Circuit

 

 
 

Arduino Sketch

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

/* ===============================================================       Project: Arduino Selfie        Author: Scott C       Created: 14th Sept 2014   Arduino IDE: 1.0.5       Website: http://arduinobasics.blogspot.com/p/arduino-basics-projects-page.html   Description: Arduino takes selfie every 30 seconds ================================================================== */  /*   Connect 5V on Arduino to VCC on Relay Module   Connect GND on Arduino to GND on Relay Module */    #define CH1 8   // Connect Digital Pin 8 on Arduino to CH1 on Relay Module  #define CH3 7   // Connect Digital Pin 7 on Arduino to CH3 on Relay Module    void setup(){    //Setup all the Arduino Pins    pinMode(CH1, OUTPUT);    pinMode(CH3, OUTPUT);        //Turn OFF any power to the Relay channels    digitalWrite(CH1,LOW);    digitalWrite(CH3,LOW);    delay(2000); //Wait 2 seconds before starting sequence  }    void loop(){    digitalWrite(CH1, HIGH); //Focus camera by switching Relay 1    delay(2000);    digitalWrite(CH1, LOW); //Stop focus    delay(100);    digitalWrite(CH3, HIGH); //Press shutter button for 0.5 seconds    delay(500);    digitalWrite(CH3,LOW); //Release shutter button    delay(30000); //Wait 30 seconds before next selfie  }

 

By connecting up the camera to an Arduino, the camera just got smarter !!
The Arduino connects to 2 different channels on the relay board in order to control the focus and the shutter of the camera. The relays are used to isolate the camera circuit from that of the Arduino. I have also included a couple of diodes and resistors in the circuit as an extra precaution, however they may not be needed.

Warning : Any circuit you build for your camera (including this one) is at your own risk. I will not take responsibility for any damage caused to any of your equipment. Do your research, and take any precautions you see fit.

 
 

The Video

 

 

However, if you do not have a google profile...
Feel free to share this page with your friends in any way you see fit.

What do you do if you suck at a smartphone game? Buy some in-game upgrades to pretend like you’re good? Screw that! [Valentin] did what any self-respecting hacker would: developed an automated system to play for him.

Granted, when you see the demo video embedded below you’ll realize there isn’t much strategy involved in this game. But that setup to simulate the touchscreen presses is pretty neat. We’re used to seeing mechanical touchscreen hacks but this one is electronic, using a couple of pads of copper foil tape and some relays to make it happen. Here’s the one caveat: you still need to be touching something with your hand. This just uses the relays to switch the connection between the pads and your body.

We’ve looked around for this before. Does anyone have a cheap, simple, and effective hack to fully automate presses on a modern touchscreen? Can we use a potato or something? Tell us below, but send it in to the tips line too!

[Shawn] recently overhauled his access control by fitting the doors with some RFID readers. Though the building already had electronic switches in place, unlocking the doors required mashing an aging keypad or pestering someone in an adjacent office to press a button to unlock them for you. [Shawn] tapped into that system by running some wires up into the attic and connecting them to one of two control boxes, each with an ATMega328 inside. Everything functions as you would expect: presenting the right RFID card to the wall-mounted reader sends a signal to the microcontroller, which clicks an accompanying relay that drives the locks.

You may recall [Shawn's] RFID phone tag hack from last month; the addition of the readers is the second act of the project. If you’re looking to recreate this build, you shouldn’t have any trouble sourcing the same Parallax readers or building out your own Arduino on a stick, either. Check out a quick walkthrough video after the jump.

Today’s class in the freshman design seminar went well. I started by returning the drafts of the design reports and giving some generic feedback. I realized on reading the reports that I had not given a good explanation of what I meant by describing the components of the system—two of the groups had given me long parts lists on the first page of their reports, something that would only really be appropriate in an appendix. I explained that what I wanted was what the main blocks in the block diagram were, and that they should use the block diagram to organize their report, writing a page for each block. I also suggested that they use the block diagram to partition the project among the group members, with each group member working on a different component, then getting back together to reconcile any discrepancies. Note that this is much more like real engineering group work than the usual K–12 group project, which is usually done most efficiently by turning the whole project over to the most competent member of the group.

After the feedback on design reports, I offered the students a chance to get a demo of building an Arduino program with sensing and motor control. This was a completely extemporaneous demo—I had gathered a number of possibly useful components, but had not tested anything ahead of time nor even figured out what order to do the demo in.  I asked the students if they wanted me to start with sensing or control—they asked for the motor control first.

I started by pulling a motor out of box of motors I had gotten when the elementary school my wife works at cleaned out their closets.  I told the students that I had no idea what the spec of the motor were, but since it came from an elementary school, it probably ran on 3v batteries.  I tested the motor by hooking it up first to the 3.3v, then to the 5v power on my Arduino Uno.  It spun just fine on 3.3v, but squealed a bit on 5v, so we decided to run it on 3.3v.

I then pulled out the Sainsmart 4-relay board that I had bought some time ago but never used.  I explained how a relay worked, what single-pole double-throw meant, and normally open (NO) and normally closed (NC) contacts. I used the board unpowered with the NC contacts to spin the motor, then moved the wire over to the NO contacts to turn the motor off.  I then hooked up power to the board and tried connecting input IN1 to power to activate the relay.  Nothing happened. I then tried connecting IN1 to ground, and the relay clicked and the motor spun.  The inputs to the Sainsmart board are active low, which I explained to the students (though I did not use the terminology “active low”—perhaps I should have).  I did make a point of establishing that the relay provides very good isolation between the control logic and the circuitry being controlled—you can hook up AC power from the walls to the relay contacts without interfering with the logic circuitry.

Having established that the relay worked, the next step was to get the class (as a group) to write an Arduino program to control the motor using the relay. With me taking notes on the whiteboard, they quickly came up with the pinMode command for the setup, the digitalWrite and delay for the loop, and with only a tiny bit of prompting with a second digitalWrite and delay to turn the motor back off.  They even realized the need to have different delays for the on and off, so we could tell whether we had the polarity right on the control.  Here is the program we came up with:

#define RELAY_PIN (3)

void setup()
{   pinMode(RELAY_PIN, OUTPUT);
}

void loop()
{
  digitalWrite(RELAY_PIN,LOW); // turn motor ON via relay (or off via transistor)
  delay(1000);  // on for 1 second
  digitalWrite(RELAY_PIN,HIGH); // turn motor OFF via relay (or on via transistor)
  delay(3000); // off for 3 seconds
}

I typed the code in and downloaded it to the Arduino Uno, and it worked as expected.  (It would be nice if the Arduino IDE would allow me to increase the font size, like almost every other program I use, so that students could have read the projection of what I was typing better.)

I then offered the students a choice of going on to sensing or looking at pulse-width modulation for proportional control.  They wanted PWM. I explained why PWM is not really doable with relays (the relays are too slow, and chattering them would wear them out after a while.  I did not have the specs on the relay handy, but I just looked up the specs for the SRD-05VDC-SL-C relays on the board: They have a mechanical life of 10,000,000 cycles, but an electrical life of only 100,000 cycles.  The relay takes about 7msec to make a contact and about 3msec to break a contact, so they can’t be operated much faster than about 60 times a second, which could wear them out in as little as half an hour.

So instead of a relay, I suggested an nFET (Field-Effect Transistor). I gave them a circuit with one side of the motor connected to 3.3V, the other to the drain of an nFET, with the source connected to ground.  I explained that the voltage between the gate and the source (V_GS) controlled whether the transistor was on or off, and that putting 5v on the gate would turn it on fairly well. I then got out an AOI518 nFET and stuck it in my breadboard, explaining the orientation to allow using the other holes to connect to the source, gate, and drain.

I mentioned that different FETs have the order of the pins different, so one has to look up the pinout on data sheet. I pulled up the AOI518 data sheet, which has on the first page “RDS(ON) (at VGS = 4.5V) < 11.9mΩ”. I explained that if we were putting a whole amp through the FET (we’re not doing anywhere near that much current), the voltage drop would be 11.9mV, so the power dissipated in the transistor would be only 11.9mW, not enough to get it warm. I mentioned that more current would result in more power being dissipated (I²R), and that the FETs could get quite warm. I passed around my other breadboard which has six melted holes from FETs getting quite hot when I was trying to debug the class-D amplifier design. The students were surprised that the FETs still worked after getting that hot (I must admit that I was also).

I hooked up the AOI518 nFET using double-headed male header pins and female jumper cables, and the motor alternated on for 3 seconds, off for one second. We now had the transistor controlling the motor, so it was time to switch to PWM. I went to the Arduino reference page and looked around for PWM, finding it on analogWrite(). I clicked that link and we looked at the page, seeing that analog Write was like digitalWrite, except that we could put in a value from 0 to 255 that controlled what fraction of the time the pin was high.

I edited the code, changing the first digitalWrite() to analogWrite(nFET_GATE_PIN, 255), and commenting out the rest of the loop. We downloaded that, and it turned the motor on, as expected. I then tried writing 128, which still turned the motor on, but perhaps not as strongly (hard to tell with no load). Writing 50 resulted in the motor not starting. Writing 100 let the motor run if I started it by hand, but wouldn’t start the motor from a dead stop. I used this opportunity to point out that controlling the motor was not linear—1/5th didn’t run at 1/5th speed, but wouldn’t run the motor at all.

Next we switched over to doing sensors (with only 10 minutes left in the class). I got out the pressure sensor and instrumentation amp from the circuits course and hooked it up. The screwdriver I had packed in the box had too large a blade for the 0.1″ screw terminals, but luckily the tiny screwdriver on my Swiss Army knife (tucked away in the corkscrew) was small enough. After hooking up the pressure sensor to A0, I downloaded the Arduino Data Logger to the Uno, and started it from a terminal window. I set the triggering to every 100msec (which probably should be the default for the data logger), the input to A0, and convert to volts. I then demoed the pressure sensor by blowing into or sucking on the plastic tube hooked up to the sensor. With the low-gain output from the amplifier, the output swung about 0.5 v either way from the 2.5v center. Moving the A0 wire over to the high-gain output of the amplifier gave a more visible signal. I also turned off the “convert to volts” to show the students the values actually read by the Arduino (511 and 512, the middle of the range from 0 to 1023).

Because the class was over at that point, I offered to stay for another 10 minutes to show them how to use the pressure sensor to control the motor. One or two students had other classes to run to, but most stayed. I then wrote a program that would normally have the motor off, but would turn it full on if I got the pressure reading up to 512+255 and would turn it on partway (using PWM) between 512 and 512+255. I made several typos when entering the program (including messing up the braces and putting in an extraneous semicolon), but on the third compilation it downloaded successfully and controlled the motor as expected.

One student asked why the motor was off when I wasn’t blowing into the tube, so I explained about 512 being the pressure reading when nothing was happening (neither blowing into the tube nor sucking on it). I changed the zero point for the motor to a pressure reading of 300, so that the motor was normally most of the way on, but could be turned off by sucking on the tube. Here is the program we ended up with

#define nFET_GATE_PIN (3)

void setup()
{   pinMode(nFET_GATE_PIN, OUTPUT);
    pinMode(A0, INPUT);
}

void loop()
{ int pressure;
  pressure=analogRead(A0);
  if (pressure < 300)
  {    digitalWrite(nFET_GATE_PIN,LOW);  // turn motor off
  }
  else
  {   if (pressure>300+255)
      { digitalWrite(nFET_GATE_PIN,HIGH);  // turn motor on full
      }
      else
      {    analogWrite(nFET_GATE_PIN,pressure-300); // turn motor partway on
      }
  }
}

Note: this code is not an example of brilliant programming style. I can see several things that I would have done differently if I had had time to think about the code, but for this blog it is more useful to show the actual artifact that was developed in the demo, even if it makes me cringe a little.

Overall, I thought that the demo went well, despite being completely extemporaneous. Running over by 10 minutes might have been avoidable, but only by omitting something useful (like the feedback on the design reports). The demo itself lasted about 70 minutes, making the whole class run 80 minutes instead of 70. I think I compressed the demo about as much as was feasible for the level the students were at.

Based on how the students developed the first motor-control program quickly in class, I think that some of them are beginning to get some of the main ideas of programming: explicit instructions and sequential ordering. Because we were out of time by the point I got to using conditionals, I did not get a chance to probe their understanding there.

Today’s class in the freshman design seminar went well. I started by returning the drafts of the design reports and giving some generic feedback. I realized on reading the reports that I had not given a good explanation of what I meant by describing the components of the system—two of the groups had given me long parts lists on the first page of their reports, something that would only really be appropriate in an appendix. I explained that what I wanted was what the main blocks in the block diagram were, and that they should use the block diagram to organize their report, writing a page for each block. I also suggested that they use the block diagram to partition the project among the group members, with each group member working on a different component, then getting back together to reconcile any discrepancies. Note that this is much more like real engineering group work than the usual K–12 group project, which is usually done most efficiently by turning the whole project over to the most competent member of the group.

After the feedback on design reports, I offered the students a chance to get a demo of building an Arduino program with sensing and motor control. This was a completely extemporaneous demo—I had gathered a number of possibly useful components, but had not tested anything ahead of time nor even figured out what order to do the demo in.  I asked the students if they wanted me to start with sensing or control—they asked for the motor control first.

I started by pulling a motor out of box of motors I had gotten when the elementary school my wife works at cleaned out their closets.  I told the students that I had no idea what the spec of the motor were, but since it came from an elementary school, it probably ran on 3v batteries.  I tested the motor by hooking it up first to the 3.3v, then to the 5v power on my Arduino Uno.  It spun just fine on 3.3v, but squealed a bit on 5v, so we decided to run it on 3.3v.

I then pulled out the Sainsmart 4-relay board that I had bought some time ago but never used.  I explained how a relay worked, what single-pole double-throw meant, and normally open (NO) and normally closed (NC) contacts. I used the board unpowered with the NC contacts to spin the motor, then moved the wire over to the NO contacts to turn the motor off.  I then hooked up power to the board and tried connecting input IN1 to power to activate the relay.  Nothing happened. I then tried connecting IN1 to ground, and the relay clicked and the motor spun.  The inputs to the Sainsmart board are active low, which I explained to the students (though I did not use the terminology “active low”—perhaps I should have).  I did make a point of establishing that the relay provides very good isolation between the control logic and the circuitry being controlled—you can hook up AC power from the walls to the relay contacts without interfering with the logic circuitry.

Having established that the relay worked, the next step was to get the class (as a group) to write an Arduino program to control the motor using the relay. With me taking notes on the whiteboard, they quickly came up with the pinMode command for the setup, the digitalWrite and delay for the loop, and with only a tiny bit of prompting with a second digitalWrite and delay to turn the motor back off.  They even realized the need to have different delays for the on and off, so we could tell whether we had the polarity right on the control.  Here is the program we came up with:

#define RELAY_PIN (3)

void setup()
{   pinMode(RELAY_PIN, OUTPUT);
}

void loop()
{
  digitalWrite(RELAY_PIN,LOW); // turn motor ON via relay (or off via transistor)
  delay(1000);  // on for 1 second
  digitalWrite(RELAY_PIN,HIGH); // turn motor OFF via relay (or on via transistor)
  delay(3000); // off for 3 seconds
}

I typed the code in and downloaded it to the Arduino Uno, and it worked as expected.  (It would be nice if the Arduino IDE would allow me to increase the font size, like almost every other program I use, so that students could have read the projection of what I was typing better.)

I then offered the students a choice of going on to sensing or looking at pulse-width modulation for proportional control.  They wanted PWM. I explained why PWM is not really doable with relays (the relays are too slow, and chattering them would wear them out after a while.  I did not have the specs on the relay handy, but I just looked up the specs for the SRD-05VDC-SL-C relays on the board: They have a mechanical life of 10,000,000 cycles, but an electrical life of only 100,000 cycles.  The relay takes about 7msec to make a contact and about 3msec to break a contact, so they can’t be operated much faster than about 60 times a second, which could wear them out in as little as half an hour.

So instead of a relay, I suggested an nFET (Field-Effect Transistor). I gave them a circuit with one side of the motor connected to 3.3V, the other to the drain of an nFET, with the source connected to ground.  I explained that the voltage between the gate and the source (V_GS) controlled whether the transistor was on or off, and that putting 5v on the gate would turn it on fairly well. I then got out an AOI518 nFET and stuck it in my breadboard, explaining the orientation to allow using the other holes to connect to the source, gate, and drain.

I mentioned that different FETs have the order of the pins different, so one has to look up the pinout on data sheet. I pulled up the AOI518 data sheet, which has on the first page “RDS(ON) (at VGS = 4.5V) < 11.9mΩ”. I explained that if we were putting a whole amp through the FET (we’re not doing anywhere near that much current), the voltage drop would be 11.9mV, so the power dissipated in the transistor would be only 11.9mW, not enough to get it warm. I mentioned that more current would result in more power being dissipated (I²R), and that the FETs could get quite warm. I passed around my other breadboard which has six melted holes from FETs getting quite hot when I was trying to debug the class-D amplifier design. The students were surprised that the FETs still worked after getting that hot (I must admit that I was also).

I hooked up the AOI518 nFET using double-headed male header pins and female jumper cables, and the motor alternated on for 3 seconds, off for one second. We now had the transistor controlling the motor, so it was time to switch to PWM. I went to the Arduino reference page and looked around for PWM, finding it on analogWrite(). I clicked that link and we looked at the page, seeing that analog Write was like digitalWrite, except that we could put in a value from 0 to 255 that controlled what fraction of the time the pin was high.

I edited the code, changing the first digitalWrite() to analogWrite(nFET_GATE_PIN, 255), and commenting out the rest of the loop. We downloaded that, and it turned the motor on, as expected. I then tried writing 128, which still turned the motor on, but perhaps not as strongly (hard to tell with no load). Writing 50 resulted in the motor not starting. Writing 100 let the motor run if I started it by hand, but wouldn’t start the motor from a dead stop. I used this opportunity to point out that controlling the motor was not linear—1/5th didn’t run at 1/5th speed, but wouldn’t run the motor at all.

Next we switched over to doing sensors (with only 10 minutes left in the class). I got out the pressure sensor and instrumentation amp from the circuits course and hooked it up. The screwdriver I had packed in the box had too large a blade for the 0.1″ screw terminals, but luckily the tiny screwdriver on my Swiss Army knife (tucked away in the corkscrew) was small enough. After hooking up the pressure sensor to A0, I downloaded the Arduino Data Logger to the Uno, and started it from a terminal window. I set the triggering to every 100msec (which probably should be the default for the data logger), the input to A0, and convert to volts. I then demoed the pressure sensor by blowing into or sucking on the plastic tube hooked up to the sensor. With the low-gain output from the amplifier, the output swung about 0.5 v either way from the 2.5v center. Moving the A0 wire over to the high-gain output of the amplifier gave a more visible signal. I also turned off the “convert to volts” to show the students the values actually read by the Arduino (511 and 512, the middle of the range from 0 to 1023).

Because the class was over at that point, I offered to stay for another 10 minutes to show them how to use the pressure sensor to control the motor. One or two students had other classes to run to, but most stayed. I then wrote a program that would normally have the motor off, but would turn it full on if I got the pressure reading up to 512+255 and would turn it on partway (using PWM) between 512 and 512+255. I made several typos when entering the program (including messing up the braces and putting in an extraneous semicolon), but on the third compilation it downloaded successfully and controlled the motor as expected.

One student asked why the motor was off when I wasn’t blowing into the tube, so I explained about 512 being the pressure reading when nothing was happening (neither blowing into the tube nor sucking on it). I changed the zero point for the motor to a pressure reading of 300, so that the motor was normally most of the way on, but could be turned off by sucking on the tube. Here is the program we ended up with

#define nFET_GATE_PIN (3)

void setup()
{   pinMode(nFET_GATE_PIN, OUTPUT);
    pinMode(A0, INPUT);
}

void loop()
{ int pressure;
  pressure=analogRead(A0);
  if (pressure < 300)
  {    digitalWrite(nFET_GATE_PIN,LOW);  // turn motor off
  }
  else
  {   if (pressure>300+255)
      { digitalWrite(nFET_GATE_PIN,HIGH);  // turn motor on full
      }
      else
      {    analogWrite(nFET_GATE_PIN,pressure-300); // turn motor partway on
      }
  }
}

Note: this code is not an example of brilliant programming style. I can see several things that I would have done differently if I had had time to think about the code, but for this blog it is more useful to show the actual artifact that was developed in the demo, even if it makes me cringe a little.

Overall, I thought that the demo went well, despite being completely extemporaneous. Running over by 10 minutes might have been avoidable, but only by omitting something useful (like the feedback on the design reports). The demo itself lasted about 70 minutes, making the whole class run 80 minutes instead of 70. I think I compressed the demo about as much as was feasible for the level the students were at.

Based on how the students developed the first motor-control program quickly in class, I think that some of them are beginning to get some of the main ideas of programming: explicit instructions and sequential ordering. Because we were out of time by the point I got to using conditionals, I did not get a chance to probe their understanding there.

Over the last few years I’ve been writing a few Arduino tutorials, and during this time many people have mentioned that I should write a book. And now thanks to the team from No Starch Press this recommendation has morphed into my new book – “Arduino Workshop“:

Although there are seemingly endless Arduino tutorials and articles on the Internet, Arduino Workshop offers a nicely edited and curated path for the beginner to learn from and have fun. It’s a hands-on introduction to Arduino with 65 projects – from simple LED use right through to RFID, Internet connection, working with cellular communications, and much more.

Each project is explained in detail, explaining how the hardware an Arduino code works together. The reader doesn’t need any expensive tools or workspaces, and all the parts used are available from almost any electronics retailer. Furthermore all of the projects can be finished without soldering, so it’s safe for readers of all ages.

The editing team and myself have worked hard to make the book perfect for those without any electronics or Arduino experience at all, and it makes a great gift for someone to get them started. After working through the 65 projects the reader will have gained enough knowledge and confidence to create many things – and to continue researching on their own. Or if you’ve been enjoying the results of my thousands of hours of work here at tronixstuff, you can show your appreciation by ordering a copy for yourself or as a gift

You can review the table of contents, index and download a sample chapter from the Arduino Workshop website.

Arduino Workshop is available from No Starch Press in printed or ebook (PDF, Mobi, and ePub) formats. Ebooks are also included with the printed orders so you can get started immediately.

In the meanwhile have fun and keep checking into tronixstuff.com. Why not follow things on twitter, Google+, subscribe  for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

The post Book – “Arduino Workshop – A Hands-On Introduction with 65 Projects” appeared first on tronixstuff.

The Nerf gun prototype is coming along nicely.  The students have tested the launcher up to 120 psi, built a prototype tilt and pan mechanism in Lego, and today hooked up a small reservoir behind the solenoid valve on the barrel to a bigger reservoir using an air hose.

They hope to be able to keep the bigger reservoir up to pressure by occasionally turning on a 12v compressor.  The compressor takes 10A and can’t be run for very long at a time (it brings the system up to 120psi  from 0psi in about 15 seconds), so they’ll have to run it off a relay.  I couldn’t find cheap relays that looked easy to use with 5v control and 12v 10A contacts, but automotive relays are cheap (I found 5 relays and 5 sockets for $5 on Amazon AGT (5 Pack) 30/40 AMP Relay Harness Spdt 12V Bosch Style (40AMP-HRNS)—even with shipping that is only $2.25 each for relay plus socket).  The relay can be controlled by half an H-bridge of the Hexmotor board.  The other half of the H-bridge controlling the solenoid should be fine, as we never need to run the compressor and fire at the same time—we can stop the compressor for a fraction of a second while firing.

They want to have the running of the compressor be automatic, which would require a pressure sensor.  The Freescale MPX5999D would work and is one of the few sensors I’ve seen with a large enough range, but I’m not sure how to mount it.  Standard tire-pressure monitoring sensors and transmitters are cool, but I don’t know if they go up to high enough pressures and I don’t know how to interface to their transmitters—that is almost certainly a more expensive solution. Honeywell has a differential sensor with ports that will go to ±150psi, which may be easier to connect up, but it costs about twice as much and is uncompensated and unamplified: I suspect it would be a lot fussier to work with than the Freescale part.  I’ve ordered a sample of the Freescale part, and read their AN936 application note on mounting (epoxy is your friend).

It turns out that the relays may be useful for other functions, like a linear actuator for the tilt mechanism. Two relays can be controlled from one H-bridge to get forward-backward-stop action on motors up to 30 amps (but no PWM!). Unfortunately, 12v linear actuators seem to run $100 and up, which is more that I want to spend on a single part.  I may ask the students to redesign—either building their own lead-screw mechanism or coming up with a different tilt mechanism.  I don’t think a simple servo motor will do—the beefiest one I have claims only 69 oz-in (0.49 Nm) of torque, which I don’t think will be enough to tilt the gun, even if they can get the hinge very close to the center of gravity.

Another problem has come up: getting more darts.  We have 5 darts that fit the barrel perfectly (1.45cm diameter).  There are plenty of darts sold like that, but they almost all now have larger heads on the end, and the heads don’t slide down the barrel.  The new Nerf clip-system darts are all mini-darts, that have a 0.5″ (1.25cm) diameter instead.  These do not fire well from the ½” PVC, which I measured as having an ID of 1.485cm (0.585″). A chart of PVC sizes I found on line says that 1/2″ ID Schedule 40 PVC is supposed to have an inside diameter of 0.622″, which is almost 5/8″, but that ID can vary by 10%, even along a single piece of pipe—only OD is held to tight specs.  Thicker-walled Schedule 80 is supposed to have 0.546″ ID, which would still be too loose for clip-system darts.

I see four possible solutions:

• Find a source of (probably non-Nerf) foam darts that are 1.45cm (9/16″) diameter with heads that are no wider than the body. I think that they came with an NXT generation crossbow, so replacement foam darts for that may be what we need. They’re nowhere near as cheap as clip-system darts, but this is still probably the cheapest solution.
• Buy Nerf  (or other) darts with the right size bodies but oversize heads, remove the heads, and make new ones (out of what?). This would be cheap, but tedious, and the darts would probably fly poorly, unless we made the new heads have a decent weight.
• Use clip-system darts for compatibility with the popular Nerf guns, but find a smaller diameter tube than the ½” PVC pipe (where? and how would it be connected to the solenoid valve?) It looks like Schedule 40 3/8″ steel pipe has a inside diameter of 0.49″, which is just right, but steel pipe is rather heavy.
• Use clip-system darts, but convert to the Nerf-standard tube-inside-the-dart launching system.  This limits the effective barrel length to the inside length of the dart (about 4.5cm) and the barrel diameter to the inside diameter of ¼”, which will limit the top speed of the darts (OK for safety, but probably not as much fun).

So [RobB] wanted to take out all the light switches in his house. His plan was to replace them with a system that could be operated from his smart phone. But his wife insisted that there still must be some way to control the lighting directly — we have to agree with her on that one. The solution was to develop a system that switches the lights via a touch sensor or by Bluetooth.

The touch part of the project is pretty easy. He coated the back of a blank outlet plate with tin foil and hooked it to a microcontroller with a couple of resistors. He’s using an ATtiny85, which can be programmed using Arduino sketches, so the software side is made easy by the CapSense Library. The chip also uses the software serial library to communicate with a Bluetooth module. You can see the result of both in the demo video after the break.

Of course you need to throw a relay in there to switch mains, and find a way to power the uC and Bluetooth module. [RobB] went with a tiny plug-in USB power converter and managed to fit everything in a single-gang switch.