The Raspberry Pi and other similar Linux-based single board computers simplify many projects. However, one issue with Linux is that it doesn’t like being turned off abruptly. Things have gotten better, and you can certainly configure things to minimize the risk, but–in general–shutting a Linux system down while it is running will eventually lead to file system corruption.

If your project has an interface, you can always provide a shutdown option, but that doesn’t help if your application is headless. You can provide a shutdown button, but that leaves the problem of turning the device back on.

[Ivan] solved this problem with–what else–an Arduino (see the video below). Simplistically, the Arduino reads a button and uses a FET to turn off the power to the Pi. The reason for the Arduino, is that the tiny processor (which draws less than a Pi and doesn’t mind being shut down abruptly) can log into the Pi and properly shut it down. The real advantage, though, is that you could use other Arduino inputs to determine when to turn the Pi on and off.

For example, it is easy to imagine a Pi in an automotive application where the Arduino would sense the ignition was off for a certain period of time and then go ahead and shut off the Pi. Or maybe the Pi needs to be turned on when a motion sensor fires and then turned off again once there is no motion for a particular time period. Any of these strategies would be simple to build with the Arduino.

We’ve seen a similar project that used an IR remote as the trigger instead of a physical button. If you are afraid the Pi will just lose power unexpectedly, you might consider a battery backup. If powering a Pi with regular electricity is too tame for you, try steam.

[John Fin] put a lot of work into his Ghostbuster’s proton pack prop with full-featured user control and effects. What appealed to us well beyond the exquisite build is the extra effort taken to write down the whole process in a PDF for anyone wishing to imitate him.

We all know that a lot of famous props are creatively rearranged household items. The famous Mr. Fusion from Back to The Future is actually a Krups coffee grinder with some logos adhered.

[John]’s prop is no different. The cyclotron is a five gallon bucket. A garlic powder container fills another function. As you look at it more and more items can be picked out. Is that a spark plug wire? The handles on that are suspiciously similar to a power tool case’s. It all comes together, and while it’s not screen accurate you’d have to be an extreme prop fanatic to tell.

Naturally, the core of [John]’s prop is an Arduino. It stores the sound files on a SD Card shield. It controls all the lights sounds and motors on the prop. This isn’t quite a point and shoot. You must toggle on the power, generator, and arming mechanisms before actually firing. If you do it out of order, the electronics will issue an alarm as warning, and each step in the process has its own unique audio and animated lighting.

Since the Proton Pack went so well, he also built a PKE meter and Ghost Trap to go along with his backpack. He’s ready to take on Vigo at anytime. You can see a video of his prop in action after the break.

Numbers are wonderful things when applied to technical specifications. Take [Bobricius]’ handheld Arduino-based game console. With an 8×8 LED matrix for a display it’s not going to win any prizes, but while he’s pushing the boundaries of dubious specification claims he’s not strictly telling any lies with his tongue-in-cheek statement that the graphics are 64-bit.

Jokes aside, it’s a neatly done build using a DIP version of the Arduino MCU and all through-hole components on a custom PCB. Power comes from a CR2032 cell, and it includes three buttons and a small piezoelectric speaker. He’s implemented a whole slew of games, including clones of Pong, Breakout, and Tetris, and judging by the video below it’s surprisingly playable.

Now you might look at this console and wonder what the big deal is. After all, there are plenty of similar designs to be found, and it’s nothing new. Of course, it’s a neat project for any hacker or maker, but we can see that this would make a great starter project for the younger person in your life who wants to try their hands at building something electronic. All through-hole construction for easy soldering, and a neat game at the end of it all.

He’s posted a full write-up of the design process as well as the hackaday.io page linked above, so if you fancy building one yourself there’s nothing to stop you too squeezing 64 bits of graphical goodness from an Arduino.

This isn’t the first Arduino game we’ve shown you here at Hackaday, we’ve unmasked the secrets of the Arduinocade, featured another handheld Arduino game with an LCD screen, and a beautifully coded console using a TFT among many more.

Last fall, I grabbed a robot arm from Robot Geeks when they were on sale at Thanksgiving. The arm uses servos to rotate the base and move the joints and gripper. These work well enough but I found one aspect of the arm frustrating. When you apply power, the software commands the servos to move to home position. The movement is sufficiently violent it can cause the entire arm to jump.

This jump occurs because there is no position feedback to the Arduino controller leaving it unable to know the positions of the arm’s servos and move them slowly to home. I pondered how to add this feedback using sensors, imposing the limitation that they couldn’t be large or require replacing existing parts. I decided to try adding accelerometers on each arm section.

Accelerometers, being affected by gravity when on a planet, provide an absolute reference because they always report the direction of down. With an accelerometer I can calculate the angle of an arm section with respect to the direction of gravitational acceleration.

Before discussing the accelerometers, take a look at the picture of the arm. An accelerometer would be added to each section of the arm between the controlling servos.

Accelerometers

Gravity tugs everything toward the center of the mass of the Earth. It is a force that creates an acceleration exactly just like what you feel when a vehicle begins to move or stop. The force of gravity creates an acceleration of 1 g which is 9.8 m/s² or 32.15 ft/s². An accelerometer measures this force.

Integrated circuit accelerometers are inexpensive and small devices readily usable by hackers. One reason they are inexpensive is the high demand for them in smart phones. These small devices are based on etching mechanical structures within the integrated circuit using a technology called MEMS (Microelectromechanical systems).

One design for a MEMS accelerometer is basically a variable capacitor. One plate is fixed and the other mounted some distance away on a spring suspension. When the device is accelerated the suspended plate moves closer or further away from the fixed plate, changing the capacitance. Another uses piezo-resistive material to measure the stress on an arm caused by acceleration.

A single axis accelerometer measures acceleration in only one direction. If positioned so the direction is up and down it will measure the force of gravity but will not detect horizontal acceleration. When the device is tilted between horizontal and vertical the force of gravity is only partially affecting the measurement. This provides the ability to measure the angle of the device with the direction of gravity. The acceleration felt along the tilted axis, for a tilt angle can be calculated by:

Knowing the output of the accelerometer we can determine the angle by taking the inverse sine, the arc sine, of the output:

If you rotate a single axis device through 360° the output is a sine wave. Start with the device outputting zero and consider that 0°. As it rotates, the output is 1 when the angle is 90° and back to zero at 180°. Continuing the rotation, the output becomes -1 at 270°, or -90°, degrees and back to zero at 360°, or 0°.

Notice on the chart that between -60° and 60° the output is nearly linear. This is the best orientation for measuring inclination. Increases in inclination are not as accurate on the other portions of the curve. Also notice that the same output is generated for 45° and 135° (90° + 45°) creating an ambiguity. With a single axis you cannot determine which of those angles is measured.

Putting two accelerometers at a right angle to one another creates a 2-axis device which solves the ambiguity problem. As the device is rotated through 360° the outputs are 90° out of phase, the same relationship as the sine and cosine. By combining the measurements there is a unique solution for every angle throughout 360°. The acceleration due to gravity at each angle is given by:

which leads to calculating the angle by:

Actually, one more step is needed to determine the sign of the angle. This requires examining the sign of the values for the X and Y axis. It isn’t necessary to go into this here because a standard programming function handles this automatically.

The orientation of a quadcopter requires a 3-axis accelerometer. The calculations for the three spherical angles combine all three inputs for their results. You’ll need to study this carefully because the standard trigonometric equations can cause anomalies when the quadcopter flips.

First Pass Solution

Accelerometers are easily obtained and relatively cheap. You can find them mounted on breakout boards with voltage regulators and all the supporting circuits from the usual vendors. They are available for 1 to 3 axis, various amounts of g force, and providing either analog or digital outputs. Analog devices need an analog input for each axis being measured. Digital outputs use I²C or SPI buses for communications. I decided to use analog devices because digital units typically only allow two addresses and the arm needs three devices, one for each section.

The robot arm uses an Arduino board so there are at least 6 analog inputs. The original board was a Robot Geek Geekduino, their version of the Arduino Duemilanove, with 8 analog inputs. Unfortunately, when working with the arm I broke the USB connector so switched to a Uno equivalent having only 6 inputs.

My choice for accelerometer is a 3-axis, ±3 g accelerometer breakout from Adafruit, their ADXL335. It has one analog output for each axis. Since I’m measuring three joints that means three boards which adds up to 9 analog outputs.

Because of the geometry of the arm, however, I only need 5 inputs for these three joints. The shoulder joint only moves from 0° to 180°. This can be handled by a single axis accelerometer by mounting it to read acceleration of 1 g for 0° and -1g for 180°. That provides a unique output for the necessary angles. The elbow and wrist joints each require two inputs. The third input is not needed because their motion is constrained to moving within the vertical plane of the arm.

Frame of Reference

The next issue is the frame of reference. This is a standard problem in robotics work. Early in a project, a global frame of reference is decided upon. This sets the origin for the coordinate system that the robot will follow and the direction of the three axes, usually specified as X, Y, and Z. For the arm, X is straight forward, Y is to the left, and Z is straight up. The zero point is the base of the shoulder. This also defines a global frame for rotation of the arms limbs with zero degrees also toward the front.

Sensors and controllers each have their own frame of reference. Any differences among these devices and the global frame need to be resolved in software. The shoulder servo’s frame of reference is 0° at the back of the arm and 180° at the front, a clockwise rotation. This is the reverse of the global frame. The elbow servo worked the opposite with a counter-clockwise rotation putting 180° straight up and 90° straight out when the shoulder was vertical. It is 90° off from the global frame of reference.

Sensors also have their own frame of reference. The Y-axis accelerometer measuring the shoulder orientation worked counter-clockwise. Both axis on the accelerometers measuring the elbow worked in the clock-wise direction. This may seem strange but it’s because of the different mounting orientations of the sensors.

Software

The actual code is straightforward once the frame of references are sorted out. A single axis is read from the analog input and its angle calculated with:

const int shouldery = shoulderAnalogY.read();
float shoulder_angle = degrees(asin(shouldery_value / 100.0));

The read() method scales the raw analog input values so ±1g is represented as ±100. The input to asin() is divided by 100.0 to convert to the actual g value. That suffices for the shoulder angle.

The elbow and wrist angles use values from two axis and the calculation is:

const int elbowx = elbowAnalogX.read();
const int elbowy = elbowAnalogY.read();
float elbow_angle = degrees(atan2(-elbowy, elbowx));

The atan2() function is a special version of the arc tangent calculation. It examines the signs of the input value to determine the quadrant of the angle to set the appropriate sign on its result. The negative sign on the elbowy is needed to set the appropriate quadrant. There’s the frame of reference issue, again.

Wrap Up

Adding the accelerometers solved the startup lurching problem well enough. Whether the accelerometers can be used for other purposes remains to be seen.

The accuracy of the angle measurements is not good. In part this is due to using a device that with a +/- 3 g range to measure 1/3 of the devices range, 1 g. The device outputs 0 to 3.3 volts while the Arduino is sampling for 5 volts, again losing accuracy. This might be improved by using an Arduino based on 3.3 volts. I have a couple Dues on hand so might try them. The Uno also provides for adjusting the reference voltage for analog inputs so setting it to 3.3 volts might help.

The analog values need to be calibrated with some care. Each accelerometer outputs slightly different values. Calibration requires measuring the outputs for 1 and -1 g for each axis, recording the values, and using them to scale the voltage input to acceleration. This calibration is not accurate given the other problems with the analog inputs.

Another problem is the mounting of the accelerometers on the arm’s sections. The alignment of the boards with the sections of the arm is not perfect. When the servo is positioned at 90° the accelerometer doesn’t necessarily sit at 90° with respect to the center of the earth. Of course, the servos are not that precise, either. They do not always arrive at the same position, especially when approaching from different directions. Another goal for this project was to use the accelerometer information to more precisely position the servos.

I guess I have to think about this project a bit more, including deciding what I actually want to accomplish with the arm. But then, just saying you have a robotic arm is a terrific hacking cred.

Kids love Minecraft, and a clever educator can leverage that love to teach some very practical skills. The summer class offered by the Children’s Museum in Bozeman Montana would have blown my mind if such a thing existed when we were younger. (Rather than begging one of the dads in my Boy Scout Troop to pirate Visual Studio for me, which was delivered in the form of an alarmingly tall stack of CDs.) The kids in Bozeman get to learn hardware, software, their integration, and all while playing Minecraft.

Minecraft is an immersive universe that has proven to suck in creative minds. It’s the bait that pulls the kids into the summer class but Serialcraft delivers on making the learning just as addictive. This is accomplished by providing students with physical objects that are tied to the Minecraft world in meaningful ways we just haven’t seen before (at least not all at one time). On the surface this adds physical LEDs, toggle switches, potentiometers, and joysticks to the game. But the physical controls invite understanding of the mechanisms themselves, and they’re intertwined in exciting ways, through command blocks and other in-game components that feel intuitive to the students. From their understanding of the game’s mechanics they understand the physical objects and immediately want to experiment with them in the same way they would new blocks in the game.

The thing that makes this magic possible is a Minecraft mod written by [John Allwine], who gave us a demonstration of the integration at Maker Faire Bay Area 2016. The mod allows the user to access the inputs and output of the Arduino, in this case a Pololu A-Star 32U4, from within Minecraft. For the class this is all packaged nicely in the form of a laser cut controller. It has some LEDs, two joysticks, buttons, potentiometers, and a photosensor.

As you can see in the video below the break, it’s really cool. The kids have a great time with it too. For example, [John] showed them how they can attach their unique controller to a piston in the world. Since this piston can be controlled by them alone, they quickly figured out how to make secret safe rooms for their items.

Another troublesome discovery, was that the photo transistor on the controller set the light level in the game world by altering the time of day. Kids would occasionally get up and change the world from day to night, by turning the lights in the room on or off. A feature that has a certain appeal for any Minecraft player, is rigging one of the LEDs on the controller to change brightness depending on proximity to a creeper.

There’s a lot more to the library, which is available on GitHub. The kids (and adults) have a great time learning to link the real world with the world’s most accessible fantasy world creation kit.  Great work [John]!

If necessity is the mother of invention, then inconvenience is its frustrating co-conspirator. Faced with a finicky dryer that would shut down mid-cycle with a barely audible beep if its load was uneven (leaving a soggy mass of laundry), [the0ry] decided to add the dryer to the Internet of Things so it could send them an email whenever it shut itself down.

After opening a thinger.io account, adding the soon-to-be device, and setting up the email notification process, [the0ry] combined the ESP8266 Development Board, a photosensitive resistor, and a 5V power supply on a mini breadboard. All that was left was to mount it on the dryer and direct the LDR (light-dependent resistor) to the machine’s door lock LED to trigger an email when it turned off — indicating the cycle had finished or terminated prematurely. A little tape ensured the LDR would only be tripped by the desired light source.

If you’re an apartment-dweller have WiFi in the wash area it would be awesome to see a battery-powered version you take with you. But in general this is a great hardware blueprint as many device have status LEDs that can be monitored in a similar way. If you want to keep the server in-house (literally in this case) check out the Minimal MQTT series [Elliot Williams] recently finished up. It uses a Raspberry Pi as the center server and an ESP8266 is one of the limitless examples of hardware that plays nicely with the protocol.

We love seeing hacks like this because not only does it conserve water and energy by reducing instances of rewashing, but it’s also a clever way to extend the life of an appliance and potentially save hundreds of dollars in replacing it. Add this to the bevvy of hacks that add convenience to one’s home — some of which produce delicious results.

Sometimes when browsing the websites of our global hackspace community you notice a project that’s attractive not necessarily because of what it does or its technology but because of its presentation. So it is with the subject of this article, [Kris] needed a house temperature monitor and found a 1960s slide viewer made an excellent choice for its housing.

The monitor itself is a fairly straightforward Arduino build using a couple of DS18B20 1-wire temperature sensors and a real-time-clock module and displaying their readings on a small OLED screen. Its code can be found on this mailing list thread if you are interested. The display presented a problem as it needed to be reasonably large, yet fairly dim so it could be read at night without being bright enough to interrupt sleep.

A variety of projection techniques were tried, involving lenses from a projection clock, a magnifying glass, and a Google Cardboard clone. Sadly none of these lenses had the required focal length. Eventually the slide viewer was chosen because it was pointed out that the OLED screen was about the same size as a photographic slide.

Slide viewers are part of the familiar ephemera of the analog era that most people over 60 may still have taking up drawer space somewhere but may well be completely alien to anyone under about 30. They were a magnification system packaged up into a console usually styled to look something like a small portable TV of the day, and different models had built-in battery lights, or collected ambient light with a mirror. The screen was usually a large rectangular lens about 100mm(4″) diagonal.

[Kris]’s Vistarama slide viewer came via eBay. It’s not the smallest of viewers, other models folded their light paths with mirrors, however the extra space meant that the Arduino fit easily. The OLED was placed where the slide would go, and its display appeared at just the right magnification and brightness. Job done, and looking rather stylish!

We’ve not featured a slide viewer before here at Hackaday, though we did recently feature a similar hack on an Ikea toy projector. We have however featured more than one digital conversion on a classic slide projector using LCD screens in place of the slide.

Via Robots and Dinosaurs makerspace, Sydney.

Lots of us get to take home a little e-waste from work once in a while to feed our hacking habits. But some guys have all the luck and score the really good stuff, which is how these robotic surgical tools came to be gesture controlled.

The lucky and resourceful hacker in this case is one [Julien Schuermans], who managed to take home pieces of a multi-million dollar da Vinci Si surgical robot. Before anyone cries “larcency”, [Julien] appears to have come by the hardware legitimately – the wrist units of these robots are consumable parts costing about $2500 each, and are disposed of after 10 procedures. The video below makes it clear how they interface with the robot arm, and how [Julien] brought them to life in his shop. A quartet of Arduino-controlled servos engages drive pins on the wrist and rotates pulleys that move the cables that drive the instruments. A neat trick by itself, but when coupled with the Leap Motion controller, the instruments become gesture controlled. We’re very sure we’d prefer the surgeon’s hands on a physical controller, but the virtual control is surprisingly responsive and looks like a lot of fun.

When we talk about da Vinci around here, it’s usually in reference to 3D printers or a Renaissance-style cryptex build. Unsurprisingly, we haven’t featured many surgical robot hacks – maybe it’s time we started.

[via r/arduino]

A stock Arduino isn’t really known for its hi-fi audio generating abilities. For “serious” audio like sample playback, people usually add a shield with hardware to do the heavy lifting. Short of that, many projects limit themselves to constant-volume square waves, which is musically uninspiring, but it’s easy.

[Connor]’s volume-control scheme for the Arduino bridges the gap. He starts off with the tone library that makes those boring square waves, and adds dynamic volume control. The difference is easy to hear: in nature almost no sounds start and end instantaneously. Hit a gong and it rings, all the while getting quieter. That’s what [Connor]’s code lets you do with your Arduino and very little extra work on your part.

The code that accompanies the demo video (which is embedded below) is a good place to start playing around. The Gameboy/Mario sound, for instance, is as simple as playing two tones, and making the second one fade out. Nonetheless, it sounds great.

Behind the scenes, it uses Timer 0 at maximum speed to create the “analog” values (via PWM and the analogWrite() command) and Timer 1 to create the audio-rate square waves. That’s it, really, but that’s enough. A lot of beloved classic arcade games didn’t do much more.

While you can do significantly fancier things (like sample playback) with the same hardware, the volume-envelope-square-wave approach is easy to write code for. And if all you want is some simple, robotic-sounding sound effects for your robot, we really like this approach.

There are a ton of applications that we use that can benefit from keyboard shortcuts, and we use ’em religiously. Indeed, there are some tasks that we do so often that they warrant their own physical button. And the only thing cooler than custom keyboards are custom keyboards that you’ve made yourself.

Which brings us to [Dan]’s four-button Cherry MX USB keypad. It’s not really all that much more than four keyswitch footprints and an AVR ATmega32u4, but that plus some software is all you really need. He programs the Arduino bootloader into the chip, and then he’s using the Arduino Leonardo keyboard libraries. Bam! Check out the video below.

We see this design much more as a demo or collection of building-blocks than necessarily a one-size-fits-all solution. You might need five buttons, or want a different layout, or… It’s all open-source, so go nuts. And you’re not limited to key-clicks either — mouse buttons or even multiple scripted actions are within easy reach.

Building a special-function USB keypad or gaming device used to be hard work. But today between hardware and software design availability, it’s child’s play. Whether you need a footboard, a single-handed chording keyboard, or even just to update an old typewriter, the ability to control the input device that we use for eight hours per day is liberating. Experiment!