Category Archives: Uncategorized

Two items of interest: Legos in a research lab and DARPA Challenge video

Posted on by
Reply

Make Magazine’s blog had an interesting item on how researchers in the U.K. have automated a long, repetitive process by using Lego Mindstorms NXT robots. The researchers are working on automated bones, and building up the material involves repeatedly dunking the substrate in various liquids in a certain order.  Rather than buy expensive equipment dedicated to this application, they put some Mindstorms robots together and programmed them.

A second item of interest comes from Udacity’s Programming a Robotic Car course.  The course is in beta (as are all their courses) and still has some rough edges (e.g., in the automated grading of programming homework), but the course is fascinating and well-taught.  I find it to be good value for the time committed and the courses are free.  In any event, there’s an interesting video showing a visualization one of the cars in the DARPA challenge detecting the barriers in the maze it’s in and using it’s A* pathfinding algorithm to determine its path.  The video also shows the car dealing with a complete roadblock and parking itself.

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.