A great place to get your feet wet with the data-network-wonderland that is modern-day automobiles is the Car Hacking Village at DEF CON. I stopped by on Saturday afternoon to see what it was all about and the place was packed. From Ducati motorcycles to junkyard instrument clusters, and from mobility scooters to autonomous RC test tracks, this feels like one of the most interactive villages in the whole con.
The news is full of self-driving cars and while there is some bad news, most of it is pretty positive. It seems a foregone conclusion that it is just a matter of time before calling for an Uber doesn’t involve another person. But according to a recent article, [Ernst Dickmanns] — a German aerospace engineer — built three autonomous vehicles starting in 1986 and culminating with on-the-road demonstrations in 1994 for Daimler.
It is hard to imagine what had to take place to get a self-driving car in 1986. The article asserts that you need computer analysis of video at 10 frames a second minimum. In the 1980s doing a single frame in 10 minutes was considered an accomplishment. [Dickmanns’] vehicles borrowed tricks from how humans drive. They focused on a small area at any one moment and tried to ignore things that were not relevant.
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.
You have doubtlessly heard the news. A robotic Uber car in Arizona struck and killed [Elaine Herzberg] as she crossed the street. Details are sketchy, but preliminary reports indicate that the accident was unavoidable as the woman crossed the street suddenly from the shadows at night.
If and when more technical details emerge, we’ll cover them. But you can bet this is going to spark a lot of conversation about autonomous vehicles. Given that Hackaday readers are at the top of the technical ladder, it is likely that your thoughts on the matter will influence your friends, coworkers, and even your politicians. So what do you think?
You might think that you do not have what it takes to build a self-driving car, but you’re wrong. The mistake you’ve made is assuming that you’ll be controlling a two-ton death machine. Instead, you can give it a shot without the danger and on a relatively light budget. [Otavio] and [Will] got into self-driving vehicles using radio controlled (RC) cars.
[Otavio] slapped a MacBook Pro on an RC car to do the heavy lifting and called it carputer. The computer reads Hall effect sensor data from the motor to establish distance traveled (this can be used to calculate speed) and watches the stream from a webcam perched on the chassis. These two sources are fed into a neural network using TensorFlow. You train the system by driving the vehicle manually through the course a few times and then let it drive itself.
In the video interview below, you get a look at the car and [Otavio] gives commentary on how the system works as we see playback of a few races, including the Sparkfun 2016 Autonomous Vehicle Competition. I apologize for the poor audio, they lost the booth lottery and were next door to an incredibly noisy robot band (video proof) so we were basically shouting at each other. But I think you’ll agree it’s worth it to get a look at the races. Continue reading “Self-Driving RC Cars with TensorFlow; Raspberry Pi or MacBook Onboard”
Seems like all the buzz about autonomous vehicles these days centers around self-driving cars. Hands-free transportation certainly has its appeal – being able to whistle up a ride with a smartphone app and converting commute time to Netflix binge time is an alluring idea. But is autonomous personal transportation really the killer app that everyone seems to think it is? Wouldn’t we get more bang for the buck by automating something a little more mundane and a lot more important? What about automating the shipping of freight?
Look around the next time you’re not being driven to work by a robot and you’re sure to notice a heck of a lot of trucks on the road. From small panel trucks making local deliveries to long-haul tractor trailers working cross-country routes, the roads are lousy with trucks. And behind the wheel of each truck is a human driver (or two, in the case of team-driven long-haul rigs). The drivers are the weak point in this system, and the big reason I think self-driving trucks will be commonplace long before we see massive market penetration of self-driving cars.
Drones fill the sky raining hellfire on unsuspecting civilians below. Self-driving cars only cause half as many accidents as carbon-based drivers. Autonomous vehicles are the future, no matter how bleak that future is. One thing we haven’t seen much of is autonomous marine vehicles, be they submarines, hovercrafts, or sailboats. That’s exactly what [silvioBi] is building for his entry into the Hackaday Prize: a sailboat that will ply the waters of Italy’s largest lake.
Every boat needs a hull, but this project will need much more, from electronics to solar panels to sensors. Luckily for [silvio], choosing a hull is as simple as heading over to eBay. [silvio] picked up a fiberglass boat hull for about €40 that fill fit both is needs and his workbench.
The electronics are a bit trickier, but the basic plan is to cover the deck with solar panels, and use a few sensors including GPS, IMU, and an anemometer to steer this sailboat around a lake. Building an autonomous vehicle is a hard challenge, and for the electronics, [silvio] has a trick up his sleeve: he’s using redundant electronics. All the sensors are connected via an I2C bus, so why not put two microcontrollers on that bus in a master and slave configuration? It won’t add much mass, and given the problems had by a few of the teams behind robotic sailing competitions, a bit of redundancy isn’t a bad thing to have.