Firmware Hints That Tesla’s Driver Camera Is Watching

October 13, 2020 by Tom Nardi 163 Comments

Currently, if you want to use the Autopilot or Self-Driving modes on a Tesla vehicle you need to keep your hands on the wheel at all times. That’s because, ultimately, the human driver is still the responsible party. Tesla is adamant about the fact that functions which allow the car to steer itself within a lane, avoid obstacles, and intelligently adjust its speed to match traffic all constitute a driver assistance system. If somebody figures out how to fool the wheel sensor and take a nap while their shiny new electric car is hurtling down the freeway, they want no part of it.

So it makes sense that the company’s official line regarding the driver-facing camera in the Model 3 and Model Y is that it’s there to record what the driver was doing in the seconds leading up to an impact. As explained in the release notes of the June 2020 firmware update, Tesla owners can opt-in to providing this data:

Help Tesla continue to develop safer vehicles by sharing camera data from your vehicle. This update will allow you to enable the built-in cabin camera above the rearview mirror. If enabled, Tesla will automatically capture images and a short video clip just prior to a collision or safety event to help engineers develop safety features and enhancements in the future.

But [green], who’s spent the last several years poking and prodding at the Tesla’s firmware and self-driving capabilities, recently found some compelling hints that there’s more to the story. As part of the vehicle’s image recognition system, which usually is tasked with picking up other vehicles or pedestrians, they found several interesting classes that don’t seem necessary given the official explanation of what the cabin camera is doing.

If all Tesla wanted was a few seconds of video uploaded to their offices each time one of their vehicles got into an accident, they wouldn’t need to be running image recognition configured to detect distracted drivers against it in real-time. While you could make the argument that this data would be useful to them, there would still be no reason to do it in the vehicle when it could be analyzed as part of the crash investigation. It seems far more likely that Tesla is laying the groundwork for a system that could give the vehicle another way of determining if the driver is paying attention.

Continue reading “Firmware Hints That Tesla’s Driver Camera Is Watching” →

The High Seas Are Open Source

March 1, 2020 by Bryan Cockfield 9 Comments

One of the biggest problems of owning an older boat (besides being a money pit – that is common to all boats regardless of age) is the lack of parts and equipment, and the lack of support for those parts if you can find them at all. Like most things, this is an area that can benefit greatly from some open source solutions, which the Open Boat Projects in Germany has been able to show. (Google Translate from German)

This group has solutions for equipment problems of all kinds for essentially any sized boat. At their most recent expo, many people were interested in open source solutions for situations where there is currently only an expensive proprietary option, such as support for various plotting devices. This isn’t the only part of this project, though. It includes many separate projects, like their solutions for autopilot and navigation. There are even complete hardware packages available, all fully documented.

Open source solutions for large, expensive things like this are often few and far between for a number of reasons. There are limited options for other modes of open source transportation too, as it seems like most large companies are not willing to give up their secrets easily. Communities like this, however, give us hope that people will have other options for repairing their vehicles without having to shell out too much money.

Thanks to [mip] for the tip!

Hackaday Links: September 15, 2019

September 15, 2019 by Dan Maloney 28 Comments

It’s probably one of the first lessons learned by new drivers: if you see a big, red fire truck parked by the side of the road, don’t run into it. Such a lesson appears not to have been in the Tesla Autopilot’s driver education curriculum, though – a Tesla Model S managed to ram into the rear of a fire truck parked at the scene of an accident on a southern California freeway. Crash analysis reveals that the Tesla was on Autopilot and following another vehicle; the driver of the lead vehicle noticed the obstruction and changed lanes. Apparently the Tesla reacted to that by speeding up, but failed to notice the stationary fire truck. One would think that the person driving the car would have stepped in to control the vehicle, but alas. Aside from beating up on Tesla, whose AutoPilot feature seems intent on keeping the market for batteries from junked vehicles fully stocked, this just points out how far engineers have to go before self-driving vehicles are as safe as even the worst human drivers.

The tech press is abuzz today with stories about potential union-busting at Kickstarter. Back in March, Kickstarter employees announced their intent to organize under the Office and Professional Employees International Union (OPEIU). On Thursday, two of the union organizers were fired. Clarissa Redwine, who recently hosted a Hack Chat, was one of those released; both she and Taylor Moore are protesting their terminations as an illegal attempt to intimidate Kickstarter employees and keep them from voting for the union. For their part, Kickstarter management says that both employees and two more were released as a result of documented performance issues during the normal review cycle, and that fourteen employees who are in favor of the union were given raises during this cycle, with three of them having been promoted. There will no doubt be plenty more news about this to come.

Would you pay $900 for a Nixie clock? We wouldn’t, but if you choose to buy into Millclock’s high-end timepiece, it may help soften the blow if you think about it being an investment in the future of Nixie tubes. You see, Millclock isn’t just putting together an overpriced clock that uses surplus Russian Nixies – they’re actually making brand new tubes. Techmoan recently reviewed the new clock and learned that the ZIN18 tubes are not coming from Czech Republic-based Dalibor Farný, but rather are being manufactured in-house. That’s exciting news for Nixie builders everywhere; while Dalibor’s tubes are high-quality products, it can’t hurt to have a little competition in the market. Nixies as a growth industry in 2019 – who’da thunk it?

We ran across an interesting project on Hackaday.io the other day, one that qualifies as a true hack. How much house can you afford? A simple question, but the answer can be very difficult to arrive at with the certainty needed to sign papers that put you on the hook for the next 30 years. Mike Ferarra and his son decided to answer this question – in a circuit simulator? As it turns out, circuit simulators are great at solving the kinds of non-linear simultaneous equations needed to factor in principle, interest, insurance, taxes, wages, and a host of other inflows and outflows. Current sources represent money in, current sinks money paid out. Whatever is left is what you can afford. Is this how Kirchoff bought his house?

And finally, is your parts inventory a bit of a mystery? Nikhil Dabas decided that rather than trying to remember what he had and risk duplicating orders, he’d build an application to do it for him. Called WhatDidIBuy, it does exactly what you’d think; it scrapes the order history pages of sites like Adafruit, Digi-Key, and Mouser and compiles a list of your orders as CSV files. It’s only semi-automated, leaving the login process to the user, but something like this could save a ton of time. And it’s modular, so adding support for new suppliers is a simple as writing a new scraper. Forgot what you ordered from McMaster, eBay, or even Amazon? Now there’s an app for that.

Self-Driven: Uber And Tesla

April 2, 2018 by Elliot Williams 164 Comments

Self-driving cars have been in the news a lot in the past two weeks. Uber’s self-driving taxi hit and killed a pedestrian on March 18, and just a few days later a Tesla running in “autopilot” mode slammed into a road barrier at full speed, killing the driver. In both cases, there was a human driver who was supposed to be watching over the shoulder of the machine, but in the Uber case the driver appears to have been distracted and in the Tesla case, the driver had hands off the steering wheel for six seconds prior to the crash. How safe are self-driving cars?

Trick question! Neither of these cars were “self-driving” in at least one sense: both had a person behind the wheel who was ultimately responsible for piloting the vehicle. The Uber and Tesla driving systems aren’t even comparable. The Uber taxi does routing and planning, knows the speed limit, and should be able to see red traffic lights and stop at them (more on this below!). The Tesla “Autopilot” system is really just the combination of adaptive cruise control and lane-holding subsystems, which isn’t even enough to get it classified as autonomous in the state of California. Indeed, it’s a failure of the people behind the wheels, and the failure to properly train those people, that make the pilot-and-self-driving-car combination more dangerous than a human driver alone would be.

A self-driving Uber Volvo XC90, San Francisco.

You could still imagine wanting to dig into the numbers for self-driving cars’ safety records, even though they’re heterogeneous and have people playing the mechanical turk. If you did, you’d be sorely disappointed. None of the manufacturers publish any of their data publicly when they don’t have to. Indeed, our glimpses into data on autonomous vehicles from these companies come from two sources: internal documents that get leaked to the press and carefully selected statistics from the firms’ PR departments. The state of California, which requires the most rigorous documentation of autonomous vehicles anywhere, is another source, but because Tesla’s car isn’t autonomous, and because Uber refused to admit that its car is autonomous to the California DMV, we have no extra insight into these two vehicle platforms.

Nonetheless, Tesla’s Autopilot has three fatalities now, and all have one thing in common — all three drivers trusted the lane-holding feature well enough to not take control of the wheel in the last few seconds of their lives. With Uber, there’s very little autonomous vehicle performance history, but there are leaked documents and a pattern that makes Uber look like a risk-taking scofflaw with sub-par technology that has a vested interest to make it look better than it is. That these vehicles are being let loose on public roads, without extra oversight and with other traffic participants as safety guinea pigs, is giving the self-driving car industry and ideal a black eye.

If Tesla’s and Uber’s car technologies are very dissimilar, the companies have something in common. They are both “disruptive” companies with mavericks at the helm that see their fates hinging on getting to a widespread deployment of self-driving technology. But what differentiates Uber and Tesla from Google and GM most is, ironically, their use of essentially untrained test pilots in their vehicles: Tesla’s in the form of consumers, and Uber’s in the form of taxi drivers with very little specific autonomous-vehicle training. What caused the Tesla and Uber accidents may have a lot more to do with human factors than self-driving technology per se.

You can see we’ve got a lot of ground to cover. Read on!

Continue reading “Self-Driven: Uber And Tesla” →

Self-Driving Cars Are Not (Yet) Safe

December 5, 2016 by Elliot Williams 123 Comments

Three things have happened in the last month that have made me think about the safety of self-driving cars a lot more. The US Department of Transportation (DOT) has issued its guidance on the safety of semi-autonomous and autonomous cars. At the same time, [Geohot]’s hacker self-driving car company bailed out of the business, citing regulatory hassles. And finally, Tesla’s Autopilot has killed its second passenger, this time in China.

At a time when [Elon Musk], [President Obama], and Google are all touting self-driving cars to be the solution to human error behind the wheel, it’s more than a little bold to be arguing the opposite case in public, but the numbers just don’t add up. Self-driving cars are probably not as safe as a good sober driver yet, but there just isn’t the required amount of data available to say this with much confidence. However, one certainly cannot say that they’re demonstrably safer.

Continue reading “Self-Driving Cars Are Not (Yet) Safe” →

A Quadcopter Controlled By A Pi Zero

February 16, 2016 by Brian Benchoff 57 Comments

Flight controllers for quadcopters and other drones are incredible pieces of engineering. Not only do these boards keep an aircraft level, they do so while keeping the drone in one place, or reading a GPS sensor and flying it from waypoint to waypoint. The latest of these flight controllers is built on everyone’s favorite $5 computer, the Raspberry Pi Zero.

The PXFmini controller and autopilot shield is the latest project from Erle Robotics that puts eight servo outputs on the Pi, barometer and IMU sensors, a power supply, and all the adapters to turn the Raspberry Pi Zero into a capable flight controller. Since the Pi Zero will have some computational horsepower left over after keeping a quadcopter level, there’s a possibility of some very cool peripherals. Erle Robotics has been working with depth cameras and Lidar on more than a few drones. This makes for some interesting applications we can only imagine now.

The schematics for the PXFmini are open source in the best traditions of the RC and drone community and will be available soon. You can check out a video of the FXPmini flying around an office below.

Continue reading “A Quadcopter Controlled By A Pi Zero” →

The Autopilot Shield For The Raspberry Pi

June 4, 2014 by Brian Benchoff 29 Comments

Navio

In the world of drones, quadcopters, and unmanned aerial vehicles, the community has pretty much settled on AVR microcontrollers for the low end, and ARM for the high performance boards. If the FAA doesn’t screw things up, there will soon be another market that requires even more computational power, and Navio, the autopilot shield for the Pi, is just the thing for it.

Where high end multicopter and autopilot boards like the OpenPilot Revolution use ARM micros, there’s a small but demanding segment of the hobby that needs even more processing power. Think of something like the Outback Challenge, where fixed-wing drones search the desert for a lost mannequin autonomously. You’re going to need OpenCV for that, and that means Linux.

Navio is a shield for the Raspberry Pi, complete with a barometric pressure sensor, gyros, accelerometer, and compass, and GPS. It’s designed to run a more real-time version of Linux, and has the ability to do some interesting telemetry configurations – putting a 3G modem on the Navio isn’t much of a problem, and since it’s a Raspi, doing image processing of a downward facing camera is just a matter of writing the code.

The Navio team is currently running an Indiegogo campaign, with the baseline version available for $145. That’s pretty close to the price of the OpenPilot Revolution. There’s also a version upgraded with the U-blox NEO-6T that allows for on-board processing of raw GPS data.