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]

After The Prize: What’s Next For The Light Electric Utility Vehicle

April 13, 2016 by Jenny List 16 Comments

Winner of the third place in last year’s Hackaday Prize was [Chris Low]’s Light Electric Utility Vehicle. In case you think that once a Hackaday Prize is in the bag then that’s it and the project creator packs up and goes home, [Chris] dispels that idea, he’s invested his winnings straight back into his project and posted his latest progress on an improved Mk3 model.

Light Electric Utility Vehicle, 2015-style

We first covered the Light Electric Utility Vehicle back in June 2015 when it was first entered for the 2015 Hackaday Prize. The aim was to produce a rugged and simple small electric vehicle that could be powered by solar energy and that was suitable for the conditions found in South Sudan, where [Chris] works. The vehicle as we saw it then was an articulated design, with chain drive to bicycle-style wheels. The Mk3 version by comparison has lost the articulation in favour of rack-and-pinion steering, has in-hub motors instead of chain drive, and now features coil-spring suspension. You might comment that it has lost some of its original simplicity and become something more like a conventional electric UTV, but along the way it has also become more of a practical proposition as an everyday vehicle.

You can follow the entire build log on the Light Electric Utility Vehicle’s project page on hackaday.io, and below the break have a look at [Chris]’s video showing it in action. Continue reading “After The Prize: What’s Next For The Light Electric Utility Vehicle” →

Hand Gestures Drive Car

April 5, 2016 by Bryan Cockfield 8 Comments

There are a number of ways to control an automobile without using the pedals, and sometimes even without using the steering wheel. Most commonly these alternative control mechanisms are installed in vehicles whose owners are disabled in some way, but [Anurag] has taken this idea of alternative control one step further. He has built a car that can be driven by hand gestures alone.

On a remote controlled car, a Raspberry Pi 2 was installed that handles processing and communication. A wireless network is created on the Pi, and a laptop connects to the Pi over the network. The web camera on the laptop regularly captures frames at 15 fps to check for the driver’s hand gestures. The image is converted to gray scale, thresholded, contours are obtained, and the centroid and farthest points are obtained.

After some calculations are done, a movement decision is taken. The decision is passed to the Pi, which in turn, passed that to the internal chip of the car. All of the code is available on the project’s github page. [Anurag] hopes that this can be scaled up to full sized cars in the future. We’ve seen gesture-based remote controls before that rely on Sonar sensors, so it’s interesting to see one that relies strictly on image processing.

Continue reading “Hand Gestures Drive Car” →

Car Idle Alarm Helps You Stop Wasting Gas While Tweeting

March 29, 2016 by Dan Maloney 79 Comments

[TVMiller] has a bone to pick with you if you let your car idle while you chat or text on your phone. He doesn’t like it, and he wants to break you of this wasteful habit – thus the idle-deterrence system he built that he seems to want on every car dashboard.

In the video below, the target of his efforts is clear – those who start the car then spend time updating Twitter or Instagram. His alarm is just an Arduino Nano that starts a timer when the car is started. Color-coded LEDs mark the time, and when the light goes red, an annoying beep starts to remind you to get on with the business of driving. The device also includes an accelerometer that resets the timer when the vehicle is in motion; the two-minute timeout should keep even the longest stop light from triggering the alarm.

[TVMiller] plans an amped-up version of the device built around an MKR1000 that will dump idle to moving ratios and other stats to the cloud. That’s a little too Big Brother for our tastes, but we can see his point about how wasteful just a few minutes of idling can be when spread over a huge population of vehicles. This hack might make a nice personal reminder to correct wasteful behavior. It could even be rolled into something that reads the acceleration and throttle position directly from the OBD port, like this Internet of Cars hack we featured a while back.

Continue reading “Car Idle Alarm Helps You Stop Wasting Gas While Tweeting” →

The Onion Omega Carputer Can Be Controlled Via WiFi

March 28, 2016 by James Hobson 13 Comments

The Onion Omega, a curiously named ultra-tiny linux-based WiFi board, is a useful little device for everything Internet of Things related. [Daniel] decided to use it to connect his car to the internet.

Most new cars these days have remote start built in, and slowly, manufacturers are catching up to modern technology and including apps to control various features of their vehicles. But for old cars, there’s not much you can do aside from after-market remote start kits and the likes.

Undeterred, [Daniel] wanted to bring his car into the 21st century by manually adding an extra key fob, a remote start protocol, and a data connection to the vehicle’s on board computer.

Continue reading “The Onion Omega Carputer Can Be Controlled Via WiFi” →

Open Source OBD-II Adapter

March 27, 2016 by Anool Mahidharia 55 Comments

Automotive diagnostics have come a long way since the “idiot lights” of the 1980s. The current version of the on-board diagnostics (OBD) protocol provides real time data as well as fault diagnostics, thanks to the numerous sensors connected to the data network in the modern vehicle. While the hardware interface is fairly standardized now, manufacturers use one of several different standards to encode the data. [Alex Sidorenko] has built an open source OBD-II Adapter which provides a serial interface using the ELM327 command set and supports all OBD-II standards.

The hardware is built around the LPC1517 Cortex-M3 microprocessor and can accept a couple of different versions. Here’s the PDF schematic, and a set of Gerber files (ZIP archive) for the PCB layout, if you’d like to dig in to it’s internals. The MC33660 ISO K Line Serial Link Interface device is used to provide bi-directional half-duplex communication interface with the micro-controller. Also included is the TJF1051, a high-speed CAN transceiver that provides an interface between the micro controller and the physical two-wire CAN lines on the ODB-II connector. The serial output from the adapter board is connected to a computer using a serial to USB adapter.

The software is written in C++ for the LPCXpresso IDE – a GNU tool chain for ARM Cortex-M processors, but can also be compiled using a couple of other toolchains. He’s got instructions if you’d like to build the firmware from source, or if you’d like to program the adapter via Flash Magic.

We featured [Alex]’s inexpensive PIC based ODB-II interface way back in 2007, so he’s been working on this for a while and has a good grip on what he’s doing.

Third Person Driving IRL

March 19, 2016 by Kristina Panos 31 Comments

It’s a dream come true: remote control of a real car. Besides being a lot of fun, a life-size RC vehicle has some practical applications, like performing rescue operations or delivering supplies to dangerous areas. For [Carter], [Dave], [Ryan], and [Sean], the dream became reality in the span of 24 caffeine-and-chicken-finger-fueled hours during an Ohio State University hackathon. They dubbed the system MagiKarpet because it sits in place of the floor mat and runs on pixies.

The plan was to control the throttle, brake, and steering of a Chevy Cobalt using a PlayStation controller. For added fun, a camera mounted high above the back bumper would provide a third-person view, and this feed would be displayed on a monitor in the backseat. Everything is controlled by an Arduino Mega. A beefy linear actuator works the brake and is attached temporarily with a band of Shapelock that slips around the pedal. The throttle is pushed by a lever attached to a car window motor. Another motor connects to the steering wheel with cables that can turn it 90° left and right. Although the build was successful, they ran into a couple of issues. But what’s a hackathon experience without a few problems?

The linear actuator was jammed for about an hour after some early testing, but they got it unstuck. The PS controller was borked, so they had to roll their own joysticks. The school wouldn’t let them actually drive it around because of safety (killjoys but we get it), so they put it up on a jack to demonstrate it for the judges. They took second place, though we can’t imagine what would have beat this. Check out the complete build video after the break.

You might remember these guys from last year around this time. They took first place at the same hackathon with Robottermilk Puncakes, a app-controlled pancake machine. Now that you’re hungry for pancakes, feast your eyes on this endless one.

Continue reading “Third Person Driving IRL” →