The Predictability Problem With Self-Driving Cars

April 18, 2016 by Elliot Williams 93 Comments

A law professor and an engineering professor walk into a bar. What comes out is a nuanced article on a downside of autonomous cars, and how to deal with it. The short version of their paper: self-driving cars need to be more predictable to humans in order to coexist.

We share living space with a lot of machines. A good number of them are mobile and dangerous but under complete human control: the car, for instance. When we want to know what another car at an intersection is going to do, we think about the driver of the car, and maybe even make eye contact to see that they see us. We then think about what we’d do in their place, and the traffic situation gets negotiated accordingly.

When its self-driving car got into an accident in February, Google replied that “our test driver believed the bus was going to slow or stop to allow us to merge into the traffic, and that there would be sufficient space to do that.” Apparently, so did the car, right before it drove out in front of an oncoming bus. The bus driver didn’t expect the car to pull (slowly) into its lane, either.

All of the other self-driving car accidents to date have been the fault of other drivers, and the authors think this is telling. If you unexpectedly brake all the time, you can probably expect to eventually get hit from behind. If people can’t read your car’s AI’s mind, you’re gonna get your fender bent.

The paper’s solution is to make autonomous vehicles more predictable, and they mention a number of obvious solutions, from “I-sense-you” lights to inter-car communication. But then there are aspects we hadn’t thought about: specific markings that indicate the AIs capabilities, for instance. A cyclist signalling a left turn would really like to know if the car behind has the new bicyclist-handsignal-recognition upgrade before entering the lane. The ability to put your mind into the mind of the other car is crucial, and requires tons of information about the driver.

All of this may require and involve legislation. Intent and what all parties to an accident “should have known” are used in court to apportion blame in addition to the black-and-white of the law. When one of the parties is an AI, this gets murkier. How should you know what the algorithm should have been thinking? This is far from a solved problem, and it’s becoming more relevant.

We’ve written on the ethics of self-driving cars before, but simply in terms of their decision-making ability. This paper brings home the idea that we also need to be able to understand what they’re thinking, which is as much a human-interaction and legal problem as it is technological.

[Headline image: Google Self-Driving Car Project]

First Hackaday Prize Challenge Closes In One Week

April 18, 2016 by Mike Szczys 6 Comments

The first five weeks of the Hackaday Prize have flown by but many of you have already been busy, submitting over 400 entries! For those that haven’t (or for those considering a second entry) there’s still time. You have until 7am PDT on Monday 4/25 to Design Your Concept.

20 Entries Will Win $1000

This is the round that everyone should enter. It’s all about documenting your idea to solve a technology problem; showing you have a plan that will lead to success. From this first challenge, 20 entries will be selected to win $1000 each and move on to the final round of the 2016 Hackaday Prize.

Design with a Team During World Create Day

That’s right, you don’t need to build anything to be eligible for this round. It’s the perfect opportunity to get your engineering dream team together for an afternoon and come up with that impressive design concept. We’re making this even easier with Hackaday World Create Day. This Saturday, 4/23, there will be Hackaday Meetups all over the world. Show up, brainstorm your concept, and submit it as an entry. Many of the World Create Day meetups have more in store, like talks and socializing. Don’t miss this opportunity to meet the Hackaday community in your town!

The HackadayPrize2016 is Sponsored by:

How To Know When An Accelerator Is Not Right For Your Startup

April 18, 2016 by Bob Baddeley 23 Comments

A few weeks ago we ran an article on the benefits of accelerator programs. While I agreed with almost everything in it, the article still bothered me, and I wanted to start a discussion about when an accelerator is not appropriate. So many startups are regularly asked “have you thought about Kickstarter? Shark Tank? Are you raising money? YCombinator?” These questions are constantly ingrained into people’s brains and they come to think those are the only options.

The reality is that there are lots of ways to build a company, and Kickstarter, Shark Tank, angel investors, and accelerators are all new within the last few years, and they aren’t right for many people. So let’s look at when an accelerator is right for you.

Continue reading “How To Know When An Accelerator Is Not Right For Your Startup” →

Bootstrapping An Amiga 2000 Graphics Card Because Vintage Is Pricey

April 18, 2016 by Jenny List 80 Comments

If you have a computer on your desk today, the chances are that it has an Intel architecture and is in some way a descendant of the IBM PC. It may have an Apple badge on the front, it may run Linux, or Windows, but in hardware terms the overwhelming probability is that it will be part of the Intel monoculture. A couple of decades ago though in the 16- and early 32-bit era you would have found a far greater diversity of architectures. Intel 3-, and 486s in PCs and clones, Macintosh, Commodore, and Atari platforms with the 68000 family, the WDC 65C816 in the Apple IIGS, and the Acorn Archimedes with an early ARM processor to name but a few.

In the tough environment of the 1990s most of these alternative platforms fell by the wayside. Apple survived to be revitalised under a returning Steve Jobs, Atari and Commodore withered under a bewildering succession of takeovers, and Acorn split up and lost its identity with its processor licensing subsidiary going on to power most of the mobile devices we take for granted today.

Surprisingly though some of the 16-bit platforms refused to die when their originators faded from view. In particular Commodore’s Amiga has lived on with new OS versions, new platforms, and community-supported hardware upgrades. News of just such a device came our way this morning, [Lukas Hartmann]’s MNT VA2000, a graphics card for the Amiga 2000 using a GPU implemented on an FPGA.

Continue reading “Bootstrapping An Amiga 2000 Graphics Card Because Vintage Is Pricey” →

Sciencing DVD-RW Laser Diodes

April 18, 2016 by Elliot Williams 16 Comments

If you’ve played around with laser diodes that you’ve scavenged from old equipment, you know that it can be a hit-or-miss proposition. (And if you haven’t, what are you waiting for?) Besides the real risk of killing the diode on extraction by either overheating it or zapping it with static electricity, there’s always the question of how much current to put into the thing.

[DeepSOIC] decided to answer the latter question — with science! — for a DVD-burner laser that he’s got. His apparatus is both low-tech and absolutely brilliant, and it looks like he’s getting good data. So let’s have a peek.

First up is the detector, which is nothing more than a photodiode, 100k ohm load resistor, and a big capacitor for a power supply. We’d use a coin-cell battery, but given how low the discharge currents are, the cap makes a great rechargeable alternative. The output of the photo diode goes straight into the scope probe.

He then points the photodiode at the laser spot (on a keyboard?) and pulses the laser by charging up a capacitor and discharging it through the laser and a resistor to limit total current. The instantaneous current through the laser diode is also measured on the scope. Plotting both the current drawn and the measured brightness from the photodiode gives him an L/I curve — “lumens” versus current.

Look on the curve for where it stops being a straight line, slightly before the wiggles set in. That’s about the maximum continuous operating current. It’s good practice to de-rate that to 90% just to be on the safe side. Here it looks like the maximum current is 280 mA, so you probably shouldn’t run above 250 mA for a long time. If the diode’s body gets hot, heatsink it.

If you want to know everything about lasers in general, and diode lasers in particular, you can’t beat Sam’s Laser FAQ. We love [DeepSOIC]’s testing rig, though, and would love to see the schematic of his test driver. We’ve used “Sam’s Laser Diode Test Supply 1” for years, and we love it, but a pulsed laser tester would be a cool addition to the lab.

What to do with your junk DVD-ROM laser? Use the other leftover parts to make a CNC engraver? But we don’t need to tell you what to do with lasers. Just don’t look into the beam with your remaining good eye!

GameGirl: A Better Portable Raspberry Pi

April 17, 2016 by Brian Benchoff 8 Comments

For better or worse, the most popular use for the Raspberry Pi – by far – is media centers and retro game consoles. No, the great unwashed masses aren’t developing Linux drivers for their Pi peripherals, and very few people are tackling bare metal ARM programming. That doesn’t mean creating a handheld console based on the Pi isn’t a worthy pursuit.

For their entry for the 2016 Hackaday Prize, [David] and [Jean-André] are building a portable Pi console that’s much better than an old Bondo-encrusted Game Boy enclosure stuffed with hot glue and wires. They’re doing this project the right way with a hardware accelerated display, custom software, and a high quality case.

[David] is in charge of the hardware, and that means making a very, very small handheld console. The design of this GameGirl is extremely similar to the old-school Game Boy Pocket (or Game Boy Light). There’s a D-pad, four buttons, select, start, and two ‘shoulder’ buttons on the back. The build is based on the Raspberry Pi Zero, and thanks to the Pi’s standard 40-pin header, [David] is able to configure the display to use an RGB565 DPI interface. This means the display is stupidly cheap while still leaving a few GPIO pins left over for the SPI, buttons, backlight, and PWM audio.

[Jean-André] is the other half of the team, and his contributions to open source software make him exceptionally qualified for this project. He’s the main developer for Lakka, a DIY retro emulation console, and the #5 RetroArch contributor. No, this project isn’t using RetroPie – and there’s a reason for that. Emulator hackers are spending a lot of time optimizing emulators for the Raspberry Pi, only because of RetroPi. If these emulator hackers spent their time optimizing for an API like LibRetro, you could eventually play a working version of Pilotwings 64 on the Raspberry Pi and every other platform LibRetro is available for. All the effort that goes into making a game work with a Raspberry Pi is effort that goes into making that game work for the PSP, Wii, iOS, and a PC. Yes, its philosophical pissing in the wind while saying, ‘this is what the community should do’; this is open source software, after all.

With the right ideas going into the hardware and software, [David] and [Jean-André] have an amazing project on their hands. It’s one of the most popular entries and are near the top of the charts in the community voting bootstrap effort where every like on a project gets the team a dollar for their project. GameGirl is shaping up to be a great project, and we can’t wait to see the it in action.

The HackadayPrize2016 is Sponsored by:

Designing A 360 Degree All Metal Hinge

April 17, 2016 by James Hobson 38 Comments

Looking for a 360 degree hinge that had no slop was harder than [Mr. LeMieux] thought it would be. Add to the fact it had to be made completely out of metal with no plastic components — and basically fireproof. He was coming up blank.

You see, [Mr. LeMieux] is casting metal components, and needed a hinge to close two halves of a mold. When he couldn’t find anything commercially available, he decided to design his own. Using aluminum, he machined the two halves with an interlocking mechanism between the two. Essentially, it’s a 3-bar linkage, but if he stopped there, it would have too much slop. So he actually designed in two fixed gears that roll over each other — this ensures the hinge stays perfectly smooth throughout its entire range of movement — it’s actually quite ingenious.

Continue reading “Designing A 360 Degree All Metal Hinge” →