A simple robot that performs line-following or obstacle avoidance can fit all of its logic inside a single Arduino sketch. But as a robot’s autonomy increases, its corresponding software gets complicated very quickly. It won’t be long before diagnostic monitoring and logging comes in handy, or the desire to encapsulate feature areas and orchestrate how they work together. This is where tools like the Robot Operating System (ROS) come in, so we don’t have to keep reinventing these same wheels. And Open Robotics just released ROS 2 Dashing Diademata for all of us to use.
ROS is an open source project that’s been underway since 2007 and updated regularly, each named after a turtle species. What makes this one worthy of extra attention? Dashing marks the first longer term support (LTS) release of ROS 2, a refreshed second generation of ROS. All high level concepts stayed the same, meaning almost everything in our ROS orientation guide is still applicable in ROS 2. But there were big changes under the hood reflecting technical advances over the past decade.
ROS was built in an age where a Unix workstation cost thousands of dollars, XML was going to be how we communicate all data online, and an autonomous robot cost more than a high-end luxury car. Now we have $35 Raspberry Pi running Linux, XML has fallen out of favor due to processing overhead, and some autonomous robots are high-end luxury cars. For these and many other reasons, the people of Open Robotics decided it was time to make a clean break from legacy code.
The break has its detractors, as it meant leaving behind the vast library of freely available robot intelligence modules released by researchers over the years. Popular ones were (or will be) ported to ROS 2, and there is a translation bridge sufficient to work with some, but the rest will be left behind. However, this update also resolved many of the deal-breakers preventing adoption outside of research, making ROS more attractive for commercial investment which should bring more robots mainstream.
Judging by responses to the release announcement, there are plenty of people eager to put ROS 2 to work, but it is not the only freshly baked robotics framework around. We just saw Nvidia release their Isaac Robot Engine tailored to make the most of their Jetson hardware.
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.
Continue reading “Car Hacking At DEF CON 26”
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.
Continue reading “Was The Self Driving Car Invented In The 1980s?”
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”