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”
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?
Continue reading “Uber Has An Autonomous Fatality”
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.
Continue reading “Automate the Freight: Robotic Deliveries Are on the Way”
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.
[Andrey Nechypurenko] has posted the second part of his robotics ground vehicle design guide. In his first post [Andrey] detailed the mechanical design decisions he faced. [Andrey] now begins covering the electrical components, starting with manual control using a standard radio control system. To accomplish this an RC system was used with an MD22 h-bridge driver and a picoUPS.
The MD22 is a neat motor control board which can take the PWM signals from the radio controller and use this to drive the DC motors. Optionally it can also use an I2C interface, giving a nice migration path to integrate with a microcontroller. Until that happens this can’t really be called a robot — its more of an RC vehicle. But the iterative design and build process he’s using is a good one!
The picoUPS provides on-board battery charging. Due to its UPS heritage it also allows the vehicle to be powered from an external supply, which has proved useful during development. Finally, a 5v regulator was required to supply the on-board digital logic. [Andrey] wanted a quick drop in solution with a budget large enough to allow for future expansion and went with the Pololu D15V35F5S3 which can supply 3.5 amps in a small and easy to use module.
After breadboarding the system [Andrey] fabricated a PCB to integrate all the components. The next step is to add sensors and and embedded computer to the platform.
Continue reading “Robot Control Ties RC Receiver to Motor Controller”
[Andrey Nechypurenko] has put together an excellent design guide describing the development of his a20 grou1nd vehicle and is open sourcing all the schematics and source code.
One of [Andrey]’s previous designs used a Pololu tracked chassis. But this time he designed everything from scratch. In his first post on the a20, [Andrey] describes the mechanical design of the vehicle. In particular focusing on trade-offs between different drive systems, motor types, and approaches to chassis construction. He also covers the challenges of using open source design tools (FreeCAD), and other practical challenges he faced. His thorough documentation makes an invaluable reference for future hackers.
[Andrey] was eager to take the system for a spin so he quickly hacked a motor controller and radio receiver onto the platform (checkout the video below). The a20s final brain will be a Raspberry Pi, and we look forward to more posts from [Andrey] on the software and electronic control system.
Continue reading “Amazingly Detailed Robotics Ground Vehicle Guide”