An Open HW/SW API for Your Car

Today’s post is a bit of a diversion, but I think it will be of interest to almost everyone interested in hobby robotics.  Rather than about robotic vehicles, it’s about a new system in development that will let us develop our own apps based on data from the full-sized car you drive around in.  About 5 years ago in my day job, I argued the future of in-vehicle electronics would include an automaker supported read-only interface to the data bus, available to third party developers to build upon.  Many auto company engineers I worked with stated this would never happen and never be supported.  Well, for some car companies, #define  NEVER  5


“Many companies are already offering tools to hook into the driver’s interface, but for the most part they have limited availability for hobbyists and developers. What if the system was designed from the ground up to be open source and to give insight into the vehicle itself?”  This sounds like a Maker’s daydream, but it’s about to be reality, at least for Ford owners.  Ford Motor Company and Bug Labs have teamed up to produce the OpenXC Platform, now in limited beta testing.

This will provide read-only access via USB to many vehicle parameters in real-time, allowing developers, including hobbyists, to write applications running on whatever hardware they choose to interface.  The system is currently in limited beta testing.  According to press reports, beta testers include the University of Michigan, MIT, Stanford, Weather Underground, and India’s HCL Technologies.


All modern cars use a data bus, the CAN bus, for exchanging information between the various electronic controller modules and other devices found on today’s cars.  One device on the bus provides a port for accessing the bus.  It is often found somewhere near the driver under the dashboard.  This On Board Diagnostics II (OBD-II) port is required by law, as it is used to check for proper operation of air pollution control equipment.    However, once it was required, automakers began using it as a general diagnostics port.  There are standard codes for much of the data, however automakers are not required to support most of these codes, and also typically add proprietary codes. The codes and their availability also vary by model and model year.

the OpenXC Platform

Based on my reading of the project’s website,  the project provides a read-only interface (called the CAN translator module) that takes data from the OBD-II port, translates it into non-proprietary codes, and makes it available over a USB port.  Apparently the hardware in the reference implementation uses a ChipKit board, which uses a PIC microcontroller but can run Arduino code, along with a network shield.   They state that the initial testers have access to the C code, but I’m wondering if it will be released to hobbyists, as it may give insights into Ford’s proprietary codes (they imply as much, stating that automakers might just supply compiled code).  You can plug whatever you want into the USB port, but they are developing a reference implementation built around an Android tablet computer.

While there are over 100 data elements available from the OBD-II, they are starting with support for just a subset, which can be found on the project’s Signal Translation Specification page.  They include:

  • steering wheel angle
  • engine_speed (RPM)
  • vehicle speed
  • accelerator pedal position
  • brake pedal status
  • odometer
  • fuel level
  • fuel consumed since restart
  • windshield wiper status
  • latitude and longitude (presumably only for GPS-equipped vehicles)

As I mentioned above, codes vary by make, model, and year.  Currently, the system is said to support Ford 2011/2012 Focus, 2012 Mustang, 2012 Fiesta, and 2011 Figo.  While limited to Fords at present, they hope that this becomes a broader de facto standard.

I think this is a taste of exciting things to come, and I’d love to get my hands on a developer kit.

Picture from,  used under Creative Commons Attribution 3.0 License.

Measurement Precision versus Control Precision

Spent some time today chasing down a problem that’s probably obvious to experienced developers, but it wasn’t to me, and I’ll guess to other newcomers.  There’s obviously a limit to both the position and heading precision that can be obtained purely through odometry based on wheel encoders.  For distance traveled in a short delta of time, the precision is a function of the smallest fraction of wheel rotation you can measure and the wheel diameter.  For heading, it’s also a function of the wheelbase (the distance between the wheels on each side).  The heading precision tends to be much poorer than the distance.   For example, if I can measure 1/8th of a revolution of a 1″ diameter wheel, I can measure increments of 1/8 x pi x 1 = 0.39 inches.  If the wheelbase is 4 inches, and I’m using tank style steering, then the smallest heading increment I can measure is pi * ( 1/8 * 1) / 4 = 0.098 radians or about 5.6 degrees.  That lack of precision is one factor in the errors that can build up very quickly when making a number of turns.  (Slippage can also be a major contributor to the error).   [The Using Dead Reckoning section in Enabling Your Robot to Keep Track of It’s Position from Ridgesoft has a good explanation of this]

When trying to use dead reckoning to turn, you typically can’t get the measured heading to exactly match the desired heading due to these precision limits, so you have to set a window defining “close enough.”  So far, so good.  In my case, I’m using interrupts to count clicks on each of two wheel encoders, so I could be sure not to miss a unit.  All was working well.  In tests, I’d see 0 or 1 click of the encoder on each wheel each time my Arduino code executed the main loop and updated the position and heading.  I set my “close enough” threshold accordingly.  Then I added doubled the resolution on the encoders and added a lot of serial.print() commands when in debugging mode.  Suddenly my formally working robot, which now had more precise navigation, would go haywire.  It would often work fine, but at other times it would spin around in multiple circles when turning to the next waypoint or avoiding an obstacle.

It took a lot of debugging to figure out the problem. With interrupts now occurring with twice the frequency, and the execution loop slowing down due to numerous serial print statements, there were often 3-4 encoder clicks per update.   This meant that the robot was sometimes turning 4x more than the maximum precision of my measurements between execution of the appropriate code in the main loop.  Therefore it would sometimes, by luck, hit within the good enough window when turning, but other times it would be below the window on one pass and above it the next, and therefore keep turning and turning until by luck it hit within the window.  My control precision was only 1/4 of my measurement precision.

I’ve done three things to adjust:

  1. Ensure that don’t have the debugging serial.print() statements in except when doing a “bench test.”  (see the use of the #if preprocessor directive if you’re new to C or Arduino programming).  That speeds up loop execution.
  2. Slow down the turning speed of the robot.  By turning slower I can get the control precision to more closely match the measurement precision.
  3. Relax the window slightly, making control a bit sloppier, but ensuring I don’t miss the window if adjustments 1 and 2 weren’t sufficient.

The Coming World of 3D Printing

3dcubeWithin a decade or two, 3D printers may do for physical objects what digitization did for books, movies, and music.  Another phase of the revolution is coming, with the digital world moving more into the physical.  Along one front there’s the Internet of Things, as physical objects become “smart” and linked to the Internet.  At the other front there’s digital home printing of physical 3D objects, from jewelry to replacement parts, and even candy sculptures.

3D printers are starting to get some mainstream media attention, including an appearance on the Colbert Report and a recent ABC News article. Like computers before them, they’ve already broken out of the business world and are moving into the consumer market.  I’d say we’re now moving past the early Altair phase and about to enter the Apple II explosion.  MakerBot is on their 3rd generation with their new Replicator.  Meanwhile the competition for the home market is heating up, with competitors like the Cube and the larger, but still rather pricey 3D Touch.  Meanwhile the iModela takes a different approach.  It’s a desktop CNC milling machine rather than an additive printer.   Except for the 3D Touch, the prices aren’t that far away from the $1298 that the original Apple II would have set you back when it was introduced, WITHOUT adjusting for inflation.

Make no mistake, this won’t be a passing fad.  Like a lot of technology, it may take a bit longer to get established than the hype would suggest, but its going to happen.  Stories are often a much better way to make a point than facts and figures, and thanks to Cory Doctorow’s ability to write and willingness to release his material under a Creative Commons license, there’s a great 1-page story on the disruption these things are going to cause (there’s also an audio version):

Printcrime by Cory Doctorow

(Originally published in Nature Magazine, January 2006)

The coppers smashed my father’s printer when I was eight. I remember the hot, cling-film-in-a-microwave smell of it, and Da’s look of ferocious concentration as he filled it with fresh goop, and the warm, fresh-baked feel of the objects that came out of it.

The coppers came through the door with truncheons swinging, one of them reciting the terms of the warrant through a bullhorn. One of Da’s customers had shopped him. The ipolice paid in high-grade pharmaceuticals — performance enhancers, memory supplements, metabolic boosters. The kind of thing that cost a fortune over the counter; the kind of thing you could print at home, if you didn’t mind the risk of having your kitchen filled with a sudden crush of big, beefy bodies, hard truncheons whistling through the air, smashing anyone and anything that got in the way.

They destroyed grandma’s trunk, the one she’d brought from the old country. They smashed our little refrigerator and the purifier unit over the window. My tweetybird escaped death by hiding in a corner of his cage as a big, booted foot crushed most of it into a sad tangle of printer-wire.

Da. What they did to him. When he was done, he looked like he’d been brawling with an entire rugby side. They brought him out the door and let the newsies get a good look at him as they tossed him in the car, while a spokesman told the world that my Da’s organized-crime bootlegging operation had been responsible for at least twenty million in contraband, and that my Da, the desperate villain, had resisted arrest.

I saw it all from my phone, in the remains of the sitting room, watching it on the screen and wondering how, just *how* anyone could look at our little flat and our terrible, manky estate and mistake it for the home of an organized crime kingpin. They took the printer away, of course, and displayed it like a trophy for the newsies. Its little shrine in the kitchenette seemed horribly empty. When I roused myself and picked up the flat and rescued my peeping poor tweetybird, I put a blender there. It was made out of printed parts, so it would only last a month before I’d need to print new bearings and other moving parts. Back then, I could take apart and reassemble anything that could be printed.

By the time I turned eighteen, they were ready to let Da out of prison. I’d visited him three times — on my tenth birthday, on his fiftieth, and when Ma died. It had been two years since I’d last seen him and he was in bad shape. A prison fight had left him with a limp, and he looked over his shoulder so often it was like he had a tic. I was embarrassed when the minicab dropped us off in front of the estate, and tried to keep my distance from this ruined, limping skeleton as we went inside and up the stairs.

“Lanie,” he said, as he sat me down. “You’re a smart girl, I know that. Trig. You wouldn’t know where your old Da could get a printer and some goop?”

I squeezed my hands into fists so tight my fingernails cut into my palms. I closed my eyes. “You’ve been in prison for ten years, Da. Ten. Years. You’re going to risk another ten years to print out more blenders and pharma, more laptops and designer hats?”

He grinned. “I’m not stupid, Lanie. I’ve learned my lesson. There’s no hat or laptop that’s worth going to jail for. I’m not going to print none of that rubbish, never again.” He had a cup of tea, and he drank it now like it was whisky, a sip and then a long, satisfied exhalation. He closed his eyes and leaned back in his chair.

“Come here, Lanie, let me whisper in your ear. Let me tell you the thing that I decided while I spent ten years in lockup. Come here and listen to your stupid Da.”

I felt a guilty pang about ticking him off. He was off his rocker, that much was clear. God knew what he went through in prison. “What, Da?” I said, leaning in close.

“Lanie, I’m going to print more printers. Lots more printers. One for everyone. That’s worth going to jail for. That’s worth anything.”

Creative Commons License Deed

Attribution-NonCommercial-ShareAlike 2.5

You are free:

* to Share — to copy, distribute, display, and perform the work
* to Remix — to make derivative works

Under the following conditions:

* Attribution. You must attribute the work in the manner specified by the author or licensor.

* Noncommercial. You may not use this work for commercial purposes.

* Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.

* For any reuse or distribution, you must make clear to others the license terms of this work.

* Any of these conditions can be waived if you get permission from the copyright holder.

Disclaimer: Your fair use and other rights are in no way affected by the above.

This is a human-readable summary of the Legal Code (the full license)