off topic

• Python
  Some very nice python routines that read NMEA GPS strings and transmit them over UDP.
  (tags: python gps)

I had a chance to sit down a play around with the Maxbotics LV-EZ3 ultrasonic range finder. The EZ3 is a low cost, reasonably high quality range finder capable of measuring distances from around 6″ all the way up to 254″. The device is fairly straightforward and can output analog voltage, PWM, or serial data (although strangely, RS-232 not TTL). The analog output is the obvious choice, as I will be using my arduino board to interact with the device.

When I initially connected the device I was mildly discouraged. The values returned on the analog pin seemed slightly erratic. Too much so to even process a data sample. The MaxSonar-EZ1 FAQ recommended implementing a low pass RC filter using a .1uF capacitor and 1k resistor, which stabilized the output nicely.

The next step was to convert the data into inches so that it will be more useful to Terry. Analog voltages on the arduino range between 0 and 1023 and are scaled based on the analog reference input. The default analog reference is 5V. This means that 5V applied to the arduino’s analog input pin is interpretted by the arduino as 1023. The arduino also has the ability to use an internal analog reference of 1.1V on the ATMega168 microcontroller (2.56V on ATMega8) or an external reference that can be specified by applying voltage to the arduino’s AREF pin. Information on the arduino analog reference configuration can be found here. The Maxbotics EZ3 outputs a maximum of 5V, therefore I was able to use the default reference.

With the low pass filter functioning properly and the analog reference properly set, I was ready to convert the output into inches. The arduino analogRead reference page indicates that each unit (0-1023) represents 0.0049V, and the Maxbotics LV-EZ3 datasheet specifies that an inch is represented by 9.8mV (0.0098V). From there it was simple to translate the arduino’s analog input into inches: ((units * 0.0049)/0.0098).

The code seems to work flawlessly. The data doesn’t seem to vary beyond an inch in either direction even without data sampling and when the unit is jostled around. I will, however, likely sample the data using a mode average that will return the most frequently occurring value in a given dataset. Tomorrow I will try to uncover an effecient algorithm for this, even though it’s completely usable as-is.

These little wall racers look like an incredibly fun side project to pass some time when not working on the autonomous vehicle project.

Fritsl, from letsmakerobots.com retrofitted these little RC cars with some artificial intelligence that allows them to race around any room in your home. The cars are designed to ride counter-clockwise along the wall simulating a standard oval track.

I would really love to make a half-dozen of these things with various levels of AI aggression and watch them battle it out around the house. You can peep the video of the little fellas in action at letsmakerobots.com

As it turns out, my partner in this autonomous vehicle fiasco actually reads this blog. Needless to say, he was a little shocked to read my blog post about the perils of compiled languages the other day. He took it in stride though. It wasn’t like I hadn’t made all of the same points to him directly, but in retrospect, it does appear as though I was giving him a bit of a bad reputation. The problem is that we didn’t clearly define our roles. His desire to use Delphi and my open source philosophy caused a pretty major meltdown for a couple of days.

We’ve since kissed and made up. So from henceforth, I will be known as the “Director of all things involving embedded system components and/or tools.” My partner now lays claim to the title of “Most venerable architect of software design and implementation.”

In order to ensure that I never again abuse my position as “Chief Dictator of the written word,” I have offered to give my partner Terry a voice of his very own.

I’ve got a real beef with the commonly accepted notion that natively compiled code is always inherently faster than interpreted scripting languages. Obviously, all things being the same, compiled code will almost always perform better than interpreted code. But what happens when a novice programmer is faced with tasks like File I/O, serial, or network communication? The lower level languages generally provide platform API’s, but they still require a certain amount of mastery for true optimization whereas many of the newer scripting languages provide a very straightforward manner of achieving the same results. My assertion: Unless your programming skills outshine those of the programmers who designed the interpreted language, I believe you will find interpreted languages to be as good, if not better at performing such tasks than any low level language.

I mention this because there has been a considerable rift in the autonomous vehicle design process. I was originally writing the code in Python. A very powerful language that enabled me to read, parse, and store GPS serial data in about 10 minutes and with only 5 lines of code. My partner, on the other hand, has been insisting that a compiled language would perform this task significantly better. He has spent the last 16 hours trying to read and parse data from the serial port using Delphi. The code is still not complete, and I am very displeased that we are now using a commercial ($2,000) development environment to accomplish something that could be done more easily, and with negligible difference in performance, using open source languages such as python.

We’re still in the early stages of development so the decision hasn’t been finalized on which language to use. I will continue to write code in python when time permits in hopes of proving it’s overall usefulness, but as of now, the project is officially being developed using Delphi.