An embedded MEMS sensor might be lots of fun to play with on your first foray into the embedded world–why not deploy a whole network of them? Alas, the problem with communicating with a series of identical sensors becomes increasingly complicated as we start needing to handle the details of signal integrity and the communication protocols to handle all that data. Fortunately, [Artem], [Hsin-Liu], and [Joseph] at MIT Media Labs have made sensor deployment as easy as unraveling a strip of tape from your toolkit. They’ve developed SensorTape, an unrollable, deployable network of interconnected IMU and proximity sensors packaged in a familiar form factor of a roll of masking tape.
Possibly the most interesting technical challenge in a string of connected sensor nodes is picking a protocol that will deliver appreciable data rates with low latency. For that task the folks at MIT Media labs picked a combination of I²C and peer-to-peer serial. I²C accomodates the majority of transmissions from master to tape-node slave, but addresses are assigned dynamically over serial via inter-microcontroller communication. The net effect is a fast transfer rate of 100 KHz via I²C with a protocol initialization sequence that accommodates chains of various lengths–up to 128 units long! The full details behind the protocol are in their paper [PDF].
With a system as reconfigurable as SensorTape, new possibilities unfold with a solid framework for deploying sensors and aggregating the data. Have a look at their video after the break to get a sense of some of the use-cases that they’ve uncovered. Beyond their discoveries, there are certainly plenty others. What happens when we spin them up in the dryer, lay them under our car or on the ceiling? These were questions we may never have dreamed up because the tools just didn’t exist! Our props are out to SensorTape for giving us a tool to explore a world of sensor arrays without having to trip over ourselves in the implementation details.
I keep up with the trends in 3D printing reasonably well. The other day my friend mentioned that filament thickness sensing had been added to the latest version of the Marlin firmware. I had no idea what it was, but it certainly sounded cool. I had to find out more.
In industrial settings, filament is made by pulling extruding molten plastic at a certain speed into a cooling bath. The nozzle for 2.85mm filament and 1.75 mm filament is actually the same size, but the filament is stretched more or less as it leaves the nozzle. By balancing these three variables the extrusion machine can produce any size filament desired. Like any mechanical system, it needs constant adjustment to maintain that balance. This is usually done by measuring the filament with a laser after it has cooled, and then feeding this information back into the system. The better filament manufacturers have multiple lasers and very fast feedback loops. Some of the best offer +-0.04mm or less variation in thickness between any two points on the filament. Some of the worst have larger errors such as +-.10mm. Because the plastic is fed into the extruder at a fixed linear speed, this makes a variation in the volume of the plastic coming out of the nozzle per second. With the best we see a 4.41% variation in the volume of plastic extruded. With the worst we start to see 10.51% or more.
A printer is dumb. It works under the assumption that it is getting absolutely perfect filament. So when it gets 10.51% more plastic, it simply pushes it out and continues with its life. However, if the filament is off enough, this can actually show up as a visible defect on the print. Or in worse cases, cause the print to fail by over or under extrusion of plastic.
So, what does a filament thickness sensor do to correct this issue? To start to understand, we need to look at how the filament is dealt with by the software. When the slicer is compiling the G-code for a 3D print, it calculates the volume of plastic it needs in order to deposit a bead of plastic of a certain width and of a certain height per mm of movement. That was a mouthful. For example, when a printer printing 0.2mm layers moves 1mm it wants to put down a volume that’s 1.0mm long x 0.4mm wide x 0.2mm high. The filament being pushed into the nozzle has a volume per mm determined by the diameter of the filament.
The volume out per mm of filament in.
The equation we are trying to balance.
Our goal is to integrate the thickness sensor into these functions to see what the thickness sensor is doing. This is a linear equation, so there’s nothing fancy here. Now, the layer height, layer width, and length of the move are determined by settings and model geometry respectively. These are fixed numbers so we don’t care about them. That leaves us the diameter of the filament and the length of filament extruded. As we mentioned before, typically the filament is assumed to be a fixed diameter. So all the software has to calculate is the length of filament that needs to be extruded per mm of combined movement in the x and y so that our volumes match.
But, we know that one of these variables is actually changing per millimeter as well. The filament diameter! So now we have a problem. If the filament diameter is changing all the time, our equation will never balance! In order to fix this we can add a multiplier to our equation. Since we have no control over the width of the filament we can’t modify that value. However, if we know the width of the filament, and we know the value its supposed to be, we can change the length of the filament extruded. This is because unlike the filament, we have control over the stepper motor that drives the extruder. This value is called the extrusion multiplier, and its determination is what the thickness sensor is all about.
So all the filament sensor does is measure the filament’s current diameter. It takes expected diameter and divides it by the value it just measured to get a simple percentage. It feeds that number back into our system as the extruder multiplier and slows or speeds up the stepper motor as needed. Pretty simple.
The ideal filament the printer thinks it is seeing.
The printer is unable to compensate for the variations.
By adjusting with the extrusion multiplier the printer is able to approximate perfect filament.
There are a few thickness sensors being toyed with right now. The first, as far as I can tell; let me know if I am wrong in the comments, was by [flipper] on thingiverse. He is in his third version now. The sensor works by casting a shadow of the filament as it passes by onto an optical sensor. The firmware then counts the pixels and works backwards to get the diameter. This value is sent to the Marlin firmware on the printer which does the rest. As is usual and wonderful in the open source community, it wasn’t long before others started working on the problem too. [inoranate] improved on the idea by casting more shadows on the sensor. The technique is still brand new, but it will be interesting to see what benefits it reaps.
Now comes the next question,”Is it worth upgrading my printer with a thickness sensor?” If you typically run poor filament, or if you extrude your own, yes. The current sensors can only measure +- .02mm. So for the best filament, you won’t really see a difference, but for worse stuff, you might. The latest firmware of the Lyman filament extruder, for making your own filament, also supports these sensors, letting you feed back into your production system like the industrial machines. All in all a very interesting development in the world of 3D printers.
RFID tags are really very primitive pieces of technology. Yes, they harvest energy from an RFID reader and are able to communicate a few bits of data, but for a long time these tags have been unable to provide useful data beyond a simple ID number. [CaptMcAllister] found a new RFID sensor platform from TI and managed to make a wireless pressure sensor that fits in the inner tube of his bike.
The sensor [Capt] is using comes from TI’s RF430 series that include a few neat sensors that don’t require batteries, but are still able to communicate sensor data to a cell phone or other RFID reader. With a pressure sensor, this tiny microcontroller can receive power from an RFID reader and send it back to a phone app, all without wires.
[CaptMcAllister] cut open an inner tube for his bike, epoxied his PCB to a patch, and sealed everything back up again. After a quick test for leaks, [Capt] found the data coming from the sensor was extraordinarily accurate, and should hold up well enough to be used in his bike.
The video below shows the mystery circuit (which is just the stock iCEstick board), which appears to react any time you flex the PC board. The Verilog implements a simple ring oscillator (basically an inverter with its output tied to its input).
The future is the Internet of Things, or so we’re told, and with that comes the requirement for sensors attached to the Internet that also relay GPS and location data. [Camilo]’s MobileNodes do just that. He’s designed a single device that will listen to any sensor, upload that data to the Internet over GSM or GPRS, and push all that data to the cloud.
The MobileNode is a small circular (7cm) PCB with a standard ATMega32u4 microcontroller. Attached to this PCB are GSM/GPRS and GPS/GLONASS modules to receive GPS signals and relay all that data to the cloud. To this, just about any sensor can be added, including light sensors, PIR sensors, gas and temperature sensors, and just about anything else that can be measured electronically.
Of course the biggest problem with a bunch of sensors on an Internet of Things device is pulling the data from the Internet. For that, [Camilo] designed a web interface that shows sensor data directly on a Google Map. You can check out the project video below.
If someone lobs a grenade, it’s fair to expect that something unpleasant is going to happen. Tear gas grenades are often used by riot police to disperse an unruly crowd, and the military might use a smoke grenade as cover to advance on an armed position, or to mark a location in need of an airstrike. But some gas grenades are meant to help, not hurt, like this talking gas-sensing grenade that’s a 2015 Hackaday Prize entry.
Confined space entry is a particularly dangerous aspect of rescue work, especially in the mining industry. A cave in or other accident can trap not only people, but also dangerous gasses, endangering victims and rescuers alike. Plenty of fancy robots have been developed that can take gas sensors deep into confined spaces ahead of rescuers, but [Eric William] figured out a cheaper way to sniff the air before entering. An MQ2 combination CO, LPG and smoke sensor is interfaced to an Arduino Nano, and a 433MHz transmitter is attached to an output. A little code measures the data from the sensors and synthesizes human voice readings which are fed to the transmitter. The whole package is stuffed into a tough, easily deployed package – a Nerf dog toy! Lobbed into a confined space, the grenade begins squawking its readings out in spoken English, which can be received by any UHF handy-talkie in range. [Eric] reports in the after-break video that he’s received signals over a block away – good standoff distance for a potentially explosive situation.
Since 1998 we’ve been privileged to partake in an arcade game known as Dance Dance Revolution, but before that, way back in the 70’s, was the Simon game. It’s essentially a memory game that asks the player to remember a series of lights and sounds. [Uberdam] decided to get the best of both worlds and mixed the two together creating this giant foot controlled Simon game. (English translation.)
The wood platform that serves as the base of the project was fitted with four capacitive sensors, each one representing a “color” on the Simon game. When a player stomps on a color, a capacitive sensor sends a signal to a relay which in turn notifies the Raspberry Pi brain of the input. The Pi also takes care of showing the player the sequence of colored squares that must be stepped on, and keeps track of a player’s progress on a projector.
This is a pretty good way of showing how a small, tiny computer like the Raspberry Pi can have applications in niche environments while also being a pretty fun game. We all remember Simon as being frustrating, and we can only imagine how jumping around on a wooden box would make it even more exciting. Now, who can build a robot that can beat this version of Simon?