It’s pretty common to grab a USB webcam when you need something monitored. They’re quick and easy now, most are plug-and-play on almost every modern OS, and they’re cheap. But what happens when you need to monitor more than a few things? Often this means lots of cameras and additional expensive hardware to support the powerful software needed, but [moritz simon geist] and his group’s Madcam software can now do the same thing inexpensively and simply.
Many approaches were considered before the group settled on using PCI to handle the video feeds. Obviously using just USB would cause a bottleneck, but they also found that Ethernet had a very high latency as well. They also tried mixing the video feeds from Raspberry Pis, without much success either. Their computer is a pretty standard AMD with 4 GB of RAM running Xubuntu as well, so as long as you have the PCI slots needed there’s pretty much no limit to what you could do with this software.
At first we scoffed at the price tag of around $500 (including the computer that runs the software) but apparently the sky’s the limit for how much you could spend on a commercial system, so this is actually quite the reduction in cost. Odds are you have a desktop computer anyway, and once you get the software from their Github repository you’re pretty much on your way. So far the creators have tested the software with 10 cameras, but it could be expanded to handle more. It would be even cooler if you could somehow incorporate video feeds from radio sources!
Yesterday, there was a Hackaday post for a Kickstarter campaign. Because we force everyone to read every Hackaday post, there were some complaints and suggestions that we flag posts about Kickstarter campaigns. The most obvious solution to this problem of forcing people to read what they don’t want to read would be a UserScript or browser extension that automatically removes posts with objectionable tags.
[Daniel] wrote a UserScript for GreaseMonkey or TamperMonkey that looks at the tags for each and every Hackaday post. If a tag matches, “crowd-funding”, “crowdfunding”, or “kickstarter”, the post is removed from your browser.
It’s an astonishing advancement in state of the art, “not reading what you don’t want to read” technology. Bards and troubadours will sing of this day for years. Philosophers and theologians are citing this as evidence of something they’re calling, ‘free will.’ We don’t know who [Will] is, but at least he’s free now.
If that’s not enough, [RoGeorge] came up with an astonishing twist on this life-changing technology. By adding, ‘Arduino’ to the blacklisted tags, all posts tagged ‘Arduino’ are also removed. This can, of course, be extended to any tag. Imagine; a world where you don’t have to read what you don’t want to read. A futuristic utopia. Astounding.
As if it weren’t confusing enough in the Arduino world these days, now we’re going to have to deal with conflicting version numbers for the IDE. Yup, it’s been forked. Arduino LLC is offering a recently-updated version 1.6.3 at arduino.cc, but Arduino SRL has bumped up the version number to 1.7.0 at arduino.org. The conflict in naming and versioning has not gone unnoticed.
According to this article (Google translate here) the versions don’t differ by much, and the 1.7.0 IDE may even be a step backwards versus 1.6.3. It certainly seems to us that the majority of the active developers in the Arduino project have been sticking with [Massimo Banzi] and the Arduino LLC camp. Of course, everything’s open source and there’s nothing stopping Arduino SRL from porting worthwhile IDE changes across to their version of the codebase.
It doesn’t take a clairvoyant to sense that this may be in response to the warning about non-licensed boards that was included in the “official” 1.6.1 release. Nor does it take a psychic to foresee confusing times ahead.
If you’re interested in doing some code-sleuthing, have a look at the two versions and leave a comment below letting us know of any substantive differences you unearth.
Let’s be honest, multi-extruder 3D printers don’t work the greatest — even MakerBot decided to get rid of the feature in their latest line of printers. So what are you going to do when you want to print a multi-colored object with your trusty single extruder? Pause the print like a savage and exchange the filament? No, no, it’s much easier than that — well, you’re still going to have to switch the filament.
[Jan Henrik] has put together a simple script in OpenScad to split up 3D files into layers in order to facilitate printing in multiple colors (or even materials). You load in the file, tell it the print height you want to do, export, convert to G-Code, print, rinse, repeat. In between the layers you have time to purge the extruder, remove any excess skirt or support material, and then hit print again. Quite a bit easier than hitting pause and jogging the extruder out of the way (while avoiding plastic dribble coming out of your extruder!).
Meanwhile if your prints get interrupted — or fail a lot — you might be interested in this project by a group of MIT researchers. It’s an add-on for 3D printers that uses a laser scanner to evaluate how much of the part was printed, allowing you to restart a print that failed!
The new hotness for Internet of Things hardware is the ESP8266. Alone it can connect to a WiFi network, but it doesn’t really have a lot of output options. Paired with an ATMega, and you really have something. That’s the philosophy behind the WIOT board, and when [Chris] was assembling these boards, he needed a way to flash firmware. The board has an unpopulated ISP header from the assembler, so pogo pins are the answer. How do you make a pogo pin jig? With a 3D printer, of course.
The ISP header wasn’t populated to give the board a slim profile, but this means a jig of sorts would be needed to program the WIOT. The first attempt was buying a few pogo pin adapters from Tindie, but this was terribly uncomfortable to hold while the board was being programmed.
To fix this problem, a small clip device was rigged up, printed out, and used for programming. Interestingly, this clip has a very deep throat, and a few holes used for bolting on a separate programmer. This shows a lot of forward thinking: the programmer can be reused for different boards with completely different layouts and programmers. If the next revision of the WIOT needs a JTAG header to program the micro, the problem of programming it is already covered.
A Thermocouple is a terrific way to measure temperature. The effects of temperature change on dissimilar metals produces a measurable voltage. But to make that measurement you need an amplifier circuit designed for the thermocouple being used.
While researching “Zero Drift Amplifiers” as a follow-up to my video on Instrumentation Amplifiers I noticed the little schematic the front page of the LTC1049 datasheet which is shown here. I thought it was an ideal example of an analog application where some gain and some “gain helper” were needed to accomplish our useful little application of amplifying a thermocouple probe.
In the video I don’t really talk much about the thermocouples themselves other than the type I see most of the time which is type K. If you’re not already familiar with the construction of these probes you can find an informative write-up on thermocouples and the different types on the Wikipedia page and you might also want to check out the Analog Devices app note if you would like to know more. What I will cover is a reliable and precise way to read from these probes, seen in the video below and the remainder of the post after the break.
Are the contents of a Crown Royal bag fair? No, they never are. What about dice? In a quest for good randomness, [Apo] designed and built an automated die tester. Not only does it shake the die up, it captures images so real, actual statistics can be done on each individual die.
The setup is a n acrylic box made with BoxMaker attached to a 3D printed adapter for a stepper motor shaft. Randomizing the die happens exactly like you think it would: a stepper shakes the box, and a camera underneath takes a picture. With a bit of computer vision, this image can be translated into a number, ready for the statistics package of your choice.
There were only 559 rolls before the 3D printed mess of duck tape fell apart, but a test of the distribution revealed this die to have a 92% probability that it is fair. That’s not good.
Creating a cheating die is much more interesting, and to find out if he could do it, [Apo] stuck a die in an oven at 100° C for a few minutes. Surprisingly, the fairness of the die got better, suggesting it’s possible to correct an un-fair die. Putting it back in the oven after that threw the fairness out of the window but there was still no visual difference between this modified die and the original stock die.