Self-Driven: Uber And Tesla

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”

Scotty Allen Visits Strange Parts, Builds An IPhone

Scotty Allen has a YouTube blog called Strange Parts; maybe you’ve seen his super-popular video about building his own iPhone “from scratch”. It’s a great story, and it’s also a pretext for a slightly deeper dive into the electronics hardware manufacturing, assembly, and repair capital of the world: Shenzhen, China. After his talk at the 2017 Superconference, we got a chance to sit down with Scotty and ask about cellphones and his other travels. Check it out:

The Story of the Phone

Scotty was sitting around with friends, drinking in one of Shenzhen’s night markets, and talking about how bizarre some things seem to outsiders. There are people sitting on street corners, shucking cellphones like you’d shuck oysters, and harvesting the good parts inside. Electronics parts, new and used, don’t come from somewhere far away and there’s no mail-ordering. A ten-minute walk over to the markets will get you everything you need. The desire to explain some small part of this alternate reality to outsiders was what drove Scotty to dig into China’s cellphone ecosystem.

Continue reading “Scotty Allen Visits Strange Parts, Builds An IPhone”

What’s Inside A Neonode Laser Sensor?

Every once in a while, you get your hands on a cool piece of hardware, and of course, it’s your first instinct to open it up and see how it works, right? Maybe see if it can be coaxed into doing just a little bit more than it says on the box? And so it was last Wednesday, when I was at the Embedded World trade fair, and stumbled on a cool touch display floating apparently in mid-air.

The display itself was a sort of focused Pepper’s Ghost illusion, reflected off of an expensive mirror made by Aska3D. I don’t know much more — I didn’t get to bring home one of the fancy glass plates — but it looked pretty good. But this display was interactive: you could touch the floating 2D projection as if it were actually there, and the software would respond. What was doing the touch response in mid-air? I’m a sucker for sensors, so I started asking questions and left with a small box of prototype Neonode zForce AIR sensor sticks to take apart.

The zForce sensors are essentially an array of IR lasers and photodiodes with some lenses that limit their field of view. The IR light hits your finger and bounces back to the photodiodes on the bar. Because the photodiodes have a limited angle over which they respond, they can be used to triangulate the distance of the finger above the display. Scanning quickly among the IR lasers and noting which photodiodes receive a reflection can locate a few fingertips in a 2D space, which explained the interactive part of the floating display. With one of these sensors, you can add a 2D touch surface to anything. It’s like an invisible laser harp that can also sense distance.

The intended purpose is fingertip detection, and that’s what the firmware is good at, but it must also be the case that it could detect the shape of arbitrary (concave) objects within its range, and that was going to be my hack. I got 90% of the way there in one night, thanks to affordable tools and free software that every hardware hacker should have in their toolbox. So read on for the unfortunate destruction of nice hardware, a tour through some useful command-line hardware-hacking tools, and gratuitous creation of animations from sniffed SPI-like data pulled off of some test points.

Continue reading “What’s Inside A Neonode Laser Sensor?”

Can Open-source Hardware Be Like Open-source Software?

Hardware and software are certainly different beasts. Software is really just information, and the storing, modification, duplication, and transmission of information is essentially free. Hardware is expensive, or so we think, because it’s made out of physical stuff which is costly to ship or copy. So when we talk about open-source software (OSS) or open-source hardware (OSHW), we’re talking about different things — OSS is itself the end product, while OSHW is just the information to fabricate the end product, or have it fabricated.

The fabrication step makes OSHW essentially different from OSS, at least for now, but I think there’s something even more fundamentally different between the current state of OSHW and OSS: the pull request and the community. The success or failure of an OSS project depends on the community of people developing it, and for smaller projects that can hinge on the ease of a motivated individual digging in and contributing. This is the main virtue of OSS in my opinion: open-source software is most interesting when people are reading and writing that source.

With pure information, it’s essentially free to copy, modify, and push your changes upstream so that others can benefit. The open hardware world is just finding its feet in this respect, but that’s changing as we speak, and I have great hopes. Costs of fabrication are falling all around, open and useful tools are being actively developed to facilitate interchange of the design information. I think there are lessons that OSHW can learn from the OSS community’s pull-request culture, and that will help push the hardware hacker’s art forward.

What would it take to get you to build someone else’s OSHW project, improve on it, and contribute back? That’s a question worth a thoughtful deep dive.

Continue reading “Can Open-source Hardware Be Like Open-source Software?”

Mechanical Clocks That Never Need Winding

What is it about mechanical clocks? Maybe it’s the gears, or the soft tick-tocking that they make? Or maybe it’s the pursuit of implausible mechanical perfection. Combine mechanical clocks with “free” energy harvested from daily temperature and pressure variation, and we’re hooked.

Both the Beverly Clock, built by Arthur Beverly in 1864, and the Atmos series of clocks built between 1929 and 1939, run exclusively on the expansion and contraction of a volume of air (Beverly) or ethyl chloride (Atmos) over the day to wind up the clock via a ratchet. The Beverly Clock was apparently a one-off, and it’s still running today. And with over 500,000 Atmos clocks produced, there must be some out there.

Although we had never heard of it, this basic idea is really old. Clicking through Wikipedia (like you do!) got us to Cox’s Timepiece, which is powered by the movement of 68 kg of mecury under atmospheric pressure. It is currently not running, but housed in the Victoria and Albert Museum in London. Even older is a clock that we couldn’t find any info on that dates from 1620, invented by Cornelius Drebbel. Anyone know anything?

We’ve had energy harvesting on our mind lately, and the article on the Beverly Clock says that it gets 31 μWh over a day when the temperature swings by 3.3 °C. Put into microcontroller perspective, this is 0.39 μA at 3.3 V, so you’ll have to be pretty careful about your sleep modes, and an LED is out of the question. How amazing is it, then, that this can power a mechanical clock?

Thanks [Luke], [hex4def6], and [Wallace Owen] for tipping us off to these in the comment section!

OpenSCAD: Tieing It Together With Hull()

What’s your favorite OpenSCAD command? Perhaps it’s intersection() or difference()? Or are you a polygon() and extrude() modeler? For me, the most useful, and maybe most often overlooked, function is hull(). Hull() does just what it says on the can — creates a convex hull around the objects that are passed to it as children — but that turns out to be invaluable.

Hull() solves a number of newbie problems: making things round and connecting things together. And with a little ingenuity, hull() can provide a nearly complete modelling strategy all on its own. If you use OpenSCAD and your creations end up with hard edges, or you spend too much time figuring out angles, or if you just want to experience another way to get the job done, read on!

Continue reading “OpenSCAD: Tieing It Together With Hull()”

You Can Learn A Lot From A Blinkenrocket

At this year’s Chaos Communication Congress, we caught up with [muzy] and [overflo], who were there with a badge and soldering project they designed to teach young folks how to solder and program. Blinkenrocket is a basically a 64-LED matrix display and just enough support hardware to store and display animations, and judging by the number of blinking rockets we saw around the necks of attendees, it was a success.

Their talk at 34C3 mostly concerns the production details, design refinements, and the pitfalls of producing thousands of a thing. If you’re thinking of building a hardware kit or badge on this scale, you should really check it out and crib some of their production optimization tricks.

For instance, instead of labelling the parts “C2” or “R: 220 Ohms”, they used a simple color-coding scheme. This not only makes it easier for kids to assemble, but it also means that they didn’t have to stick 1,000 part labels on every component. Coupled with [overflo]’s Zerhacker, SMD parts in strips were cut to the right length and color-coded in one step, done by machine.

The coolest feature of the Blinkenrocket itself is the audio programming interface. It’s like in the bad old days of software stored on cassette tapes, but it’s a phenomenal interface for getting a simple animation out of a web app and straight into a piece of minimal hardware — just plug it into a laptop or cell phone’s audio out and press “play” in the browser. The original design tried to encode the data in the pulse-length of square waves, but this turned out to be very hardware dependent. The final design used frequency-shift keying. What’s old is new again.

Everything you could want to know about the design, its code, and even the website itself are up on the project’s GitHub page, so go check it out. If you’d like to arrange a Blinkenrocket workshop yourself, shoot [muzy] or [overflo] an e-mail. Full disclosure: [overflo] gave us a kit, the “hard-mode” SMD one with 0805 1206 parts, and it was fun to assemble and program.