Tag Archives: Arduino

An Open HW/SW API for Your Car

Posted on by
1

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

Introduction

“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.

Background

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 http://openxcplatform.com/developers/vehicle-interface/assembly.html,  used under Creative Commons Attribution 3.0 License.

Measurement Precision versus Control Precision

Posted on by
Reply

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.

Links to Information on converting R/C cars to autonomous vehicles

Posted on by
1

My first robot, MARV-1, uses a small, commercial tracked chassis.  It uses dead reckoning from wheel encoders (only) for navigation, and a single front-mounted ultrasonic sensor for obstacle avoidance.  While I could get fancier on sensors and tweak the control more (e.g., add proportional feedback between the wheel encoders and the motor PWM control to keep on course better), I figure I’m nearing the end of the development and testing I want to do on this first robot.

For MARV-2, my second robot,  I want to build a new vehicle with GPS and other sensor systems suitable for outdoor navigation, and I want something that covers ground more quickly.  I figure an R/C conversion will fit the bill.  I’ve started looking into this, and it seems that it’s not too difficult.  It also seems that it’s easier on a “hobby” class R/C vehicle than a cheap toy one.  Many hobby class cars, it seems (from my online research) utilize standard 3-wire servo connections, sometimes with an electronic controller between the R/C unit and the drive and steering controls.  Cheaper toy cars have a circuit board you need to cut wires from and solder new connections on.

AVC 2010 Poster

Poster for Sparkfun’s 2010 AVC competition

Sparkfun Electronics runs an annual Autonomous Vehicle Competition, and several competitors from past years have blogs with useful information for developing autonomous vehicles from R/C cars.  Three blog postings that seem to provide a lot of good information are Overdue AVC Specifications, Team Zyzzyx” SparkFun AVC 2011 Ground Entry, and Data Bus: the Nickel Tour.

The video podcast The Latest in Hobby Robotics has several videos on modifying R/C cars.  The two I’ve found that are most relevant are The Latest in Hobby Robotics 17, which focuses on modifying higher end cars and The Latest in Hobby Robotics 18, which demonstrates modding a cheaper toy-style R/C car.

An additional link that’s worth pointing out, especially if you’re modifying a toy R/C car, is Autonomous R/C Car – Part 1 – Reverse Engineering Signals.

I suspect it will be a while before I wrap up work on MARV-1 and have the time to start MARV-2, but the information these other hobbyists provide a lot of good guidance for getting started.