Hackaday Prize Entry: Powering A Pi From A Battery

May 11, 2016 by Moritz Walter 28 Comments

Knocking a microcontroller into sleep mode and waking it up on demand or in intervals is common practice in many low power applications, enabling devices to stay in operation for years on a single coin cell battery. Since there are tons of applications where you might want to do similar things with a Raspberry Pi, [Patrick Van Oosterwijck] created the LiFePO4wered/Pi. The module that snaps on to eight GPIO pins of a Pi, extending it by a long life LiFePO4 battery, a charging regulator, and a proper power management. Obviously, it also makes a great UPS.

[Patrick] realized this project by expanding his already available and equally useful LiFePO4wered/USB charging regulator module by a low power MSP430G2131 microcontroller and a load switch. A daemon on the Raspberry Pi speaks to the module over I2C, allowing you to schedule a wake-up timer, let your Pi autoboot after a power outage or just read out the current battery voltage through a command line tool. Once the Pi is safely shut down, the microcontroller will also go to sleep, resulting in a standby current of 8 uA for the whole system. Together with the 500 mAh LiFePo4 cell, that’s theoretically low enough to send your Pi-ncess into a seven-year-long sleep.

LiFePO4wered/Pi is not only good for sleeping, though. [Patrick’s] runtime tests show, that the 500 mAh cell will power a Raspberry Pi Zero and a WiFi dongle for about two hours. Because the Raspberry Pi and many USB peripherals won’t complain when only 3.2 V are present on the VBUS, [Patrick] was able to squeeze out even more runtime by dismissing the boost converter from the design and driving the Pi directly from the battery voltage. If that worries you, you can either read a detailed explanation on why that works so well or just have a look at the more compliant 5 V version.

Eventually, [Patrick] used his module to create a Raspberry Pi time-lapse camera. A little script lets the Pi take a picture on boot up, set a wake-up timer and go back to sleep again. Safely enclosed in a waterproof electric box and deployed into the wild, the camera took 120 pictures on a single charge.

We’re sure the module will find it’s way into many cool projects and we’re counting the hours until we can get one in [Patrick’s] tindie store. Until then, enjoy the time-lapse video:

The HackadayPrize2016 is Sponsored by:

Concrete Table Just The Way You Like It

May 11, 2016 by Gerrit Coetzee 14 Comments

You need a coffee table, you need a dinner table. Do you really need two tables? [Shua] thinks the answer is “no”. That’s why he built this swinging countersink table out of concrete and a aluminum.

He started by making a simple half-scale prototype. Then a larger one. Through these explorations he learned how the table would be made, what kind of weight it needed, and how the mechanics needed to be constructed for the most stable table top.

Next he designed the final table in Autodesk Revit. This is software traditionally used for architecture. Since the table was to be made from concrete Revit’s useful set of concrete tools were useful for this project.

Most of the construction process was pretty standard. However, the use of CNC’d pink insulation as a mold for the concrete was interesting. The foam is closed cell, so it worked fine and gave a nice finish. The assembly was finished with a glass top and a carpeted base that contained a surge suppressor and two outlets. The table can be seen swinging between two positions in a video after the break.

Continue reading “Concrete Table Just The Way You Like It” →

Converting Kids’ Hand-Drawings To G-Code

May 11, 2016 by Steven Dufresne 12 Comments

[Martin Raynsford] wrote a program that converts a black-and-white 2D image to G-code so that his laser printer could then etch the image. Not satisfied with just that, he used his laser printer to make a scanner that consists of a stand for his webcam and a tray below it for positioning the paper just right. The result was something he took to a recent Maker Faire where many kids drew pictures on paper which his system then scanned and laser etched.

Screenshot of Martin's scanning and G-code maker program — Martin’s scanning and G-code maker program

[Martin’s] program, written in C#, does the work of taking the image from the webcam using OpenGL and scanning it line by line looking for pixels that surpass a contrast threshold. For each suitable pixel the program then produces G-code that moves the laser to the corresponding coordinate and burns a hole. Looking at the source code (downloadable from his webpage) it’s clear from commented-out code that he did plenty of experimenting, including varying the laser burn time based on the pixel’s brightness.

While it’s a lot of fun writing this code as [Martin] did, after the break we talk about some off-the-shelf ways of accomplishing the same thing.

Continue reading “Converting Kids’ Hand-Drawings To G-Code” →

TV Stick Out-Raspberries Raspberry Pi

May 11, 2016 by Al Williams 24 Comments

Android-based TV sticks should be in more projects. They are readily available and inexpensive. They have a lot of horsepower for the price, and they can even boot a mainline Linux kernel, unlike some single-board computers we know. They’re smaller than the Pi Zero, so they’ll fit almost anywhere.

The one thing they don’t have, though, is I/O. Sure, it’s got a USB port, but that’s just about it. [Necromant] considered these problems and created a carrier board that fixes all that.

On-board 3A DC-DC. You can power the whole thing with anything from 7 to 24 volts DC
A 4-Port USB hub
An ATtiny 2313, connected to the hub via the V-USB stack
2 USB ports on the back, with power control via GPIO lines
One USB port on the front (with power always on)
3 relays
Fits a common anodized aluminum enclosure

The ATtiny code is on GitHub and allows for full I/O control, saving the state of the pins in EEPROM, and providing up to eight channels of servo control. The device connects through the USB port (consuming one port on the hub).

Repurposing consumer gear for embedded service is nothing new. We’ve seen it with phones. We’ve even seen remotes used as a mouse. But this is such a nice template for adding cheap and easy computing power to your projects that we’re surprised we don’t see it more often. Why aren’t you hacking a TV stick into your projects?

Mike Szczys Ends 8-Bit Vs 32-Bit Holy War!

May 11, 2016 by Elliot Williams 102 Comments

If you’ve read through the comments on Hackaday, you’ve doubtless felt the fires of one of our classic flame-wars. Any project done with a 32-bit chip could have been done on something smaller and cheaper, if only the developer weren’t so lazy. And any project that’s squeezes the last cycles of performance out of an 8-bit processor could have been done faster and more appropriately with a 32-bit chip.

Of course, the reality for any given project is between these two comic-book extremes. There’s a range of capabilities in both camps. (And of course, there are 16-bit chips…) The 32-bit chips tend to have richer peripherals and run at higher speeds — anything you can do with an 8-bitter can be done with its fancier cousin. Conversely, comparatively few microcontroller applications outgrow even the cheapest 8-bitters out there. So, which to choose, and when?

Eight Bits are Great Bits

The case that [Mike] makes for an 8-bit microcontroller is that it’s masterable because it’s a limited playground. It’s a lot easier to get through the whole toolchain because it’s a lot shorter. In terms of debugging, there’s (often) a lot less that can go wrong, letting you learn the easy debugging lessons first before moving on to the truly devilish. You can understand the hardware peripherals because they’re limited.

And then there’s the datasheets. The datasheet for a chip like the Atmel ATMega168 is not something you’d want to print out, at around 660 pages long. But it’s complete. [Mike] contrasts with the STM32F405 which has a datasheet that’s only 200 pages long, but that’s just going over the functions in principle. To actually get down to the registers, you need to look at the programming manual, which is 1,731 pages long. (And that doesn’t even cover the various support libraries that you might want to use, which add even more to the documentation burden.) The point is, simpler is simpler. And if you’re getting started, simpler is better.

Continue reading “Mike Szczys Ends 8-Bit Vs 32-Bit Holy War!” →

Open Robots With Open Roberta

May 11, 2016 by Elliot Williams 11 Comments

Kids, and Hackaday editors, love robots! The Open Roberta project (OR) takes advantage of this to teach kids about programming. And while the main focus is building a robot programming language that works for teaching grade-school and high-school kids, it’s also a part of a large open source robotics ecosystem that brings a lot more to the table than you might think. We talked with some folks at Google, one of the projects’ sponsors, about where the project is and where it’s going.

Building a robot can be very simple — assembling pre-configured parts or building something small, quick, and cute — or it can be an endeavour that takes years of sweat and tears. Either way, the skills involved in building the ‘bot aren’t necessarily the same as those it takes to program the firmware that drives it, and then eventually the higher-level software that makes it functional and easy to drive.

OR, as an educational project, makes it very, very easy for kids to start off programming robots, but it’s expandable as the user gets more experienced. And since everything is open source, it’s part of a whole ecosystem that makes it even more valuable. We think it’s worth a look (along with something significantly more complex like ROS) if you’re playing around with robotics.

System Architecture

Open Roberta is the user-facing middleware in a chain of software and firmware bits that make a robot work in a classroom environment. For the students, everything runs inside a browser. OR provides a webserver, robot programming interface and language, and then converts the output of the students’ programs to something that can be used with the robots’ firmware. The robots that are used in classrooms are mostly based on the Lego Mindstorms EV3 platform because it’s easy to put something together in short order. (But if you don’t have an EV3, don’t despair and read on!)

The emphasis is on ease of entry for the students and the teachers supervising the class. Everything runs in a browser, so there’s nothing to install on the client side. The students connect to a server that directs the robots, communicating with the robots’ own operating system, and uploading the students’ programs.

Continue reading “Open Robots With Open Roberta” →

Peachy Printer Collapses, Investor Built A House Instead Of A Printer

May 11, 2016 by Brian Benchoff 169 Comments

The Peachy Printer, originally a crowdfunding campaign for a $100 stereolithography 3D printer, is now dead in the water.[Rylan Grayston], the creator of the Peachy Printer, announced that [David Boe] — investor, 50% owner of Peachy Printer, and business partner — had stolen over $300,000 in Kickstarter campaign funds. According to [Rylan], this money was used to build a house.

An example print from the Peachy Printer Kickstarter campaign

When the Peachy Printer was announced on Kickstarter, it was, by any measure, a game changing product. Unlike other stereolithographic printers like the Form 1 and DLP projector kit printers, the Peachy was cheap. It was also absurdly clever. Instead of using a stepper motor to raise a print out of a vat of resin, the Peachy Printer floated the resin on a vat of salt water. By slowly dripping salt water into this vat, the level of the resin rose up, allowing the galvanometers and laser diode to print the next layer of a 3D object. In our first coverage of the Peachy Printer, everyone was agog at how simple this printer was. It wasn’t a high-resolution printer, but it was a 3D resin printer that only cost $100. Even today, nearly three years after the launch of the Kickstarter campaign, there’s nothing like it on the market.

For the last two years, [Rylan] appeared to have the Peachy Printer in a pseudo-stealth mode. Whispers of the Peachy Printer circled around 3D printer forums, with very little information coming from [Rylan]. For the last year, the Peachy Printer appeared to be just another failed crowdfunded 3D printer. Either [Rylan] didn’t have the engineering chops to take a novel device to market, there were problems with suppliers, or [Rylan] just couldn’t get the product out the door.

In the update published to the Kickstarter campaign, the reason for the failure of Peachy Printer to deliver becomes apparent. The Kickstarter campaign was set up to deliver the funds received – $587,435.73 – directly into [David Boe]’s account. Thirty days after the funds were received, [David] had spent over $165,000. In just over three months, all the Kickstarter funds, save for $200,000 transferred into the Peachy Printer corporate account, were spent by [David].

With no funds to complete the development of the Peachy Printer, [Rylan] looked into alternative means of keeping the company afloat until Kickstarter rewards had shipped. Peachy Printer received two government grants totalling $90,000 and $135,000. In March of 2015, one of [Rylan]’s family members loaned $50,000 to Peachy Printer. A plan to finance the delivery of Kickstarter rewards with new sales – a plan that is usually looked down upon by Kickstarter backers – was impossible, as cost and time required of certifying the laser in the Peachy Printer would have put the company in the red.

Right now, [Rylan] and the Peachy Printer are pursuing repayment from [David Boe], on the basis that Kickstarter reward money is still tied up in the construction of a house. Once the house is complete, the bank will disburse funds from the construction mortgage, and funds can then be transferred from [David] to Peachy Printer.

In all, the Peachy Printer is a mess, and has been since the Kickstarter funds were disbursed to [David]. There is – potentially – a way out of this situation that gets Peachy Printers into the hands of all the Kickstarter backers if the mortgage construction funds come through and production resumes, but that’s a lot of ‘ifs’. Failed Kickstarter projects for 3D printers are nothing new, but [Rylan]’s experience with the Peachy Printer is by far the most well-documented failure of a crowdfunding project we’ve ever seen.