Fatalities Vs False Positives: The Lessons From The Tesla And Uber Crashes

June 18, 2018 by Elliot Williams 175 Comments

In one bad week in March, two people were indirectly killed by automated driving systems. A Tesla vehicle drove into a barrier, killing its driver, and an Uber vehicle hit and killed a pedestrian crossing the street. The National Transportation Safety Board’s preliminary reports on both accidents came out recently, and these bring us as close as we’re going to get to a definitive view of what actually happened. What can we learn from these two crashes?

There is one outstanding factor that makes these two crashes look different on the surface: Tesla’s algorithm misidentified a lane split and actively accelerated into the barrier, while the Uber system eventually correctly identified the cyclist crossing the street and probably had time to stop, but it was disabled. You might say that if the Tesla driver died from trusting the system too much, the Uber fatality arose from trusting the system too little.

But you’d be wrong. The forward-facing radar in the Tesla should have prevented the accident by seeing the barrier and slamming on the brakes, but the Tesla algorithm places more weight on the cameras than the radar. Why? For exactly the same reason that the Uber emergency-braking system was turned off: there are “too many” false positives and the result is that far too often the cars brake needlessly under normal driving circumstances.

The crux of the self-driving at the moment is precisely figuring out when to slam on the brakes and when not. Brake too often, and the passengers are annoyed or the car gets rear-ended. Brake too infrequently, and the consequences can be worse. Indeed, this is the central problem of autonomous vehicle safety, and neither Tesla nor Uber have it figured out yet.

Continue reading “Fatalities Vs False Positives: The Lessons From The Tesla And Uber Crashes” →

Opening A Ford With A Robot And The De Bruijn Sequence

June 18, 2018 by Brian Benchoff 72 Comments

The Ford Securicode, or the keyless-entry keypad available on all models of Ford cars and trucks, first appeared on the 1980 Thunderbird. Even though it’s most commonly seen on the higher-end models, it is available as an option on the Fiesta S — the cheapest car Ford sells in the US — for $95. Doug DeMuro loves it. It’s also a lock, and that means it’s ready to be exploited. Surely, someone can build a robot to crack this lock. Turns out, it’s pretty easy.

The electronics and mechanical part of this build are pretty simple. An acrylic frame holds five solenoids over the keypad, and this acrylic frame attaches to the car with magnets. There’s a second large protoboard attached to this acrylic frame loaded up with an Arduino, character display, and a ULN2003 to drive the resistors. So far, everything you would expect for a ‘robot’ that will unlock a car via its keypad.

The real trick for this build is making this electronic lockpick fast and easy to use. This project was inspired by [Samy Kamkar]’s OpenSesame attack for garage door openers. In this project, [Samy] didn’t brute force a code the hard way by sending one code after another; (crappy) garage door openers only look at the last n digits sent from the remote, and there’s no penalty for sending the wrong code. In this case, it’s possible to use a De Bruijn sequence to vastly reduce the time it takes to brute force every code. Instead of testing tens of thousands of different codes sequentially, this robot only needs to test 3125, something that should only take a few minutes.

Right now the creator of this project is putting the finishing touches on this Ford-cracking robot. There was a slight bug in the code that was solved by treating the De Bruijn sequence as circular, but now it’s only a matter of time before a 1993 Ford Taurus wagon becomes even more worthless.

Dissecting The Elusive Wax Motor

June 18, 2018 by Tom Nardi 34 Comments

We’d wager most readers aren’t intimately acquainted with wax motors. In fact, a good deal of you have probably never heard of them, let alone used one in a project. Which isn’t exactly surprising, as they’re very niche and rarely used outside of HVAC systems and some appliances. But they’re fascinating devices, and once you’ve seen how they work, you might just figure out an application for one.

[AvE] recently did a complete teardown on a typical wax motor, going as far as cutting the thing in half to show the inner workings. Now we’ve seen some readers commenting that everyone’s favorite foul-mouthed destroyer of consumer goods has lost his edge, that his newer videos are more about goofing off than anything. Well we can’t necessarily defend his signature linguistic repertoire, but we can confidently say this video does an excellent job of explaining these little-known gadgets.

The short version is that a wax motor, which is really a linear actuator, operates on the principle that wax expands when it melts. If a solid block of wax is placed in a cylinder, it can push on a piston during the phase change from solid to liquid. As the liquid wax resists compression, the wax motor has an exceptionally high output force for such a small device. The downside is, the stroke length is usually rather short: for the one [AvE] demonstrates, it’s on the order of 2 mm.

By turning heat directly into mechanical energy, wax motors are often used to open valves and vents when they’ve reached a specific temperature. The common automotive engine thermostat is a classic example of a wax motor, and they’re commonly found inside of dishwashers as a way to open the soap dispenser at the proper time during the cycle.

This actually isn’t the first time we’ve featured an in-depth look at wax motors, but [AvE] actually cutting this one in half combined with the fact that the video doesn’t look like it was filmed on a 1980’s camera makes it worth revisiting the subject. Who is going to build a wax motor power device for the Power Harvesting Challenge in the 2018 Hackaday Prize?

Continue reading “Dissecting The Elusive Wax Motor” →

Searchable KiCad Component Database Makes Finding Parts A Breeze

June 17, 2018 by Ben James 15 Comments

KiCad, the open source EDA software, is popular with Hackaday readers and the hardware community as a whole. But it is not immune from the most common bane of EDA tools. Managing your library of symbols and footprints, and finding new ones for components you’re using in your latest design is rarely a pleasant experience. Swooping in to help alleviate your pain, [twitchyliquid64] has created KiCad Database (KCDB). a beautifully simple web-app for searching component footprints.

The database lets you easily search by footprint name with optional parameters like number of pins. Of course it can also search by tag for a bit of flexibility (searching Neopixel returned the footprint shown above). There’s also an indicator for Kicad-official parts which is a nice touch. One of our favourite features is the part viewer, which renders the footprint in your browser, making it easy to instantly see if the part is suitable. AngularJS and material design are at work here, and the main app is written in Go — very trendy.

The database is kindly publicly hosted by [twitchyliquid64] but can easily be run locally on your machine where you can add your own libraries. It takes only one command to add a GitHub repo as a component source, which then gets regularly “ingested”. It’s great how easy it is to add a neat library of footprints you found once, then forget about them, safe in the knowledge that they can easily be found in future in the same place as everything else.

If you can’t find the schematic symbols for the part you’re using, we recently covered a service which uses OCR and computer vision to automatically generate symbols from a datasheet; pretty cool stuff.

Learn Six Oscilloscope Measurements With One Arduino

June 17, 2018 by Al Williams 8 Comments

We won’t mention names, but we are always dismayed to see people twist knobs randomly on a scope until it shows a good picture. These days, there’s the dreaded auto button, too, which is nearly as bad. If you haven’t spent the time to learn how to properly use a scope [Bald Engineer] has a great introduction to making six measurements with an Arduino as a test device.

To follow along you’ll need an Arduino UNO and a two-channel (or better) scope. Actually, most of the measurements would probably work on any Arduino, but there are some that require the separate USB to serial chip like that found on the UNO and similar boards.

The six measurements are:

The auto reset programming pulse
Capture and decode serial data
Noise on the power rail
Observe probe loading effects
PWM duty cycle
The timing of pin manipulation code

Some of these measurements use a bit of Arduino code, while others just make use of the circuitry on the board no matter what software is running.

Not only does the post show you where to make the measurements and what the result should look like, there’s also a discussion of what the measurement means and some suggested things to try on your own.

If you go through this post, you might also enjoy learning more about probes. If you are feeling adventurous, you can even build your own current probe.

Hackaday Links: June 17, 2018

June 17, 2018 by Brian Benchoff 16 Comments

Do you like badges? Of course you like badges. It’s conference season, and that means it’s also badge season. Well good news, Tindie now has a ‘badge’ category. Right now, it’s loaded up with creepy Krustys, hypnotoads, and fat Pikas. There’s also an amazing @Spacehuhn chicken from [Dave]. Which reminds me: we need to talk about a thing, Spacehuhn.

On the list of ‘weird emails we get in the tip line’ comes Rat Grease. Rat Grease is the solution to rodents chewing up cabling and wires. From what we can gather, it’s a mineral oil-based gel loaded up with capsaicin; it’s not a poison, and not a glue. Rats are our friends, though, which makes me want to suggest this as a marinade, or at the very least a condiment. The flash point is sufficiently high that you might be able to use this in a fryer.

[Matthias Wandel] is the guy who can build anything with a table saw, including table saws. He posts his stuff online and does YouTube videos. A while back, he was approached by DeWalt to feature their tools in a few videos. He got a few hand tools, a battery-powered table saw, and made some videos. The Internet then went insane and [Matthias] lost money on the entire deal. Part of the reason for this is that his viewers stopped buying plans simply because he featured yellow power tools in his videos. This is dumpster elitism, and possibly the worst aspect of the DIY/engineering/maker community.

Elon Musk is the greatest inventor ever. No scratch that. The greatest person ever. Need more proof? The CEO of Tesla, SpaceX, and our hearts has been given the green light to build a high-speed underground train from Chicago O’Hare to downtown. Here’s the kicker: he’s going to do it for only $1 Billion, or $55 Million per mile, making it the least expensive subway project by an order of magnitude. Yes, Subways usually cost anywhere between $500 to $900 Million per mile. How is he doing it? Luck, skill, and concentrated power of will. Elon is the greatest human ever, and we’re not just saying that to align ourselves with an audience that is easy to manipulate; we’re also saying this because Elon has a foggy idea for a ‘media vetting wiki’.

There are rumors Qualcomm will acquire NXP for $44 Billion. This deal has been years in the making, with reports of an acquisition dating back to 2016. Of course, that time, the deal was set to go through but was apparently put on hold by Chinese regulators. Now it’s the same story again; there were recent rumors of Qualcomm buying NXP, and the story was later changed to rumors. We’re waiting for an actual press release on this one. It’s just another long chapter in the continuing story of, ‘where the hell are all the Motorola app notes and data sheets?’

Using IMUs For Odometry

June 17, 2018 by Brian Benchoff 33 Comments

The future is autonomous robots. Whether that means electric cars with rebranded adaptive cruise control, or delivery robots that are actually just remote control cars, the robots of the future will need to decide how to move, where to move, and be capable of tracking their own movement. This is the problem of odometry, or how far a robot has traveled. There are many ways to solve this problem, but GPS isn’t really accurate enough and putting encoders on wheels doesn’t account for slipping. What’s really needed for robotic odometry is multiple sensors, and for that we have [Pablo] and [Alfonso]’s entry to the Hackaday Prize, the IMcorder.

The IMcorder is a simple device loaded up with an MPU9250 IMU module that has an integrated accelerometer, gyro, and compass. This is attached to an Arduino Pro Mini and a Bluetooth module that allows the IMcorder to communicate with a robot’s main computer to provide information about a robot’s orientation and acceleration. All of this is put together on a fantastically tiny PCB with a lithium battery, allowing this project to be integrated into any robotics project without much, if any, modification.

One interesting aspect of the IMcorders is that they can be used for robot kidnapping issues. This, apparently, is an issue when it comes to robots and other electronic detritus littering the sidewalks. Those electric scooters abandoned on the sidewalk in several cities contain some amazing components that are ripe for some great hardware hacking. Eventually, we’re going to see some news stories about people stealing scooters and delivery robots for their own personal use. Yes, it’s a cyberpunk’s dream, but the IMcorder can be used for a tiny bit of theft prevention. Pity that.