Anyone old enough to have driven before the GPS era probably wonders, as we do, how anyone ever found anything. Navigation back then meant outdated paper maps, long detours because of missed turns, and the far too frequent stops at dingy gas stations for the humiliation of asking for directions. It took forever sometimes, and though we got where we were going, it always seemed like there had to be a better way.
Indeed there was, but instead of waiting for the future and a constellation of satellites to guide the way, some clever folks in the early 1970s had a go at dead reckoning systems for car navigation. The video below shows one, called Cassette Navigation, in action. It consisted of a controller mounted under the dash and a modified cassette player. Special tapes, with spoken turn-by-turn instructions recorded for a specific route, were used. Each step was separated from the next by a tone, the length of which encoded the distance the car would cover before the next step needed to be played. The controller was hooked to the speedometer cable, and when the distance traveled corresponded to the tone length, the next instruction was played. There’s a long list of problems with this method, not least of which is no choice in road tunes while using it, but given the limitations at the time, it was pretty ingenious.
Dead reckoning is better than nothing, but it’s a far cry from GPS navigation. If you’re still baffled by how that cloud of satellites points you to the nearest Waffle House at 3:00 AM, check out our GPS primer for the details.
Old cars are great. For the nostalgia-obsessed like myself, getting into an old car is like sitting in a living, breathing representation of another time. They also happen to come with their fair share of problems. As the owner of two cars which are nearing their 30th birthdays, you start to face issues that you’d never encounter on a younger automobile. The worst offender of all is plastics. Whether in the interior or in the engine bay, after many years of exposure to the elements, parts become brittle and will crack, snap and shatter at the slightest provocation.
You also get stuck bolts. This was the initial cause of frustration with my Volvo 740 Turbo on a cold Sunday afternoon in May. As I tried in vain to free the fuel rail from its fittings, I tossed a spanner in frustration and I gave up any hope of completing, or indeed, starting the job that day. As I went to move the car back into the driveway, I quickly noticed a new problem. The accelerator was doing approximately nothing. Popping the hood, found the problem and shook my head in resignation. A Volvo 740 Turbo is fitted with a ball-jointed linkage which connects the accelerator cable to the throttle body itself. In my angst, the flying spanner had hit the throttle body and snapped the linkage’s plastic clips. It was at this point that I stormed off, cursing the car that has given me so much trouble over the past year.
The CAN bus is a rich vein to mine for a hacker: allowing the electronic elements of most current vehicles to be re-purposed and controlled with ease. [MikrocontrollerProjekte] has reverse engineered a CAN bus media and navigation controller and connected it to an STM32F746G-Discovery board. The STM32 is in turn connected to an Android phone, and allows the media controller to trigger a large number of functions on the phone, including music playback, maps, and general Android navigation.
When reverse engineering the controller, [MikrocontrollerProjekte] employed a variety of approaches. A small amount of information was found online, some fuzzing was done with random CAN bus IDs and messages, as well as some data logging with the device inside the car to identify message data to the relevant IDs on the bus.
The STM32F746G-Discovery board acts as a Human Interface Device (HID), emulating a mouse and keyboard connected to the Android phone via USB OTG. The LCD screen shows the output of the keystrokes and touchpad area. We’re not sure how useful the mouse-emulation would be, given that the phone has a touchscreen, but the media functions work really well, and would also make a really snazzy music controller for a PC.
If you have a car that is getting on in years, it may be missing some of the latest frills and features that the latest models sport. [Muris] has a slightly dated Audi A3 8P which did not have an AUTO setting for the headlights. In the newer models, this feature turns on the headlights when the ambient light falls below a threshold level (overcast conditions or when going through a tunnel), or when the windshield wipers are turned on. The light sensor is integrated behind the rear view mirror in a special mount, requiring an expensive windshield upgrade if he were to opt for the factory retrofit. Instead, he decided to build his own Automatic Headlights Sensor upgrade for his Audi A3.
His local regulations require the car headlights to be on all the time when the vehicle is in motion. So adding this feature may seem moot at first sight. But [Muris] programmed the headlights to be powered at 70% during daytime conditions and switch to 100% when his sensor detects low ambient light conditions. In the power save mode, all of the other non-essential lights (number plate, tail light) are also turned off to hopefully extend their life. He achieved this by using the VCDS (VAG-COM Diagnostic System) – a widely used aftermarket diagnostics tool for VW-Audi Group vehicles. His tiny circuit switches the lights between the two power settings.
His plan was to install the device without disturbing the original wiring or light switch assembly in any way. The low-powered device consists of a PIC micro-controller, an LDR (light dependent resistor) for light sensing and a low current relay which switches between the two modes. Setting the threshold at which the circuit switches the output is adjusted by a variable trimpot acting as a voltage divider with the LDR. [Muris] wired up a short custom harness which let him install this circuit between the default light switch and the car electronics. After switching on power, he has 15 seconds to enable or disable his unit by toggling the light switch five times, and that status gets stored in memory. The tiny board is assembled using SMD parts and is protected with a heatshrink sleeve. The circuit would work equally well with a lot of other cars, so If you’ve got one which could do with this feature upgrade, then [Muris] has the Eagle CAD files and code available for download on his blog.
Check out the video below where he runs a demo, describes his circuit in detail and then proceeds to assemble the PCB without using a vise or a third hand to hold the PCB. That’s a fancy watch he’s sporting at 00:50 s down the video.
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.
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!
Frankencars are built from the parts of several cars to make one usable vehicle. [Jim Belosic] has crossed the (finish) line with his Teslonda. In the most basic sense, it is the body of a Honda Accord on top of the drive train of a Tesla Model S. The 1981 Honda was the make and model of his first car, but it wasn’t getting driven. Rather than sell it, he decided to give it a new life with electricity, just like Victor Frankenstein.
In accord with Frankenstein’s monster, this car has unbelievable strength. [Jim] estimates the horsepower increases by a factor of ten over the gas engine. The California-emissions original generates between forty and fifty horsepower while his best guess places the horsepower over five-hundred. At this point, the Honda body is just holding on for dear life. Once all the safety items, like seatbelts, are installed, the driver and passengers will be holding on for the same reason.
This kind of build excites us because it takes something old, and something modern, and marries the two to make something in a class of its own. And we hate to see usable parts sitting idle.
Whether we like it or not, eventually the day will come where we have to admit that we outgrew our childhood toys — unless, of course, we tech them up in the name of science. And in some cases we might get away with simply scaling things up to be more fitting for an adult size. [kenmacken] demonstrates how to do both, by building himself a full-size 1:1 RC car. No, we didn’t forget a digit here, he remodeled an actual Honda Civic into a radio controlled car, and documented every step along the way, hoping to inspire and guide others to follow in his footsteps.
To control the Civic with a standard RC transmitter, [kenmacken] equipped it with a high torque servo, some linear actuators, and an electronic power steering module to handle all the mechanical aspects for acceleration, breaking, gear selection, and steering. At the center of it all is a regular, off-the-shelf Arduino Uno. His write-up features plenty of videos demonstrating each single component, and of course, him controlling the car — which you will also find after the break.
[kenmacken]’s ultimate goal is to eventually remove the radio control to build a fully autonomous self-driving car, and you can see some initial experimenting with GPS waypoint driving at the end of his tutorial. We have seen the same concept in a regular RC car before, and we have also seen it taken further using neural networks. Considering his background in computer vision, it will be interesting to find out which path [kenmacken] will go here in the future.