Prosthetic arms can range from inarticulate pirate-style hooks to motorized five-digit hands. Control of any of them is difficult and carries a steep learning curve, rarely does their operation measure up to a human arm. Enhancements such as freely rotating wrist might be convenient, but progress in the field has a long way to go. Prosthetics with machine learning hold the promise of a huge step to making them easier to use, and work from Imperial College London and the University of Göttingen has made great progress.
The video below explains itself with a time-trial where a man must move clips from a horizontal bar to a nearby vertical bar. The task requires a pincer grasp and release on the handles, and rotation from the wrist. The old hardware does not perform the two operations simultaneously which seems clunky in comparison to the fluid motion of the learning model. User input to the arm is through electromyography (EMG), so it does not require brain surgery or even skin penetration.
We look forward to seeing this type of control emerging integrated with homemade prosthetics, but we do not expect them to be easy.
While cars are slowing becoming completely computer-controlled, road vehicles have been relying on computers since the 1970’s. The first automotive use of computers was in engine control units (ECUs) which came along as fuel injection systems started to replace carburetors.
[P1kachu]’s 1997 Subaru Impreza STi, like most cars of this vintage, uses an ECU and provides a diagnostic connector for external communications. [P1kachu]’s Subaru hacking project includes building a diagnostic interface device, dumping the ECU’s firmware, and reverse engineering the binary to understand and disable the speed limiter. If this looks familiar, it’s because we just covered the infotainment hacks in this car on Saturday. But he added information about the communications protocols is definitely worth another look.
This era of Subaru uses a non-standard diagnostics protocol called SSM1, which is essentially a 5 volt TTL serial line running at 1953 bits per second. The custom interface consists of a Teensy and a 3.3V to 5V level shifter. Once connected, commands can be sent directly to the ECU. Fortunately, the protocol has been quite well documented in the past. By issuing the “Read data from ECU address” command repeatedly, the full firmware can be dumped.
[P1kachu] goes on to locate the various engine tuning maps and discover the inner workings of the speed limiter. With cars getting more computerized, it’s nice to see folks are still able to tune their rides, even if it means using Teensys instead of wrenches.
Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.
At last year’s 34c3, [Paul] already demonstrated the basics of writing such a user-space network driver for Linux, which serves now as reference implementation for his students. We won’t see Bash or JavaScript here, but we will see a brief summary of what it generally means to develop user-space drivers in C#, Swift, OCaml, or Haskell, along a more detailed insight from [Sebastian Voit] and [Simon Ellmann] about Go and Rust. A collection of each language’s implementation can be found on GitHub.
Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development. Continue reading “35C3: Safe And Secure Drivers In High-Level Languages”→
Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.
So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.
We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.
Vacuum tubes fueled a technological revolution. They made the amplification of signals a reality for transatlantic telephone cables (and transcontinental ones too), they performed logic for early computers, and they delivered that warm fuzzy sound for high fidelity audio. But they were labor intensive to produce, and fragile, so semiconductors came along and replaced tubes in almost every application. But of course tubes are still with us and some tube applications are still critical — you’ll find them used in high-power RF and there are even satellites that depend on klystrons. So there are still experts in tube fabrication around, and Charles Alexanian is one of them. His newly-published talk at the 2018 Hackaday Supercon (found below) is a whirlwind tour of what goes into building a vacuum tube.
The process of building your own vacuum tube isn’t hard, but it’s not a walk in the park. The difficulty comes in the sheer number of processes, and the tricks of the trade found at every step. Charles’ methaphor is that if you build one tube at a time each step is like learning to ride a bicycle again, but if you build many you get into the swing of it and things go a lot better. His talk is a brief overview of everything, but if you want to drill down he also wrote an excellent article that goes further in depth.
In the working components of each tube are the precision parts: the grid (or grids). For the tube to function well these must be accurately produced which can be done with photolithography, but Charles usually uses a winding process involving a lathe. After winding, the grid is stretched to straighten the nickel wire, then cut to length. Other components such as the plate are stamped using an arbor press and simple forms he fabricates for the purpose.
Tube sealing machine common in factories
Lathe setup used for 1-off tube sealing
Tube being tested for leaks
Two glass components are used, the dome itself, and feedthrough stems that have a wire for each lead passing through a glass disc. The components are spot welded to the inside portion of the feedthrough stem, then the glass is fused together, again using a lathe. It heads over to a pumping station to evacuate the air from the tube, and is finally tested for leaks using a handheld Tesla coil (see, we knew those weren’t just toys).
Charles proposed his Supercon appearance as a chance to fabricate tubes on-site. We loved the idea, but the amount of gear needed is somewhat prohibitive (annealing ovens, vacuum cabinets, torches for sealing, and the need for 220v, plus space for it all). That’s too bad since we were really hoping to see the Jolly Wrencher in Nixie-tube form — incidentally, Charles says Nixes are simple to make compared to amplifiers and switches. He also mentions that the majority of your time is spent “washing” parts to remove impurities. Fair enough, that part sounds boring, but we hope to endure it at some point in the future because vacuum tube fabrication demos feel very much like a Hackaday event!
Insurance is a funny business. Life insurance, for example, is essentially betting someone you will die before your time. With the recent focus on companies getting hacked, it isn’t surprising that cybersecurity insurance is now big business. Get hacked and get paid. Maybe.
The reason I say maybe is because of the recent court battle between Zurich and Mondelez. Never heard of them? Zurich is a big insurance company and Mondelez owns brands like Nabisco, Oreo, and Trident chewing gum, among others.
It all started with the NotPetya ransomware attack in June of 2017. Mondelez is claiming it lost over $100 million dollars because of the incident. But no problem! They have insurance. If they can get the claim paid by Zurich, that is. Let’s dig in and try to see how this will all shake out.
Not that we don’t love Star Trek, but the writers could never decide if ion propulsion was super high tech (Spock’s Brain) or something they used every day (The Menagerie). Regardless, ion propulsion is real and we have it today on more than one spacecraft. However, MIT recently demonstrated an ion-powered airplane. How exciting! An airplane with no moving parts that runs on electricity. Air travel will change forever, right? According to [Real Engineering], ion-propelled (full-sized) aircraft run into problems with the laws of physics. You can see the video explaining that, below.
To understand why, you need to know two things: how ion drive works and how the engines differ when using them in an atmosphere. Let’s start with a space-based ion engine, a topic we’ve covered before. Atoms are turned into ions which are accelerated electrically. So the ion engine is just using electricity to create thrust exhaust instead of burning rocket fuel.
