If you have a few hobby servos lying around, here’s a hack that let’s you recycle them and put them to good use. [Kedar Nimbalkar] took a micro servo and converted it into an electric screwdriver. It is simple enough to deserve a short video showing how he did it.
He starts by opening up a 9G micro servo and removing the electronics. All that’s needed is the DC motor and the gears. The two motor wires go directly to the battery via a polarity reversal switch to allow the motor to turn in both directions. The servo horn is cut to size so that it is a tight fit inside the screwdriver socket. A liberal amount of glue is used to make sure it stays in place. The horn is then attached to the modified servo, ready to take interchangeable bits. One last mod before closing up the servo is to convert it to continuous rotation by cutting off the stopper in the drive gear.
He built the power supply from scratch, using a 18650 Li-Po battery, a 5V USB charger, a DPDT switch to allow direction control and a push button to actuate the screw driver. A pair of LED’s connected back to back serve as direction indicators as well as some local illumination.
There’s lot’s of scope to improvise and do everything differently, but the basic premise of using unused servos for a handy electric screwdriver is pretty neat.
Continue reading “El Cheapo Electric Screwdriver” →
There’s an old proverb algebra teachers often recite: You have to use what you know to find out what you don’t know. The same could be said about sensors. For example, analog to digital converters use something computers are good at finding (like time) and use it to determine something they aren’t good at finding (like voltage). So how do you detect rainfall? If you are [lowflyerUK], you use the microphone in your web camera and a Raspberry Pi.
The idea was to reduce irrigation usage based on rainfall, so an exact measurement isn’t necessary. The Python code that analyzes the audio input is calibrated with three configuration parameters and attempts to remove wind noise. Even so, it needs to be in a room that gets a lot of noise from rainfall and ambient noise can throw the reading off.
The weather service is never going to adopt this system. Still, it is a great example of taking something you know and using it to get something you don’t know. If you want a more complete weather station, we have a few options for you.
Every year, Vitamin T holds a #ATXPumpkinChallenge for creative agencies in and around Austin. Each team was given a fake pumpkin and the challenge of making a 15-60 second video. As the reigning champions from last year, [SiteGoals] had to up the ante. So they launched a pumpkin into space.
When first given the challenge, it only took the team 3 simple words to get started. Pumpkin. In. Space. What followed was a week-long frenzy of preparing the pumpkin for its maiden flight.
The pumpkin itself is pretty simple. A plastic jack-o-lantern painstakingly painted and detailed to look like the third Death Star. This is makes the title of the project a double-meaning: “Return of the Pumpkin”. They even included iconic spacecraft flying around the equator of the immensely powerful yet questionably vulnerable orb of destruction. Simply launching the pumpkin into space wasn’t enough. They built in a telemetry system and GoPro for recording the voyage. Stick around after the break to see the very entertaining making-of video, set the tune of the Cantina Band.
Continue reading “That’s No Moon Pumpkin, It’s A Space Station” →
Because the world doesn’t have enough electronic junk floating around, [Victor] has improved the WiFi Throwie.
A decade ago, when strong, cheap magnets, bright LEDs, and small coin cell batteries were materials fresh to hacking, someone had a great idea: tape all these items up and throw them on bridges and overpasses. The LED throwie was born, and while we’re sure the biggest installation of LED throwies looked cool, it’s really just a small-scale environmental disaster.
Since then, the ESP8266 was created, and the world now has a tiny WiFi-enabled computer that’s the size of a postage stamp. Yes, WiFi throwies already exist, but coin cells don’t work with the ESP. This means the compact and tiny ESPs are laden down with heavy lithium cells. [Victor] had a better solution: tiny lithium batteries for quadcopters exist, so why not use those?
[Victor] ended up using a small 100mAh 3.7V Lipo battery from a tiny quadcopter for this build. 100mAh isn’t a lot, but in sleep mode, the ESP only uses about 15mAh, or about 6 hours of run time. Sending a picture takes 30 seconds at 120ma, or about 120mAh, so even with a tiny battery no bigger than the ESP itself, this diminutive web server can handle 100 connections before the battery dies.
While not recommended unless you intend to retrieve your throwable web server, it is an interesting example of the latest and cheapest technology that made a throwable webserver possible; 10 years ago, both the ESP and a battery this small would have been unthinkable.
I learned to program FORTRAN IV in the spring of 1968 while working as an engineering technician in water resources. One of the engineers knew of my interest in computers and asked if I would like to learn FORTRAN. He needed to calculate the biological oxygen demand in streams but didn’t have any interest in programming. I jumped at the chance.
This was the days of big iron when the term computer meant a room full of heavily air-conditioned equipment. The State University of New York at Buffalo had an IBM 704 but they soon upgraded to a CDC 6400. To help pay for it they were inviting people to attend a seminar on FORTRAN so they could use the system. My job was with a small State of NY office and getting approval for me to attend was surprisingly easy.
Off I went for 6 weeks of training on one night a week. I still have my black “A Guide to Fortran IV Programming” by [Daniel McCracken]. For years, this was the FORTRAN bible, commonly referred to as just “McCracken”.
The programming went well and somewhere out there is a very old paper with a reference to the results it generated about the Chadakoin River flowing through Jamestown, NY.
This is FORTRAN’s strength – scientific calculations. It’s name says it: FORmula TRANslation.
Origins and FORTRAN IV
[John W. Backus] suggested to IBM a language to replace assembly language. Development began in 1953 for the IBM 704 and the project reached fruition in 1957. Not only was it the first general purpose high-level language, just beating out COBOL and LISP, but its compiler optimized the code since it needed to compete head-on with assembly language. It was the C compiler of its day in that regard.
That was not the only reason it attained success. Reducing the number of punched cards needed for a program by a factor of 20 over assembly helped considerably.
In those days, you needed to use a key punch to create a deck of punch cards. To be really good you had to know how to create a programming card that would let you skip through the fields on a FORTRAN card, or how to edit a card by duplicating it and holding one of the cards in place while you typed in new characters. Because of my fascination with computers I’d taken a key punching and automation machines class in high school so I was all set.
Continue reading “This Is Not Your Father’s FORTRAN” →
The Greek philosopher [Zeno of Elea] proposed that an arrow in flight was in fact not in motion and its visible movement is only an illusion. A simple example of this is to glance at an arrow in flight, doing this causes our mind to store a snapshot of a motionless arrow. [Zeno] further defended this argument by stating that if an object has to travel a finite distance to reach a destination then the finite distance can be divided in half and the object must first reach this halfway point before arriving at the destination. This process can be repeated an infinite number of times, creating an infinite number of points that the object must occupy before reaching the destination thus it can never arrive at the destination.
Whoa, that’s a bit heavy. Let’s take a second here to think about this and never arrive at the conclusion, shall we?
So what does a fancy mathematics parlor trick have to do with the fact that we have all seen an arrow arrive at its destination? Recent experiments conducted at Cornell University have in fact verified the Zeno Effect. Researchers were able to achieve this by having atoms suspended between lasers in temperatures ~1 nano degree above absolute zero so that the atoms arrange themselves in a lattice formation. As per usual in quantum mechanics when observed, the atoms had an equal possibility of being anywhere within the space of the lattice. However, when they were observed at high enough frequencies the atoms remain motionless, bringing the quantum evolution to a halt.
The Therac-25 was not a device anyone was happy to see. It was a radiation therapy machine. In layman’s terms it was a “cancer zapper”; a linear accelerator with a human as its target. Using X-rays or a beam of electrons, radiation therapy machines kill cancerous tissue, even deep inside the body. These room-sized medical devices would always cause some collateral damage to healthy tissue around the tumors. As with chemotherapy, the hope is that the net effect heals the patient more than it harms them. For six unfortunate patients in 1986 and 1987, the Therac-25 did the unthinkable: it exposed them to massive overdoses of radiation, killing four and leaving two others with lifelong injuries. During the investigation, it was determined that the root cause of the problem was twofold. Firstly, the software controlling the machine contained bugs which proved to be fatal. Secondly, the design of the machine relied on the controlling computer alone for safety. There were no hardware interlocks or supervisory circuits to ensure that software bugs couldn’t result in catastrophic failures.
The case of the Therac-25 has become one of the most well-known killer software bugs in history. Several universities use the case as a cautionary tale of what can go wrong, and how investigations can be lead astray. Much of this is due to the work of [Nancy Leveson], a software safety expert who exhaustively researched the incidents and resulting lawsuits. Much of the information published about the Therac (including this article) is based upon her research and 1993 paper with [Clark Turner] entitled “An Investigation of the Therac-25 Accidents”. [Nancy] has since published updated information in a second paper which is also included in her book.
Continue reading “Killed By A Machine: The Therac-25” →